ECS タスク定義の変数設計: env と Secrets の実務ルール

ECS のタスク定義では、environment と secrets を混在させがちです。ここを曖昧にすると、平文シークレット混入や起動失敗の原因になります。

この記事の結論

environment: 非機密のみ
secrets: 機密情報のみ（ARN 参照）
クロスアカウントでは、ロール・Secrets ポリシー・KMS をセットで確認

使い分けの基準

`environment` に置くもの

公開しても問題ない設定値
例: APP_ENV, LOG_LEVEL, FEATURE_FLAG

`secrets`（Secrets Manager 参照）に置くもの

パスワード、トークン、接続文字列など機密情報
タスク定義には secret valueFrom（ARN 参照）のみを置く

タスク定義の例

JSON

{
  "containerDefinitions": [
    {
      "name": "api",
      "environment": [
        { "name": "APP_ENV", "value": "production" }
      ],
      "secrets": [
        {
          "name": "DB_PASSWORD",
          "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:prod/db-password"
        }
      ]
    }
  ]
}

別アカウントのタスク実行ロールを使う場合

クロスアカウントで task execution role を使うときは、次を揃える必要があります。

実行ロールの assume role 信頼ポリシー
Secrets Manager 側のリソースポリシー
必要なら KMS キーの復号権限（kms:Decrypt）

どれか1つ欠けると、タスク起動時にシークレット取得で失敗します。

よくある失敗

environment に機密値を直接書く
タスク定義 JSON をレビューせずに流用する
execution role と task role の責務を混同する

運用ルール例

機密情報はすべて Secrets Manager 管理
タスク定義に平文シークレットを置かない
変更時は「ロール権限・Secrets ポリシー・KMS」をセットでレビュー

まとめ

ECS の変数設計は、 env = 非機密 / secrets = 機密 を徹底するだけで安全性が大きく上がります。クロスアカウント時は、認可経路を図で確認してから実装するのが確実です。