IAM(AWS)

AWS Identity and Access Management

以下、だいぶはしょった説明

（だいぶはしょってもこれだけ煩雑……

IAMユーザー

いわゆるユーザー

ユーザーだけでは何もできない

ユーザーができることは、ユーザーについたポリシーに従う

IAMポリシー

「〜〜をすることができるという権限」

例

このリソースの、これこれの操作を、行うことができる(Allow)

このリソースの、これこれの操作を、行うことができない(Deny)

IAMロール

ポリシーをn個束ねたもの

例

ポリシー1〜5を束ねて「チームメンバーロール」

ポリシー1〜5+6+7を束ねて「管理者ロール」

6と7は管理者だけに許すべきデリケートなポリシーだったりする

てっとりはやいのはAdministratorsAccessロール

管理者ロール

AWS上でほぼなんでもできる

もちろんなんでもできるロールを使いまくるのは危ない

うっかりミスって重要データ消す（本番データ吹っ飛ばすとか）かもしれないし

不正されて奪われたら何されるかわからん（ビットコイン掘る処理延々と実行させられて月額ウン十万円請求されるとかはありがちか？）

なので、普通は「必要なポリシーだけつける」運用にする

システム構築して、実行して、なんかエラー出て「あ、このポリシーが足らんわ」ってのを延々と繰り返すことになる

ポリシーって、100や200じゃないからね……

自分でシステム構成とか全部見てあたりつけて特定しにいかなきゃいけない

AdministratorsAccess悪魔「ぼくを使ったらてっとり早いよ〜〜」

スイッチロールというくそむずい概念もある

AWSアカウントAが、AWSアカウントBのロールを一時的に使えるようにする仕組み

（AssumeRoleともいう。AがBのロールをAssume（引き受ける）する）

これを実行するためには、

1: B側でロールRをつくり、Rに「アカウントAに渡してもえーです」を入れる

2: A側でAssumeRoleを行うためのポリシーなりロールなりを用意する

3: A側で、2を使ってAssumeRole操作を実行

するとAWSが一連の処理をしてくれて、「ほらよ、このパスワード使ったら一定時間だけRと同じ権限で操作できるぜ」ってのを渡してくれる

あとは、そのパスワードつかってAPI叩く

こんなんどうやって説明すればええねん

新人とかどうすんの？

あらゆるニーズに適応するポテンシャルを持たせるために、本質的にかなり煩雑になっている