AWS CloudShellの環境の分離基準が気になったので確認してみた

AWS CloudShellの環境は「IAMユーザー単位 + IAMロール単位 + スイッチロール元のIAMユーザー単位」で分離されていることが分かりました。正確には「arn:aws:sts::AWSアカウントID:assumed-role/ロール名/セッション名」毎に環境が作成されます。

のんピ

2022.03.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS CloudShellの環境がどんな基準で分かれているのか気になる

こんにちは、のんピ(@non____97)です。

皆さんはAWS CloudShellの環境がどんな基準で分かれているのか気になったことはありますか? 私はあります。

AWS CloudShellの公式ドキュメントに以下のような記載があります。

With AWS CloudShell, you have persistent storage of 1 GB for each AWS Region at no cost. Persistent storage is located in your home directory ($HOME) and is private to you.

Limits and restrictions for AWS CloudShell - AWS CloudShell

private to youですよ。private to you。

このように表記されていると、どんな基準でprivate to youなのかが気になりますよね。私の方で言及している公式ドキュメントを探してみましたが、見当たりませんでした。

そこで、AWS CloudShellの環境がどんな基準で分かれているのか、実際に操作して確認してみました。

いきなりまとめ

AWS CloudShellの環境は「IAMユーザー単位 + IAMロール単位 + スイッチロール元のIAMユーザー単位」で分離されている
- 正確には「arn:aws:sts::AWSアカウントID:assumed-role/ロール名/セッション名」毎に環境が作成される
- マネージメントコンソールからスイッチロールする際はセッション名を変更できない

検証すること

考えられる分離基準は以下パターンがあります。（AWS CloudShellはリージョナルサービスであり、リージョン単位で分かれているのは自明なので検証しません）

AWSアカウント単位
IAMユーザー単位
IAMユーザー単位 + IAMロール単位
IAMユーザー単位 + IAMロール単位 + スイッチロール元のIAMユーザー単位
IAMユーザー単位 + IAMロール単位 + スイッチロール元のAWSアカウントとIAMユーザーの単位

想定される分離基準を確認するために、以下のパターンでAWS CloudShellの環境を確認します。

AWSアカウントAのIAMユーザーa
AWSアカウントAのIAMユーザーb
AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール
AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール2にスイッチロール
AWSアカウントAのIAMユーザーbからAWSアカウントAのIAMロール1にスイッチロール
AWSアカウントBのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール
AWSアカウントBのIAMユーザーcからAWSアカウントAのIAMロール1にスイッチロール

確認方法としては、「他のパターンで作成したファイルが確認できるか」というシンプルな方法です。

確認してみた

1. AWSアカウントAのIAMユーザーa

実際に確認してみます。

まずは、「1. AWSアカウントAのIAMユーザーa」のパターンです。

確認した結果は以下の通りです。

1. AWSアカウントAのIAMユーザーa

# 操作しているIAMユーザーの情報を表示
[cloudshell-user@ip-10-1-10-126 ~]$ aws sts get-caller-identity
{
    "UserId": "<AIDACKCEVSQ6C2EXAMPLE1>",
    "Account": "<AWSアカウントA>",
    "Arn": "arn:aws:iam::<AWSアカウントA>:user/cloudshell-test-user-1"
}

# カレントディレクトリを確認
[cloudshell-user@ip-10-1-10-126 ~]$ pwd
/home/cloudshell-user

# /home 配下に cloudshell-user 以外のディレクトリがないか確認
[cloudshell-user@ip-10-1-10-126 ~]$ ls -l /home
total 20
drwxr-xr-x 3 cloudshell-user cloudshell-user  4096 Mar 29 02:13 cloudshell-user
drwx------ 2 root            root            16384 Mar 29 02:13 lost+found

# カレントディレクトリにファイルやディレクトリが無いか確認
[cloudshell-user@ip-10-1-10-126 ~]$ ls -l
total 0

# AWSアカウントAのIAMユーザーa で操作したことが分かる様にカレントディレクトリにファイルを作成
[cloudshell-user@ip-10-1-10-126 ~]$ touch cloudshell-test-user-1

# 作成したファイルの確認
[cloudshell-user@ip-10-1-10-126 ~]$ ls -l
total 0
-rw-rw-r-- 1 cloudshell-user cloudshell-user 0 Mar 29 02:14 cloudshell-test-user-1

