勘違いしやすい仕様
AssumeRoleについて勘違いしていた仕様があったので、ナレッジとして残しておきます。
今回やりたかったことについて図解すると以下のようになります。
IAMユーザーからS3バケットへのアクセス権限をAssumeRoleを使って取得します。
AssumeRoleを利用するユーザーに応じて、参照できるS3バケットや権限をよしなに絞りたかったので信頼関係ポリシーではなくIAMポリシーのConditionパラメータで条件を設定しました。
実際にAssumeRoleにアタッチしたIAMポリシーは以下のような形式でした。
AssumeRoleを取得してきたユーザーのIDが合致した時だけ、指定バケットへのフルアクセス権限が付与されます。
見た目上はこれで問題がなさそうに見えますが、実際にはS3へのアクセス権限を得ることができませんでした。
AssumeRoleの情報で上書きされる
まずAssumeRoleを取得する前のIAMユーザーの情報を確認します。
この時点でユーザーIDはS3に指定したものと合致していることを確認済みでした。
続いて以下のコマンドでAssumeRoleを取得しました。
aws sts assume-role \ --role-arn arn:aws:iam::164092333477:role/assume-role \ --role-session-name get-assume-role-user
その後、AssumeRoleでIAM情報を取得したところ以下のようになりました。
つまり、IAMポリシーのConditionパラメータで条件を絞ろうとしても、AssumeRoleを取得したIAMユーザーのIDは上書きされてしまうようです。
aws:useridだけでなくaws:usernameやaws:SourceArnなどもAssumeRoleの情報に上書きされてしまうようでした。
そのため、AssumeRole利用中でも引き継がれる情報をうまく利用して識別してあげる必要があります。
role-session-nameで必要な権限のみ付与
先程確認したAssumeRole利用中のIAM情報ですが、
[AssumeRoleID:指定したRoleSessionName]
という形式でユーザーIDが発行されていることがわかります。
RoleSessionNameはAssumeRole利用時に任意に与えることができる文字列です。
そのため、これを使うことで必要に応じた最低限の権限がつけられることに気がつきました。
例えば以下のIAMポリシーをご覧ください。
RoleSessionNameに[apple-backet]を指定して呼び出すと、apple-backetとgrape-backetへのアクセス権限が付与されます。
同じようにRoleSessionNameに[orange-backet]を指定して呼び出すと、orange-backetとgrape-backetへのアクセス権限が付与されます。
指定したRoleSessionNameが残ることを利用して、与えたセッション名に応じた権限を付与することができるので、アプリケーションからの制御時に使えそうな気がします。
一方で、セッション名さえわかってしまえば好きな権限を受け取ることができてしまうため、アプリケーション内からの呼び出し以外のコントロールで利用することはお勧めできないかもしれませんが。
おわりに
AssumeRoleを利用するとIAMユーザー情報が書き換わってしまうというハマりポイントについて記事にしました。
また、その調査時の副産物としてセッション名に応じて必要な権限を付与する使い方について触れてみました。
従来よく使われているたくさんのAssumeRoleを用意して、必要に応じたAssumeRoleを指定して呼び出す方法ももちろん良いのですが、今回のようなCondition制御を利用して1つのAssumeRoleでセッション名に応じて必要最低限な権限を与える形の方が保守が楽なケースも多いかなと思います。
この辺はセキュリティ要件と保守性に応じてうまく使い分けられると良さそうですね。
コメントを残す