AWS CLIで作成したAWS Cloud9環境のIDEにアクセスできなかったので対処した話

2020.11.24

こんにちは、CX事業本部の若槻です。

今回は、AWS CLIで作成したAWS Cloud9環境のIDEになぜかアクセスできなかったので対処した際の話です。

事象

AWS CLIで下記のようにCloud9環境を作成しました。

% aws cloud9 create-environment-ec2 \
--name myCloud9Env \
--instance-type t2.micro

しかし、AWS Cloud9のマネジメントコンソールにアクセスしてみると、CLIで作成した環境が[Your Environments]タブに表示されていると思いきや、なぜかされていませんでした。 image

そしてAWSアカウント内のCloud9環境一覧である[Accounts environments]タブを見ると、先程作成した環境はこちらの方に表示されていました。しかし、環境のIDEのリンク[Open IDE]はグレーアウトしていて開けないようになっています。 image

先程作成した環境のIDEのURLhttps://ap-northeast-1.console.aws.amazon.com/cloud9/ide/<environmentId>に直接アクセスしてみると、下記のような400エラーとなりIDEにアクセスできませんでした。

User is not authorized to open this environment. Either the environment doesn't exist or the user is not a member of this environment.

image

原因

AssumeRole(スイッチロール)でアクセスしたAWSアカウントに対して操作を行っているため、マネジメントコンソールへのアクセス時に使われるロールセッション名と、先程AWS CLIで作成したCloud9環境のOwnerとなるロールセッション名が異なっていることが原因でした。

ドキュメントによると、AssumeRoleでアクセスした際のIAM ARNは次のようになります。

arn:aws:sts::account-id:assumed-role/role-name/role-session-name

そこで既にコンソールから作成していた環境と、先程AWS CLIで作成した環境のOwner Arnを比較してみると、次のようにロール名(AssumeRole時の引受けロール)までは同じですが、ロールセッション名が異なっています。

  • コンソールから作成した環境
    • Owner Arn:arn:aws:sts::{AccountId}:assumed-role/cm-wakatsuki.ryuta/cm-wakatsuki.ryuta
    • ロール名:cm-wakatsuki.ryuta
    • ロールセッション名:cm-wakatsuki.ryuta
  • AWS CLIで作成した環境
    • Owner Arn:arn:aws:sts::{AccountId}:assumed-role/cm-wakatsuki.ryuta/wakatsuki-dev-session
    • ロール名:cm-wakatsuki.ryuta
    • ロールセッション名:wakatsuki-dev-session

image

コンソールから作成した環境では、Ownerのロールセッション名は既定の値(AssumeRole元のユーザー名)が使われています。一方で、AWS CLIで作成した環境では、Ownerのロールセッション名はAssumeRole時にassume-roleコマンドのrole-session-nameオプションで指定した値となっていました。

% aws sts assume-role --profile default \
--role-arn $(aws configure get ${target_profile}.role_arn) \
--role-session-name wakatsuki-dev-session \
--serial-number $(aws configure get ${target_profile}.mfa_serial) \
--token-code $mfa_code

よって、AssumeRoleでアクセスするAWSアカウントの場合は、AssumeRole時のロールセッション名をコンソールとAWS CLIで合わせる必要があります。

対処方法

次の2通りの対処方法があります。

対処方法1

Cloud9環境を作成するcreate-environment-ec2コマンドのowner-arnオプションに、コンソールからAssumeRoleアクセス時に使用するものと同じIAM Arnを指定します。

% aws cloud9 create-environment-ec2 \
--name myCloud9Env2 \
--instance-type t2.micro \
--owner-arn arn:aws:sts::{AccountId}:assumed-role/cm-wakatsuki.ryuta/cm-wakatsuki.ryuta

作成された環境(myCloud9Env2)が[Your Eevironments]タブに表示され、Owner Arnがowner-arnオプションで指定したIAM Arnとなっています。IDEも開けるようになっています。 image

対処方法2

AWS CLIでAssumeRoleのセッションを作成するassume-roleコマンドのrole-session-nameオプションに、コンソールからAssumeRoleアクセス時に使用するロールセッション名と同じ値(今回はcm-wakatsuki.ryuta)を指定してやります。

% aws sts assume-role --profile default \
--role-arn $(aws configure get ${target_profile}.role_arn) \
--role-session-name cm-wakatsuki.ryuta \
--serial-number $(aws configure get ${target_profile}.mfa_serial) \
--token-code $mfa_code

これであれば、create-environment-ec2コマンドによる環境作成時にOwnerロールを明示的に指定する必要はなくなります。

% aws cloud9 create-environment-ec2 \
--name myCloud9Env3 \
--instance-type t2.micro

作成された環境(myCloud9Env3)が[Your Eevironments]タブに表示され、Owner Arnが--owner-arnオプションで指定したIAM Arnとなっています。IDEも開けるようになっています。 image

対処できなかった方法

update-environmentコマンドで作成済みの環境のOwnerを更新できるのではと思いましたが、Ownerを指定するオプションはなく更新できないようです。

  update-environment
--environment-id <value>
[--name <value>]
[--description <value>]
[--cli-input-json <value>]
[--generate-cli-skeleton <value>]

よってコンソールアクセス時のIAM ARNと異なるOwnerのCloud9環境を作成してしまった場合は、環境を一度削除して対処方法1または2により作り直す必要がありそうです。

おわりに

AWS CLIで作成したAWS Cloud9環境のIDEになぜかアクセスできなかったので対処した際の話でした。

今回Cloud9を初めてCLIで操作したため、Cloud9環境のOwnerという概念を初めて意識しました。

参考

以上