Storeに格納した機密な情報(DBのパスワード等)を、直接ECSのTaskDefinitionに指定できる機能が発表されましたが、今回それを試してみたので紹介します。Railsと致します。前提として、今まで開発してきたPJをECSで動かす際は、以下のような運用をしていました。最後について、RailsにはもともとEnvironment毎に設定を出し分ける機能(config/database.yml等)が備わっていますが、Dockerの特性上、極力環境の差異はアプリケーション自体に定義するのではなく、動作する環境上で実行時に確定したいと言う思いがありました。Appにも書かれている通りコンテナの環境変数を使って環境上の差異を吸収していました。AppのAPIシークレット等がこれにあたります。ディレクティブに直接定義するのは少々気が引けます。実際に、当プロジェクトではTaskDefinitionはアプリ側のリポジトリに管理されていたので、開発者は全員が閲覧可能でしたが、機密情報はすべての開発者に見える必要がない為、これらの情報はデプロイ時に個別に展開する必要がありました。Storeを使うものや、S3を使うもの等が紹介されていました。前者の方がよりおすすめされていましたが、当時は以下の理由でS3の方を採用しました。Gemを使えば環境変数の一覧をファイルで管理できるのでS3の方が相性が良い以下、実際の運用フローです。環境変数ファイルを管理するS3バケットを準備ポイントは以下となります。s)を実行、と言った流れになります。実際に、丁寧なドキュメントがあるのでそれに従って設定を行います。SSMにSecureStringなParameterを作る実際にはDBのパスワード等を想定しています。様に階層構造にしておくと、あとでIAMの設定が楽になります。今回はアカウントのデフォルトKMSキーを使いました。以下の階層にあるParameter全てを取得可能に、また復号のために(先程設定した)アカウントデフォルトのキーの使用権を与えます。指定する必要があるので注意が必要です。実際に実行してみる先程更新したTaskDefinitionを使って実際にタスクを作ります。(バックグラウンドで何もしないプロセスを継続するだけ)するだけの内容となっています。※実際のRunTaskの手順は省略します。タスクが起動しました。Taskの詳細画面secretsの内容は表示されていませんね(当然ですが)。]}それでは実際にコンテナインスタンスにSSHして、コンテナの中身を見てみましょう。環境変数が無事渡っている事が分かります。Parameterの取得と復号を行い、普通の環境変数とマージしてコンテナを実行している様です。言及する、普通に環境変数をセットした場合にインスタンス上からこれらの機密な情報が見えてしまうと言う問題が、この方法では解決できていない様に見えます(従来どおりコンテナの中で環境変数を展開すればinspectでは見えないので)。されたら結果は同じなので、そもそもインスタンスへのログイン権限とTaskDefinitionの閲覧権限は分けるのが安全です。Taskの環境変数への埋め込みが格段に楽になりました!これは使わない手はないです。優秀な技術者と一緒に、好きな場所で働きませんか株式会社もばらぶでは、優秀で意欲に溢れる方を常に求めています。働く場所は自由、働く時間も柔軟に選択可能です。現在、以下の職種を募集中です。ご興味のある方は、リンク先をご参照下さい。採用情報プロジェクトマネージャー(リモート)ソフトウェアエンジニア(リモート)デザイナー(リモート)Subscriptionメールアドレスを記入して購読すれば、更新をメールで受信できます。ThemePacific。