2. AWSアカウントAのIAMユーザーb

続いて、「2. AWSアカウントAのIAMユーザーb」のパターンです。

これで「1. AWSアカウントAのIAMユーザーa」のパターンで作成したファイルを確認できれば、AWS CloudShellの環境はIAMユーザー単位ではなく、AWSアカウント単位で分離されていることになります。

確認した結果は以下の通りです。

2. AWSアカウントAのIAMユーザーb

# 操作しているIAMユーザーの情報を表示
[cloudshell-user@ip-10-0-28-37 ~]$ aws sts get-caller-identity
{
    "UserId": "<AIDACKCEVSQ6C2EXAMPLE2>",
    "Account": "<AWSアカウントA>",
    "Arn": "arn:aws:iam::<AWSアカウントA>:user/cloudshell-test-user-2"
}

# カレントディレクトリを確認
[cloudshell-user@ip-10-0-28-37 ~]$ pwd
/home/cloudshell-user

# /home 配下に cloudshell-user 以外のディレクトリがないか確認
[cloudshell-user@ip-10-0-28-37 ~]$ ls -l /home
total 20
drwxr-xr-x 3 cloudshell-user cloudshell-user  4096 Mar 29 02:28 cloudshell-user
drwx------ 2 root            root            16384 Mar 29 02:28 lost+found

# カレントディレクトリにファイルやディレクトリが無いか確認
[cloudshell-user@ip-10-0-28-37 ~]$ ls -l
total 0

# AWSアカウントAのIAMユーザーb で操作したことが分かる様にカレントディレクトリにファイルを作成
[cloudshell-user@ip-10-0-28-37 ~]$ touch cloudshell-test-user-2

# 作成したファイルの確認
[cloudshell-user@ip-10-0-28-37 ~]$ ls -l
total 0
-rw-rw-r-- 1 cloudshell-user cloudshell-user 0 Mar 29 02:32 cloudshell-test-user-2

結果としては、「1. AWSアカウントAのIAMユーザーa」のパターンで作成したファイルは確認できませんでした。そのため、少なくともIAMユーザー単位で環境は分かれていそうです。

3. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール

続いて、「3. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール」のパターンです。

これで「1. AWSアカウントAのIAMユーザーa」のパターンで作成したファイルを確認できれば、AWS CloudShellの環境はスイッチロールしているかどうかは関係なく、単純にIAMユーザー単位で分離されていることになります。

確認した結果は以下の通りです。

3. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール

# 操作しているIAMユーザーの情報を表示
[cloudshell-user@ip-10-1-9-125 ~]$ aws sts get-caller-identity
{
    "UserId": "<AIDACKCEVSQ6C2EXAMPLE3>:cloudshell-test-user-1",
    "Account": "<AWSアカウントA>",
    "Arn": "arn:aws:sts::<AWSアカウントA>:assumed-role/cloudshell-test-role-1/cloudshell-test-user-1"
}

# カレントディレクトリを確認
[cloudshell-user@ip-10-1-9-125 ~]$ pwd
/home/cloudshell-user

# /home 配下に cloudshell-user 以外のディレクトリがないか確認
[cloudshell-user@ip-10-1-9-125 ~]$ ls -l /home
total 20
drwxr-xr-x 3 cloudshell-user cloudshell-user  4096 Mar 29 02:24 cloudshell-user
drwx------ 2 root            root            16384 Mar 29 02:23 lost+found

# カレントディレクトリにファイルやディレクトリが無いか確認
[cloudshell-user@ip-10-1-9-125 ~]$ ls -l
total 0

# AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール で操作したことが分かる様にカレントディレクトリにファイルを作成
[cloudshell-user@ip-10-1-9-125 ~]$ touch cloudshell-test-role-1_cloudshell-test-user-1

# 作成したファイルの確認
[cloudshell-user@ip-10-1-9-125 ~]$ ls -l
total 0
-rw-rw-r-- 1 cloudshell-user cloudshell-user 0 Mar 29 02:25 cloudshell-test-role-1_cloudshell-test-user-1

結果としては、「1. AWSアカウントAのIAMユーザーa」のパターンで作成したファイルは確認できませんでした。そのため、IAMロールの情報も環境分離の要素に含まれていそうです。

4. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール2にスイッチロール

続いて、「4. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール2にスイッチロール」のパターンです。

これで先程の「3. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール」のパターンで作成したファイルを確認できれば、AWS CloudShellの環境はスイッチロール先のIAMロールは関係ないことになります。

確認した結果は以下の通りです。

4. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール2にスイッチロール

# 操作しているIAMロールの情報を表示
[cloudshell-user@ip-10-0-64-44 ~]$ aws sts get-caller-identity
{
    "UserId": "AROA6KUFAVPUQPSAPYPG5:cloudshell-test-user-1",
    "Account": "<AWSアカウントA>",
    "Arn": "arn:aws:sts::<AWSアカウントA>:assumed-role/cloudshell-test-role-2/cloudshell-test-user-1"
}

# カレントディレクトリを確認
[cloudshell-user@ip-10-0-64-44 ~]$ pwd
/home/cloudshell-user

# /home 配下に cloudshell-user 以外のディレクトリがないか確認
[cloudshell-user@ip-10-0-64-44 ~]$ ls -l /home
total 20
drwxr-xr-x 3 cloudshell-user cloudshell-user  4096 Mar 29 02:26 cloudshell-user
drwx------ 2 root            root            16384 Mar 29 02:26 lost+found

# カレントディレクトリにファイルやディレクトリが無いか確認
[cloudshell-user@ip-10-0-64-44 ~]$ ls -l
total 0

# AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール2にスイッチロール が操作したことが分かる様にカレントディレクトリにファイルを作成
[cloudshell-user@ip-10-0-64-44 ~]$ touch cloudshell-test-role-2_cloudshell-test-user-1

# 作成したファイルの確認
[cloudshell-user@ip-10-0-64-44 ~]$ ls -l
total 0
-rw-rw-r-- 1 cloudshell-user cloudshell-user 0 Mar 29 02:27 cloudshell-test-role-2_cloudshell-test-user-1

結果としては、「3. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール」のパターンで作成したファイルは確認できませんでした。そのため、「IAMユーザーが同じでもスイッチロール先のIAMロールが異なれば別の環境が作成される」ということになります。

5. AWSアカウントAのIAMユーザーbからAWSアカウントAのIAMロール1にスイッチロール

続いて、「5. AWSアカウントAのIAMユーザーbからAWSアカウントAのIAMロール1にスイッチロール」のパターンです。

これで「3. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール」のパターンで作成したファイルを確認できれば、AWS CloudShellの環境はスイッチロール元のIAMユーザー単位では分離されないことになります。

確認した結果は以下の通りです。

5. AWSアカウントAのIAMユーザーbからAWSアカウントAのIAMロール1にスイッチロール

# 操作しているIAMロールの情報を表示
[cloudshell-user@ip-10-0-94-135 ~]$ aws sts get-caller-identity
{
    "UserId": "<AIDACKCEVSQ6C2EXAMPLE3>:cloudshell-test-user-2",
    "Account": "<AWSアカウントA>",
    "Arn": "arn:aws:sts::<AWSアカウントA>:assumed-role/cloudshell-test-role-1/cloudshell-test-user-2"
}

# カレントディレクトリを確認
[cloudshell-user@ip-10-0-94-135 ~]$ pwd
/home/cloudshell-user

# /home 配下に cloudshell-user 以外のディレクトリがないか確認
[cloudshell-user@ip-10-0-94-135 ~]$ ls -l /home
total 20
drwxr-xr-x 3 cloudshell-user cloudshell-user  4096 Mar 29 02:33 cloudshell-user
drwx------ 2 root            root            16384 Mar 29 02:33 lost+found

# カレントディレクトリにファイルやディレクトリが無いか確認
[cloudshell-user@ip-10-0-94-135 ~]$ ls -l
total 0

# AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール2にスイッチロール で操作したことが分かる様にカレントディレクトリにファイルを作成
[cloudshell-user@ip-10-0-94-135 ~]$ touch cloudshell-test-role-1_cloudshell-test-user-2

# 作成したファイルの確認
[cloudshell-user@ip-10-0-94-135 ~]$ ls -l
total 0
-rw-rw-r-- 1 cloudshell-user cloudshell-user 0 Mar 29 02:34 cloudshell-test-role-1_cloudshell-test-user-2

