ECS Execとは？どのようなメリットがあるか？使ってみよう（第2回）

みなさん、こんにちは。昨日は第1回目として、ECS Execが生まれた背景とその仕組み、実際にECS Execを動かしてみる方法について、お伝えしました。今日は第2回目として、ECS Execの認証やECS Execのメリット等について、解説します。

ECS Execの認証に関して

前述の通り、「aws ecs execute-command」の実行はecs:ExecuteCommand権限が必要となり、更にIAMポリシーのCondition句でリソース単位で権限を制御する事が可能です……が、実際はコンテナは動的に変化するため、公式のドキュメントではタグによる制御が推奨されています。

前述のrun-taskコマンドでは「key=environment,value=production」と指定していますが、このタグを付与されたコンテナに対するECS Execの権限は次の通りとなります。

  {
         "Version": "2012-10-17",
         "Statement": [
             {
               "Effect": "Allow",
               "Action": "ecs:ExecuteCommand",
               "Resource": "arn:aws:ecs:region:{AWSのアカウントID}:task/cluster-name/*",
               "Condition": {
               "StringEquals": {"ecs:ResourceTag/environment": "production"}
               }
           }
       ]
   }

ECS Execの登場により変わるもの

ECS Execはコンテナの運用・保守に関わる不確かな業務フローをAWSの文脈で管理できるようになるという意味で、単純に「Fargateでもコンテナの中身が見れるようになった！」ではなく、Docker on EC2なECS環境においても非常に効果的なメリットをもたらしてくれます。

コンテナのトラブルシュートの必要性等、運用上の課題で仕方なくEC2にデプロイしていた環境もFargate構成へと移行できる
「サービスのデバッグのため」という事情でSSHキーを開発者・保守担当者が持ち、誰がSSHキーを持っているか分からずSSHキーの更新も行われない…という不健康な運用を改善し、IAMベースでコンテナにアクセスできるユーザーを管理できる
「コンテナのホストOSに対するSSHに対するAuditログを出力し、不正が無いように監査する」という実装が大変な要件に対しても、SSMというAWSのサービスを介してコマンドの入出力を管理できるので、低い難易度と保守コストで「誰が、いつ、何をした」をログとして記録する事が出来る

特に重要なのは「コンテナに対する監査ログが実装できる」事で、SSMを介してコンテナへのアクセスを制御する運用に一元化して、実運用上の機微データ（個人情報）の持ち出しや悪意をもった運用担当者・開発者によるデータの改ざん行為を検知できるようになります。

監査ログに関する実装やベストプラクティスはAWSの公式ブログに詳しく解説が載っているので、ECSを実運用してセキュリティに悩んでいたり、上記の問題をクリアできずコンテナ化に踏み出せなかった方はぜひ一読しておくべき記事だと思います。

https://aws.amazon.com/jp/blogs/news/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/