AWS 基礎コース / Chapter 09

実行時設定をS3とSecrets Managerへ分けて置く

環境変数という同じ入口でも、保存場所まで同じにしてはいけない。設定の性質に応じて、閲覧・更新・監査の扱いを分ける。

TL;DR

  1. API URLやモードなど非機密の設定は、S3上の設定ファイルとして外部化できる。
  2. パスワードやトークンなどの秘密値はSecrets Managerに置き、値の露出範囲を狭める。
  3. ECSのタスク実行ロールとタスクロールを使い分け、必要な取得権限だけを付与する。

01設定値を「秘密かどうか」で分類する

環境変数という渡し方より、保存すべき性質を先に決める

非機密設定をS3、秘密値をSecrets Managerに分ける図
値の重要度に応じて、保存先と権限を分ける。

設定を外部化しても、すべてを同じ場所に置くと閲覧権限が過大になる。まず値が漏れてよいかを基準に、一般設定と秘密値を分ける。

「環境変数で渡す」は最終的な注入方法であり、保存先のセキュリティ判断を省略する理由にはならない。

02S3は非機密の設定ファイルを外出しする

設定変更とコンテナビルドを切り離す

S3の非機密設定ファイルをECSから参照する図
環境ごとの設定をイメージから分離し、更新単位を小さくする。

S3に設定ファイルを置けば、アプリケーションのコード・イメージとは別に環境値を管理できる。対象バケットへの読み取りを必要な実行主体にだけ許可する。

S3は秘密保管庫の代替ではない。値の機密性を誤って分類しないことが前提になる。

03Secrets Managerは秘密値への取得経路を制御する

値を知る人を増やさず、アプリが必要時に参照する

ECSタスクがSecrets Managerから秘密値を取得する図
アプリに必要な秘密値だけを、必要なロールへ許可する。

Secrets Managerに置いた値は、ECSの設定とIAMロールを通じて必要なコンテナへ渡す。タスクのライフサイクルで何を行う権限かを分けて、取得できる秘密を最小化する。

秘密値をログ、タスク定義の平文、ソースコードに残さない。表示・配布・取得の経路を全部確認する。

結論

  1. 設定は機密性で分類してから保存先を決める。
  2. S3は非機密設定、Secrets Managerは秘密値を扱う。
  3. ECSからの参照権限も最小化して、値の露出経路を管理する。