ecsTaskExecutionRoleを自作したらFargateにデプロイできなくなった注意点

こんにちは、けんご(@N30nnnn)です。

ECS周りの権限を含めて全てTerraformでプロビジョニングしていたら、ECS Fargateでコンテナをデプロイする際に権限周りでデプロイできずに困ったため、文章で残しておこうと思います。

目次

問題点と解決策

ことの発端は ECSまわりのIAMをTerraformでプロビジョニングしようと書き換えたところから始まります。定義したtfファイルは次のようなものです。

結論から書くと、この定義の致命的なところは3行目で ecsTaskExecutionRole の path をルートではなく /project/ に書き換えてるところにあります。

これをTerraformでデプロイし、ecsTaskExecutionRoleを指定してECSサービスデプロイを行うと完了されません。タスクのイベントタブには次のようなエラーログが並び、ecs-cli でデプロイした場合は同様のエラーがコンソールに出力され返ってきません。。。

service select_type failed to launch a task with (error ECS was unable to assume the role 'arn:aws:iam::************:role/project/ecsTaskExecutionRole' that was provided for this task. Please verify that the role being passed has the proper trust relationship and permissions and that your IAM user has permissions to pass this role.).

「pathはIAMをカテゴリ分けするものだろ」との曖昧な認識を改めることになりました。今回の問題は path をルートに戻すことで解決です。

類似した問題で記事を発見したので合わせて載せます。

【AWS】IAM ロールのパスをルート(/)以外にする - Qiita


今回当てはまらなかった別の問題

今回調べてるときに発見した、いくつか落とし穴がいくつかあるため併せて記します。

  • 信頼されたエンティティには ecs-tasks.amazonaws.com を設定する
  • 事前にAWSServiceRoleForECSを始めとしていくつかロールを作成する

信頼されたエンティティには ecs-tasks.amazonaws.com を設定

さほどややこしい問題ではないので省略。 EC2ベースのECSからFargateに移行してきた人たちが、EC2を信頼する AssumePolicy を作成してハマる事例があるとか。

事前にAWSServiceRoleForECSを始めとしていくつかロールを作成

Fargateのクラスタを作成するとき、裏では勝手に AWSServiceRoleForECS が作成されます。どういう訳かこのIssueのように作成されない事例があるようで、その場合はロールを手動で作成しないと AssumeRole できないよというお話です。また、クラスタが削除されるとロールも削除されるので、自ら作成しておくのが吉。このような話はAWS全体を通して一般的で、結構裏で勝手にロールを作ってくれたりします。最近はSageMakerでもハマった。

Unable to assume the service linked role when following the fargate tutorial · Issue #733 · aws/amazon-ecs-cli · GitHub

Amazon ECS 用のサービスにリンクされたロール - Amazon Elastic Container Service

サービスにリンクされたロールの使用 - AWS Identity and Access Management

ECS初回構築時に自動作成されるIAMロール「AWSServiceRoleForECS」とTerraformでの予期せぬ挙動 - 憂鬱な世界にネコパンチ!