PowerUserでIAMUserを発行できるようになりたかっただけなのに~権限の複雑さを味わってみた~

最近、「色々な意味で強くなりたいなぁ」と思う事が度々ありました。

▲ 身体も心もひしゃげやすい

心身共にストロングになる為の筋トレに日々勤しむ、AWS事業本部のShirotaです。ちなみに、体幹は結構しっかりしているそうです。何をやっているお陰なんでしょうかね

今日は、AWSに強くなる為にガッツリIAMUserのカスタムポリシーについて考えた時の事をまとめたいなと思います。

IAM周りの権限がほぼ絞られているPowerUser

AWSには「PowerUserAccess」というポリシーがあります。
これはAWSの公式ガイドによると「開発者パワーユーザー」と名付けられ、以下のようなユーザーが利用するポリシーだと言われています。

ユースケース: このユーザーはアプリケーション開発タスクを実行し、AWS 対応アプリケーションの開発をサポートするリソースとサービスを作成および設定できます。
ポリシーの説明: このポリシーの最初のステートメントでは、NotAction 要素を使用して、すべての AWS サービスのすべてのアクションと、すべてのリソース (AWS Identity and Access Management および AWS Organizations を除く) のすべてのアクションを許可します。2 つめのステートメントでは、サービスにリンクされたロールを作成する IAM アクセス許可を付与します。これは、別のサービスのリソース (Amazon S3 バケットなど) にアクセスしなければならないサービスに必要です。また、ユーザーの組織に関する情報 (マスターアカウントの E メールや組織の制限など) を表示する 組織 アクセス許可を付与します。

引用元: 職務機能の AWS 管理ポリシー

このように、PowerUserAccessにはアカウント周りのサービスへの権限は絞りつつ、それ以外は割とやりたい事がやれるような権限が与えられています。

IAMUserの発行だけはできるようになりたい、そう思っていた

今回、そんなPowerUserでありながらもIAMUserの発行だけは実行できるようなポリシーが必要とされるケースがあった為、ポリシーをカスタマイズして検証してみました。
先に結果からお話しすると、 想像以上に大変な事になってしまいました 。
実際にやってみた検証を追いかけながら、お話ししていきたいと思います。

最終的に作ったポリシー

まず、最終的に作ったポリシーを載せようと思います。

これは、

• 任意のポリシーをアタッチしたIAMUserの発行ができる
• CLIで利用できるように、IAMUserにアクセスキーを作れるようにする
• 作成後、IAMUserについての以下のものは確認・追加ができる
  • ポリシー
  • アクセスキー
• IAMUser発行時に設定したものは削除できない

と言った権限を与えたポリシーになります。

  
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "NotAction": [
                "iam:*",
                "organizations:*",
                "account:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateUser",
                "iam:CreateAccessKey",
                "iam:ListPolicies",
                "iam:ListUsers",
                "iam:AttachUserPolicy",
                "iam:ListAccessKeys",
                "iam:ListAttachedUserPolicies",
                "iam:GetUser",
                "iam:GetPolicyVersion",
                "iam:ListUserPolicies",
                "iam:ListGroupsForUser",
                "iam:CreateServiceLinkedRole",
                "iam:DeleteServiceLinkedRole",
                "iam:ListRoles",
                "organizations:DescribeOrganization",
                "account:ListRegions"
            ],
            "Resource": "*"
        }
    ]
}  

PowerUserの権限に、いくつか権限を追加してカスタムしています。
このポリシーで落ち着くまでの試行錯誤を辿りながら、今回追加した権限について解説していきたいと思います。

目的達成までの軌跡

まずは、IAM周りの権限を追加しようと思いました。
勿論、今回の目的に合わせたポリシーと言えば真っ先に思い浮かぶものがあります。

「 IAMUserが作れるようになりたいのなら、CreateUserでしょ 」

CreateUserを追加して、完璧だと思っていた

PowerUserのポリシーをコピーして、カスタムポリシーの土台にしました。
そして、「iam:CreateUser」を"Action"に追加しました。
早速、できたてのポリシーをIAMUserにアタッチして、ポリシーを試してみる事にしました。

その結果がこちらです。

▲ ポリシー無ェ

▲ アクセスキー無ェ

