IAM
https://gyazo.com/7ecb7d8cd753429e301ab98d0117c6d0
ルートユーザのアクセスキーは削除するのがベストプラクティス
暗黙的なdeny（デフォルト）<明示的なallow<明示的なdeny
ポリシーをユーザに直接アタッチするのはバット→ロールにアタッチしてロールを使用すること！！
ユーザー
Awsコンソールにログインできる
ポリシーをアタッチすることでできる事を制限する
グループ
グループを作成してそこに適切なポリシーをアタッチすることでできる事を制限したグループを作れる
そのグループの中にユーザを含めて行けば、同じ権限を持ったユーザを量産できる
一人一人同じ事ができるユーザを作るのはだるいからね
hiroki.iconグループの入れ子とかはできないよ
IAMユーザをグループに入れて、あるユーザだけにさらに他のポリシーをアタッチするとかはできるよ
ロール
AWSのリソースに付与するもので、IAMポリシーをグルーピングしたもの
誰(プリンシパル)がAssumeRoleできるのかという信頼ポリシーも設定する
ポリシー
AWSリソースにアクセスや操作を許す権限。Json形式のドキュメント
hiroki.iconポリシー自体は純粋な権限の概念で誰がの情報はない
ユーザーやグループ、ロールにアタッチされるものである
S3FullAccess など
AssumeRole
特定のRoleを一時的に引き受けることができる
→本来持っていない権限を一時的に得られる→デプロイ時のみ特定の権限を得る
assumeRoleしてからassumeRoleするという連鎖的なこともできる
goで書かれているから、goの勉強する時にコードリーディングしてみるといいかも
プリンシパル
認証される主体のこと
プリンシパルがawsリソースに対してリクエストを出す。そのリクエストをポリシーと付け合わせて許可されるか判断する
アカウント IAMユーザ IAMロールなど
コマンド
IAMユーザを確認する
aws iam list-users
IAMユーザにアタッチされているポリシーを確認する
aws iam list-attached-user-policies --user-name ユーザ名
自分の所属しているグループ一覧
aws iam list-groups-for-user --user-name ユーザ名
グループにアタッチされているポリシー
aws iam list-attached-group-policies --group-name グループ名
https://gyazo.com/ed74bfe51b8b98de3d79ddccf88a4122