4
9

More than 3 years have passed since last update.

AWS Cloud9の罠

Last updated at Posted at 2020-01-01

AWS Cloud9で引っ掛かかった地味な罠

Cloud9の仕様 (一部想像あり)

  • Cloud作成時は作成者のIAM情報をOWNER情報として保持する(大体以下の何れかのはず)
    • IAMユーザ
      arn:aws:iam::<アカウントID>:user/<ユーザ名>
    • ルートユーザ
      arn:aws:iam::<アカウントID>:root
    • ロールを引き受けたユーザ(ロールを引き受けたフェデレーションユーザ)
      arn:aws:sts::<アカウントID>:assumed-role/<スイッチロール名>/<セッション名(スイッチ元ユーザ名)>
  • 複数人でCloud9を扱う場合、OWNER権限を持つ人が利用したいメンバーに許可を出す必要がある。
    # 権限を付与しない限り同一アカウントであれどIDEを開くことができない。

何があったか

前提:
- 自社のAWSアカウントで調査という名目でCloud9を弄っていた
- Cloud9を弄っているのは私1人だった

事件:
- 社内で色々有り私のIAMユーザ権限が更新され、これまで利用していたロールが使えなくなった
- そのため、私のIAM情報が、環境に保持されているOWNER情報とは異なる状態になった

# 諸事情で元のロールにスイッチできる権限は剥奪された
- 結果として私が構築したCloud9環境に接続できなくなってしまった。

# GitにCommit出来ていないソースが有ったので泣いた

どう対応したか

結論だけで言えば泣きながら環境を作り直した。

上述している物は作り直し終わった後に調べた結果分かったものである

未Commitソースを失わないためにどうすればよかったか

以下のようにしてCloud9にアクセスできる状態にすると良かった。
- AWS CLIを利用して権限を付与したユーザ/ロールを引き受けたユーザを招待する。

# CLIの実行環境で、AWSCloud9Administratorポリシーを持つロールを利用できる認証設定にしておくこと

# create-environment-membershipさえ利用できればいいので、公式ポリシーをつけるのが嫌ならカスタムポリシーでも問題ない

公式より

aws cloud9 create-environment-membership --environment-id <Cloud9のID> --user-arn <ユーザARN> --permissions <与える権限>
  • : Cloud9コンソール > Environment ARN の[environment:]以降のランダム文字列
  • <ユーザARN>: 上述仕様のIAM情報の形式
  • <与える権限>: read-write, read-only のどちらか
    • (私はダメだったが) Cloud9を作った時点のロールにスイッチできるようにIAM権限を戻す

私と同じ悲劇を引き起こさないために

  • ロールを引き受けたユーザがOWNERだと、権限変更が起きるとOWNER情報をロストして面倒なことになる場合があるため、スイッチロールしない素のIAMユーザでCloud9を作ってソイツにOWNER権限持たせておこう
  • 自分1人しか使っておらず絶望することになっても、AWS CLIで何とかread-writeユーザを増やせるのであきらめるには早い
  • 当たり前すぎるけど 定期的にCommitはしておこう!
4
9
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
9