おらこんな虚無いやだ。
確かにIAMUserが発行できるようなポリシーが欲しいとは言いましたが、虚無はあんまりです。
やりたい事の為に足りていないポリシーについて、エラー画面が懇切丁寧に教えてくれるのでそれを確認しながらポリシーを追加していきます。

▲ エラーからポリシーを読み取ると手っ取り早い

ListPoliciesが足りない

虚無が生まれた原因その1です。
ポリシー一覧が見られなかった結果、IAMUser作成画面でポリシーがつけられませんでした。
「iam:ListPolicies」を"Action"に追加しました。

AttachUserPolicyが足りない

虚無が生まれた原因その2です。
ポリシー一覧が見られても、ポリシーをアタッチできない状態です。
「iam:AttachUserPolicy」を"Action"に追加しました。

CreateAccessKeyが足りない

虚無が生まれた原因その3です。
このポリシーが無いと、アクセスキーが作れません。
「iam:CreateAccessKey」を"Action"に追加しました。

ListUsersが足りない

上記までで、IAMUser発行時にエラーや注意のポップアップが出なくなりました。

▲ 心と目に優しい緑色

ですが、このままだと折角発行したIAMUser自身を見る事ができません。
IAMUserの名前を忘れたとしても、その確認すらできません。
なので、「iam:ListUsers」を"Action"に追加しました。

ListUsersだと足りない権限を補う

ListUsersだけだとIAMUserの一覧を表示できるようになりますが、IAMUser発行時にアタッチしたポリシーや作成したアクセスキーが確認できなくなります。
なので、以下のポリシーを"Action"に追加しました。

• iam:ListAccessKeys
• iam:ListAttachedUserPolicies
• iam:GetUser
• iam:GetPolicyVersion
• iam:ListUserPolicies
• iam:ListGroupsForUser

その結果、以下のようにポリシーやアクセスキーが確認できるようになりました。

▲ ポリシーよし

▲ アクセスキーよし

作成したIAMUserで、AWS CLIが叩けるかの確認もしました。

  
$ aws configure --profile poweruserplus
AWS Access Key ID [None]: XXXXXXXXXXXXXXXXXX
AWS Secret Access Key [None]: XXXXXXXXXXXXX
Default region name [None]: ap-northeast-1
Default output format [None]:  

$ aws s3 ls s3://s3-testlogs --profile poweruserplus
                           PRE /
                           PRE pdf-access-logs/
$ aws s3 ls s3://test-share-pdf  --profile poweruserplus

An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied  

アタッチした、特定のS3バケットのReadのみ許可するカスタムポリシーが機能していました。

今回作成したポリシーで起こる事

やりたい事が達成できるポリシーをカスタムしたのですが、このポリシーでは以下のような状態が発生します。

▲ ポリシーを追加して、削除しようとした

IAMUser発行後に追加するポリシー・アクセスキーの削除はできません。
勿論、IAMUserの削除もできない為、間違ったポリシーをアタッチしたIAMUserを発行した場合には作り直さないといけません。
今回はIAMUserを発行し、最低限必要な情報を相手に伝えられる(作成したIAMUser名、アタッチしたポリシー、利用するアクセスキー)ようにだけしたかったのでポリシーはこのようにしてみました。

そうは言っても守りたい「最小権限」

正直、ここまでポリシーの追加が必要だと、IAMへの権限が与えられているポリシー(それこそAdministratorAccess)を使った方が早いのではないかと思います。面倒でしたよね。
しかし、こういう時こそ思い出して欲しい事があります。 IAMのベストプラクティスである、「 最小権限を付与する 」という事です。

今回、アタッチしたポリシーは以下のようになります。
赤枠で囲んだポリシーが、 IAMUserを発行する時に最低限必要なポリシー です。

▲ 何だかんだで14/141

蓋を開けてみると、今回アタッチしたポリシーはIAMに存在しているポリシーの1/10程度でしかないのです。
時と場合によりますが、やりたい事に対して色々なポリシーをアタッチしたように思えて、まだまだ多数のポリシーが後ろに存在している可能性があります。
「最小権限を付与する」事を意識して、カスタムポリシーを作成するか既存のAdministratorAccessのようなポリシーをアタッチするかを考える事をオススメします。

▲ カスタムポリシーの保存できるバージョンの上限が5だった悲しみを添えてお別れです