結果としては、「3. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール」のパターンで作成したファイルは確認できませんでした。そのため、「スイッチロール先のIAMロールが同じでもIAMユーザーが異なれば別の環境が作成される」ということになります。

6. AWSアカウントBのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール

続いて、「6. AWSアカウントBのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール」のパターンです。

これで「3. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール」のパターンで作成したファイルを確認できれば、AWS CloudShellの環境はスイッチロール元のAWSアカウント単位では分離されないことになります。

確認した結果は以下の通りです。

6. AWSアカウントBのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール

# 操作しているIAMロールの情報を表示
[cloudshell-user@ip-10-1-9-125 ~]$ aws sts get-caller-identity
{
    "UserId": "<AIDACKCEVSQ6C2EXAMPLE3>:cloudshell-test-user-1",
    "Account": "<AWSアカウントA>",
    "Arn": "arn:aws:sts::<AWSアカウントA>:assumed-role/cloudshell-test-role-1/cloudshell-test-user-1"
}

# カレントディレクトリを確認
[cloudshell-user@ip-10-1-9-125 ~]$ pwd
/home/cloudshell-user

# /home 配下に cloudshell-user 以外のディレクトリがないか確認
[cloudshell-user@ip-10-1-9-125 ~]$ ls -l /home
total 20
drwxr-xr-x 3 cloudshell-user cloudshell-user  4096 Mar 29 02:25 cloudshell-user
drwx------ 2 root            root            16384 Mar 29 02:23 lost+found

# カレントディレクトリにファイルやディレクトリが無いか確認
[cloudshell-user@ip-10-1-9-125 ~]$ ls -l
total 0
-rw-rw-r-- 1 cloudshell-user cloudshell-user 0 Mar 29 02:25 cloudshell-test-role-1_cloudshell-test-user-1

「3. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール」のパターンで作成したファイルは確認できました。そのため、「同じ名前のIAMユーザーを使えばスイッチロール元のAWSアカウントが異なっていたとしても、同じ環境として扱われる」ということを確認できました。

7. AWSアカウントBのIAMユーザーcからAWSアカウントAのIAMロール1にスイッチロール

続いて、「7. AWSアカウントBのIAMユーザーcからAWSアカウントAのIAMロール1にスイッチロール」のパターンです。

これで「3. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール」のパターンで作成したファイルを確認できなければ、AWS CloudShellの環境は「IAMユーザー単位 + IAMロール単位 + スイッチロール元のIAMユーザー単位」であることが確定します。

確認した結果は以下の通りです。

7. AWSアカウントBのIAMユーザーcからAWSアカウントAのIAMロール1にスイッチロール

# 操作しているIAMロールの情報を表示
[cloudshell-user@ip-10-0-31-29 ~]$ aws sts get-caller-identity
{
    "UserId": "<AIDACKCEVSQ6C2EXAMPLE3>:cloudshell-test-user-3",
    "Account": "<AWSアカウントA>",
    "Arn": "arn:aws:sts::<AWSアカウントA>:assumed-role/cloudshell-test-role-1/cloudshell-test-user-3"
}

# カレントディレクトリを確認
[cloudshell-user@ip-10-0-31-29 ~]$ pwd
/home/cloudshell-user

# /home 配下に cloudshell-user 以外のディレクトリがないか確認
[cloudshell-user@ip-10-0-31-29 ~]$ ls -l /home
total 20
drwxr-xr-x 3 cloudshell-user cloudshell-user  4096 Mar 29 02:39 cloudshell-user
drwx------ 2 root            root            16384 Mar 29 02:39 lost+found

# カレントディレクトリにファイルやディレクトリが無いか確認
[cloudshell-user@ip-10-0-31-29 ~]$ ls -l
total 0

結果としては、「3. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール」のパターンで作成したファイルは確認できませんでした。そのため、AWS CloudShellの環境は「IAMユーザー単位 + IAMロール単位 + スイッチロール元のIAMユーザー単位」ということになります。

スイッチロール元のIAMユーザー名の重複には注意しよう

AWS CloudShellの環境の分離基準が気になったので確認してみました。

