目次
はじめに
こんにちは、クラウド事業部の清水(駿)です。
ECS on FargateからAuroraへの安全な接続するためのSecrets Managerへの認証情報の格納ついて調査・検証を行いました。
アプリケーションからデータベースに接続するには認証情報が必要です。しかし、ソースコードに認証情報を直接平文でベタ書きすることはセキュリティ上好ましくありません。
対処するためのテクニックとして、コンテナ内の環境変数として定義し、ソースコードから環境変数を読み込むことで接続する流れが採用されます。
この環境変数経由で流し込む場合においても、特にパスワード等の秘匿すべき情報は流し込み元でも安全に保管されなければ意味がありません。
本ブログではSecrets ManagerにAuroraの認証情報を格納し、セキュアに情報を流し込むこととします。
そして、バックエンドアプリケーションからデータベースアクセスを含むアプリケーションの動作確認をします。
こんな方へおすすめの記事です
- ECS on Fargateからデータベース連携を考えている人
- SAP-C02, SCS-C02試験について情報収集したい方
前提
Secrets Managerへの認証情報の格納、コンテナからデータベースへの接続にフォーカスするため、ECS on Fargate, Auroraをはじめ他のリソースはすでに作成してあるものを使用します。
参考
SB Create社から出版されている【AWSコンテナ設計・構築[本格]入門】を参考に進めていきます。
こちら非常にわかりやすくAWS環境でのコンテナの使用法を解説してくれている良書です。興味のある方はぜひ読んでいただきたいです。
試してみた
Secrets Managerの設定
新しいシークレットを保存するをクリック
シークレットのタイプは【Amazon RDS データベースの認証情報】、認証情報は任意のユーザー名、パスワードを入力、暗号化キーはデフォルトの【aws/secretsmanager】を選択
データベースは事前に作成したものを選択して【次】をクリック
シークレット名前と説明は任意のものを入力して【次】をクリック
今回は接続用で使用するためローテーション設定はOFFしたままでOKです
レビュー画面に進むので入力した内容に誤りがないことを確認して【保存】をクリック
Secrets Managerのダッシュボードで作成したものがあることを確認
Secrets Manager用のIAMロール作成
設定したSecrets Managerをコンテナ上の環境変数として読み込ませるために、タスクからのリソースにアクセスする権限("secretsmanager:GetSecretValue")が必要です。
これらを含むポリシーを作成し、既存のタスク実行ロール（ecsTaskExecutionRole）にポリシーを追加します。これまでの手順と同様にIAMダッシュボードから新しいポリシーを作成しましょう。
ポリシーの作成
IAMコンソールから【ポリシーの作成】をクリック
ポリシーエディタを編集して【次】をクリック
任意のポリシー名を入力して【ポリシーの作成】をクリック
ポリシーが作成できたことを確認
IAMロールへのポリシー紐付け
ecsTaskExecutionRoleを選択
ポリシーをアタッチを選択
先ほど作成したポリシーを選択し許可を追加をクリック
ポリシーが追加されていることを確認
Secrets ManagerへのVPCエンドポイントの追加
今回、Fargateのバージョンは【1.4.0】で作成しました。
【1.3.0】ではSecrets ManagerおよびSystems ManagerからシークレットをフェッチするためにFargate ENIが使用されていましたが、
【1.4.0】では、タスクENIが使用されていません。これに加えて、ECSのタスクエージェントがSecrets Managerへ到達するためにインターフェース型VPCエンドポイントが必要となります。
設定値は以下の通りです：
・サービスカテゴリ→AWSサービス
・サービス名→com.amazonaws.ap-northeast-1.secretsmanager
・サブネット→任意のサブネット
・セキュリティグループ→任意のセキュリティグループ
・ポリシー→フルアクセス
・Name→任意の名前
設定できたらエンドポイントの作成をクリックして、コンソールで確認します。
バックエンドアプリケーションへの認証情報の設定
設定したSecrets Managerのコンテナ上の環境変数を読み込ませるためには、ECSのタスク定義の更新を行います。
AWSマネジメントコンソールの「サービス」タブから「Elastic Container Service」を選択し、ECSダッシュボードより実施します。
[タスク定義]から事前に作成しておいたバックエンドアプリの定義を選択します。
[新しいリビジョンの作成]をクリックします。
環境変数情報の設定は下記のように実施
| Key | Value/ValueFrom | 値 |
|---|---|---|
| DB_HOST | ValueFrom | [作成したシークレットのARN]:host:: |
| DB_NAME | ValueFrom | [作成したシークレットのARN]:dbname:: |
| DB_USERNAME | ValueFrom | [作成したシークレットのARN]:username:: |
| DB_PASSWORD | ValueFrom | [作成したシークレットのARN]:password:: |
[作成]までクリックして新しいリビジョンができたことを確認
[サービスの更新]をクリック
CodeDeployのみ元から設定しているものを選択して、他は編集せずに[更新]をクリック
[更新]すると新リビジョンでデプロイ実行されます。
これで認証情報設定は完了です。もしうまくいかない場合はこちらのブログを参照してみてください!
データベースへのアクセス確認
バックエンドアプリケーションがデータベースからデータを取得できるか確認してみましょう。
今回はバックエンドが正しく機能するかどうかの確認にとどめます。「踏み台インスタンス→内部ALB→バックエンドアプリケーション→Aurora」の経路で確認します。
EC2から事前に作成しておいた内部ALBのDNS名を使用してCurlします
$ curl http://[ALBのDNS名]:80/v1/Notifications?id=1 {"data":[{"id":1,"title":"通知1","description":"コンテナアプリケーションの作成の確認です。","category":"information","unread":false,"createdAt":"2021-05-09T04:29:53.989+09:00","updatedAt":"2021-05-09T23:30:03.782+09:00"}]}
以上でハンズオン完了です！
いかかでしょうか、無事に疎通は確認できましたでしょうか？
お知らせ
APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。
その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp
https://www.ap-com.co.jp/service/utilize-aws/
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
