とりあえず、EC2とLambda触ってみた訳だけども、どちらで新しいリソースを作ろうとしてもIAMの一部権限が必要になってポリシーの再設定をやってた。
はやく試してみたかったからどちらのケースでも考えずに「IAMFullAccess」を付与してた訳だけども、これじゃ個人で使う分にはいいけども組織では通用しないよね?
「IAMFullAccess」これが付与されたユーザーでは、普通にAWSマネジメントコンソールのサービスでIAMの機能を全部いじれるってことだから自分で他のユーザーやリソースすべてに対するポリシーの変更ができてしまうってことだもんね。
という訳で、今日は必要最低限の実行ロールを付与する方法を手探りで試してみる?
?使ったポリシー振り返り
サービスのメニューから、IAM > グループって辿ってアクセス許可のタブを開いて「アクセス許可」を見てみる。
前回まではとりあえず、使い会機能の「～FullAccess」ってなってるやつを選択してたのね。
今回は、こっから権限を絞っていきたい訳です。参考までに「ポリシーの表示」を押すと、どんな設定になってるのか確認できます。
?IAMFullAccess
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:*",
"organizations:DescribeAccount",
"organizations:DescribeOrganization",
"organizations:DescribeOrganizationalUnit",
"organizations:DescribePolicy",
"organizations:ListChildren",
"organizations:ListParents",
"organizations:ListPoliciesForTarget",
"organizations:ListRoots",
"organizations:ListPolicies",
"organizations:ListTargetsForPolicy"
],
"Resource": "*"
}
]
}
詳しくないけど、"Action" に指定されてる"iam:*"がIAMへの全アクセスになってるぽいね?
?AWSLambdaFullAccess
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:DescribeChangeSet",
"cloudformation:DescribeStackResources",
"cloudformation:DescribeStacks",
"cloudformation:GetTemplate",
"cloudformation:ListStackResources",
"cloudwatch:*",
"cognito-identity:ListIdentityPools",
"cognito-sync:GetCognitoEvents",
"cognito-sync:SetCognitoEvents",
"dynamodb:*",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"events:*",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:ListAttachedRolePolicies",
"iam:ListRolePolicies",
"iam:ListRoles",
"iam:PassRole",
"iot:AttachPrincipalPolicy",
"iot:AttachThingPrincipal",
"iot:CreateKeysAndCertificate",
"iot:CreatePolicy",
"iot:CreateThing",
"iot:CreateTopicRule",
"iot:DescribeEndpoint",
"iot:GetTopicRule",
"iot:ListPolicies",
"iot:ListThings",
"iot:ListTopicRules",
"iot:ReplaceTopicRule",
"kinesis:DescribeStream",
"kinesis:ListStreams",
"kinesis:PutRecord",
"kms:ListAliases",
"lambda:*",
"logs:*",
"s3:*",
"sns:ListSubscriptions",
"sns:ListSubscriptionsByTopic",
"sns:ListTopics",
"sns:Publish",
"sns:Subscribe",
"sns:Unsubscribe",
"sqs:ListQueues",
"sqs:SendMessage",
"tag:GetResources",
"xray:PutTelemetryRecords",
"xray:PutTraceSegments"
],
"Resource": "*"
}
]
}
あ、「AWSLambdaFullAccess」って結構IAMの権限入ってたんだね?
そうか、前回は「新しい実行ロールを作成」のオプションにチェックを付けてたから[iam:CreateRole]へのアクセス権限がないってエラーがでたのか?
?アクセス権限の考え方を整理する。
EC2とかLambdaっていう有名どころのサービスをはやく使いたくてめちゃくちゃな使い方してしまっていたけども、権限まわりの考え方を整理しておこう。
・IAMアカウントRootユーザー
AWS自体の利用開始した時のメールアドレスでログインするマンスターアカウント、ドキュメント見る限りだと基本的にAWS上の構築とか開発の作業をするときに使うことは推奨されていません。
個別に適切なアクセス権限を付与したIAMユーザーを作成して作業してねってなってる。
・IAMユーザー
基本的に、仕事でAWS触るって場合はこのIAMユーザーを払い出して貰って参画するって感じになると思う。ActiveDirectoryのドメインユーザーに近いイメージ。
IAMユーザーをどのIAMグループに紐づけるかで、どこまでのアクセス権を持たせるか管理していく。
・IAMグループ
ポリシーというアクセス権限を定義したテンプレートを紐づけることで、個々のユーザーをグループ化して振る舞いを管理する。
⚙ポリシーとロール
正直、ここが一番わかりにくいと思った。
ポリシーは、ユーザー自体のアクセス権限による振る舞いを定義している。
このグループに属しているユーザーは、このサービスが使えるよね、みたいな。
うん、ポリシーはいい。
ロールは、基本的にはポリシーと同じようにアクセス権限の設定ができる訳だがユーザーに直接紐づけすることはできない。EC2とかLambdaの様に他のサービスと連携して実行されるリソースに紐づける感じで使うんだけども、そのリソースを実行するユーザーが持つタグでも関連付けができるようになっている。
ドキュメントだけ読むと吐き気がする相関だけども、要するにLinuxとかでもshごとにchmodして実行権限の制御とかするもんね?それを、FaaS仕様にした雰囲気かね。
GASだと、テストの初回実行時に認証踏む感じになってたけど、AWS上では組織利用のイメージでより強力にそこが管理できる雰囲気するね。
で、前回の例でいうとLambda関数の新規作成は実行ロールを新規作成せず既存のロールを使うにして置けばiam:CreateRoleする必要もなかった訳で「AWSLambdaFullAccess」だけ付与しておけば本来は作れた訳ね?（事前に実行ロールを作っていれば、だけど。）
開発を始める前に、今回の関数ではこのサービス使うよねってところまで練っておいて実行ロール作っておいて「この実行ロールを使って、こんな関数を作って下さい。」って感じでタスクを渡してあげればいい訳か?
ちなみに、何もリソースを紐付けず自動生成したデフォルトの実行ロールはこんな設定値になっていた。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "logs:CreateLogGroup",
"Resource": "arn:aws:logs:us-east-2:172610958023:*"
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": [
"arn:aws:logs:us-east-2:172610958023:log-group:/aws/lambda/Test-HelloWorld:*"
]
}
]
}
ログ出力しかできない感じになってる・・・。
ポリシーの編集ってボタンを押すと他のリソースへのアクセス権限が追加できるようになってるね。
今度は、S3のリソース追加する方法を確認してみてLambdaからファイルの読み書きしてみよう?