😸

【TIPS】Cloud9のデプロイ時にClient Errorが発生しロールバックした

2022/08/13に公開

AWS

1. はじめに

こんにちわ、Mitsuoです。
構築作業の一環で、複数アカウントに対してCloudFormationテンプレートを用いてCloud9をデプロイした時の話です。
開発環境で何度も使っていたテンプレートなので特に問題視していなかったのですが、エラーが発生しスタックがロールバックしました。

「Client Error・・・?」

何か認証、認可周りで失敗しているのかな？くらいは読み取れるのですが、具体的に何が問題か分かりませんでした。
作業時のIAMクレデンシャルも適切な権限を与えていましたし、Assume Roleの履歴もCloudTrailに出ていましたし。
後は何だ？。データセンター側のインスタンスが追い付いておらず、Insufficient関連のエラーが発生しているとか？
デプロイするAZを変えてみたり、インスタンスサイズをt3.microから他の物にしてみる？
~~もしかして、俺という存在がAWSからブロックされているから、他の人なら行けるのか？？？~~
と、色々試してみましたが解決しませんでした。そんなこんなで30分くらい格闘していたわけです。

2. 先に原因から

Cloud9に自動的にアタッチするIAMロールAWSCloud9SSMAccessRoleとインスタンスプロファイルAWSCloud9SSMInstanceProfileが作成されていなかったからです。

勘の良い方はすぐに気付かれたと思いますが、Session Managerで接続するCloud9をデプロイしようとしていました。
no-ingress EC2 環境と呼ばれるものですね。

アカウントで初めてCLIを用いたno-ingeree EC2環境を作成する場合は、IAMロールと関連するインスタンスプロファイルを定義しておく必要があります。
公式ドキュメントでも以下の記載を確認しました。

抜粋：
デフォルトでは、Systems ManagerがEC2を実行する権限を持っていないため、IAMインスタンスプロファイルを経由したアクセスが提供されます。
コンソールで初めてno-ingress EC2 環境を作成する時は、IAMロール(AWSCloud9SSMAccessRole)とIAMインスタンスプロファイル(AWSCloud9SSMInstanceProfile)は自動で作成されます。

初めてCLIでno-ingress EC2 環境を作成する場合は、明確にサービスロールとインスタンスプロファイルを定義しなければいけません。

By default, Systems Manager doesn't have permission to perform actions on EC2 instances. Access is provided through an AWS Identity and Access Management (IAM) instance profile. (An instance profile is a container that passes IAM role information to an EC2 instance at launch.)

When you create the no-ingress EC2 instance using the AWS Cloud9 console, both the service role (AWSCloud9SSMAccessRole) and the IAM instance profile (AWSCloud9SSMInstanceProfile) are created automatically for you. (You can view AWSCloud9SSMAccessRole in the IAM Management console. Instance profiles aren't displayed in the IAM console.)

Important
If you create a no-ingress EC2 environment for the first time with AWS CLI, you must explicitly define the required service role and instance profile. For more information, see Managing instance profiles for Systems Manager with the AWS CLI.

この「定義」というのは「先にロールを作成する事」と理解しています。

Managing Systems Manager permissions

なお、公式ドキュメントでCloudFormationに関する言及は無いですが、基本的にはCLIで考慮する事はCloudFormationでも考慮する必要があるかもと思ってます。
CloudFormationのリファレンスにも書いていたりするのですが、Cloud9に関してはまだ記載が無さそうです。

AWS::Cloud9::EnvironmentEC2

3 実際に再現してみる

上述した事象を再現してみます。

IAMロールAWSCloud9SSMAccessRoleが存在する事を確認します。
インスタンスプロファイルも付与されている事が分かります。

次に以下のコマンドを実行します。

aws iam remove-role-from-instance-profile --instance-profile-name `AWSCloud9SSMInstanceProfile` --role-name `AWSCloud9SSMAccessRole`
aws iam delete-role-policy --role-name `AWSCloud9SSMAccessRole` --policy-name `AWSCloud9SSMInstanceProfile`
aws iam delete-role --role-name `AWSCloud9SSMAccessRole`
aws iam delete-instance-profile --instance-profile-name `AWSCloud9SSMInstanceProfile`

参考：Deleting an IAM role (AWS CLI)

コマンド実行後、ロールが削除されていることを確認します。

ロールの削除後、CloudFormationでCloud9をデプロイしてみます。

テンプレートについては【CloudFormation】プライベートサブネットにCloud9(Session Manager経由)をデプロイしてみるの記事を参考にしてください。

しばらくするとスタックがロールバックされます、エラー内容も想定通りですね。

確認が出来ましたので、以下のコマンドを実行し元の状態に戻します。

aws iam create-role --role-name AWSCloud9SSMAccessRole --path /service-role/ --assume-role-policy-document '{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Principal": {"Service": ["ec2.amazonaws.com","cloud9.amazonaws.com"]      },"Action": "sts:AssumeRole"}]}'
aws iam attach-role-policy --role-name AWSCloud9SSMAccessRole --policy-arn arn:aws:iam::aws:policy/AWSCloud9SSMInstanceProfile
aws iam create-instance-profile --instance-profile-name AWSCloud9SSMInstanceProfile --path /cloud9/
aws iam add-role-to-instance-profile --instance-profile-name AWSCloud9SSMInstanceProfile --role-name AWSCloud9SSMAccessRole

参考：Managing instance profiles for Systems Manager with the AWS CLI