調査の結果、AWS CloudShellの環境は「IAMユーザー単位 + IAMロール単位 + スイッチロール元のIAMユーザー単位」で分離されていることが分かりました。

正確には「arn:aws:sts::AWSアカウントID:assumed-role/ロール名/セッション名」毎に環境が作成されます。

これは各パターンのaws sts get-caller-identityの実行結果を見れば分かります。そうです。「3. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール」と「6. AWSアカウントBのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール」のパターンのみ実行結果が一致しています。

どちらもArnはarn:aws:sts::AWSアカウントA:assumed-role/cloudshell-test-role-1/cloudshell-test-user-1となっています。

スイッチロール元のセッションのARNはarn:aws:sts::AWSアカウントID:assumed-role/ロール名/セッション名というフォーマットです。こちらのフォーマットの通り、スイッチロール元のAWSアカウントIDはARNに含まれません。また、マネージメントコンソールからスイッチロールする際はセッション名を変更できず、セッション名はスイッチロール元のIAMユーザー名になります。

そのため相当なレアケースですが、IAMユーザーの名前が重複しており、スイッチロール先のIAMロールを共用している場合は同じ環境が割当たることになります。このような事象を避けるためにIAMユーザー名をなるべくユニークな名前にした方が良いかもしれませんね。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部コンサルティング部ののんピ(@non____97)でした!

AWS CloudShellの環境の分離基準が気になったので確認してみた

AWS CloudShellの環境がどんな基準で分かれているのか気になる

いきなりまとめ

検証すること

確認してみた

1. AWSアカウントAのIAMユーザーa

2. AWSアカウントAのIAMユーザーb

3. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール

4. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール2にスイッチロール

5. AWSアカウントAのIAMユーザーbからAWSアカウントAのIAMロール1にスイッチロール

6. AWSアカウントBのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール

7. AWSアカウントBのIAMユーザーcからAWSアカウントAのIAMロール1にスイッチロール

スイッチロール元のIAMユーザー名の重複には注意しよう

イベント

EVENT【5/29（水）大阪】Alteryxの使い方から導入メリットまですべてがわかるセミナー＆ワークショップ

EVENT【5/15（水）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会〜フィンテック / リテール業界案件特集〜を開催します

EVENT【5/28（火）】AWSを最大活用するための1dayカンファレンス

EVENT【5/17（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！

EVENT【4/25（木）リモート】Google Cloudに携わるエンジニアのキャリア～クラスメソッド会社説明会～

AWS CloudShellの環境の分離基準が気になったので確認してみた

AWS CloudShellの環境がどんな基準で分かれているのか気になる

いきなりまとめ

検証すること

確認してみた

1. AWSアカウントAのIAMユーザーa

2. AWSアカウントAのIAMユーザーb

3. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール

4. AWSアカウントAのIAMユーザーaからAWSアカウントAのIAMロール2にスイッチロール

5. AWSアカウントAのIAMユーザーbからAWSアカウントAのIAMロール1にスイッチロール

6. AWSアカウントBのIAMユーザーaからAWSアカウントAのIAMロール1にスイッチロール

7. AWSアカウントBのIAMユーザーcからAWSアカウントAのIAMロール1にスイッチロール

スイッチロール元のIAMユーザー名の重複には注意しよう

イベント

EVENT【5/29（水）大阪】Alteryxの使い方から導入メリットまですべてがわかるセミナー＆ワークショップ

EVENT【5/15（水）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会 〜フィンテック / リテール 業界案件特集〜 を開催します

EVENT【5/28（火）】AWSを最大活用するための1dayカンファレンス

EVENT【5/17（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【5/10（金） 名古屋】クラスメソッドグループの会社説明会を開催します！

EVENT【4/25（木）リモート】Google Cloudに携わるエンジニアのキャリア～クラスメソッド会社説明会～

関連記事

AWS CloudShellをControl-Bできちんと1文字戻るように設定してみた

[小ネタ] CloudShellで最新のAWS CLIのバージョンに自動で引き上げる方法（AWS CLIバージョン1、バージョン2両方対応）

CloudShell上で一発でAssumeRoleできるワンライナーを作ってみた

AWS CloudShell から Gemini APIを利用してみた

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会〜フィンテック / リテール業界案件特集〜を開催します

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！