みなさんお疲れ様です！佐々木です！
最近は何かとキャッチアップすることが多いのでやることなすこと中途半端になって、悩みのタネが付きません！若いときより記憶力もおちているなーと地味に落ち込みます、、
ですがそうも言ってられないので覚えるまでやるマインドで今後ともがんばります笑
AWS IAMのお話です。
AWSといったら様々なサービスが沢山ありますね！基本的なところだとEC2やS3とかRDS・DynamoDB、コンテナだとECS、EKS、サーバレスならlambda、Amplify……
はい！たくさんです！（白目）ですが、今日お話ししたいのはIAMです。
なんとなく地味なイメージの人もいるかも知れませんが、ルートユーザーで環境ぶん回してるような人は一度落ち着いてください。ほんとにどえらいことになるので。
IAM(Identity and Access Management)とは
AWSのサービスの一つであり、「認証」と「認可」の設定を行うことができるサービスで、「認証」「認可」を正しく設定することで、AWSの利用者や、AWSのサービスがアクセスできる範囲を制御することができます。
ここでいう「利用者」や「サービス」とは後述の「プリンシパル」を指します。
IAM自体の詳細は、以下の公式ドキュメントや解説を参考にしてください。
IAMユーザー
IAMユーザーとは、ルートユーザーにより、AWSアカウントの範囲内で権限を与えられた個別のユーザーを指す。これはプログラムやアプリケーションの場合もあります。
ユーザーはアクセスキーかパスワード、あるいは両方を選択して認証する方式を決定します。
アクセスキーについてはアクセスキーIDとシークレットアクセスキーが発行されます。
IAMポリシー
IAMポリシーとは、AWSリソースに対する許可・拒否を示すもの。
また、認証主体（プリンシパル）として評価される、IAMユーザーやIAMロールにアタッチして使用することが出来ます。（厳密にはIdentityにアタッチ）
ポリシーはjson形式で記載されており、設定項目の詳細としては以下の通りです。
- プリンシパルを指定・・・Principal
- サービスとアクションを指定・・・Action
- リソースを指定・・・Resource
- コンディション（ポリシーの条件）を指定・・・Condition
なお、ポリシーにはアイデンティティベースとリソースベースの２種類があり、アイデンティティベースのポリシーは認証主体そのものにアタッチするもの、リソースベースのポリシーは操作されるAWSリソース側にアタッチするものになります。
IAMロール
IAMロールとはポリシーを複数アタッチすることが出来る任意の権限をまとめたものであり、特徴として信頼関係と権限という２つの性質を持っています。
ロールにスイッチ出来るポリシーを持ったIAMグループやユーザーであればロールにスイッチすることが出来ます。
IAMのここは抑えときましょう
アイデンティティベースポリシーとリソースベースポリシーについてはきちんと理解しておきたい。
前者は、「誰がどのリソースに対してどんなアクションを実行できるか」というものです。
例えば、「devuser」が「EC2インスタンス」に「参照、スタートとストップ」アクションを行う。
という権限を与えようとした場合、「EC2インスタンスの参照、スタートとストップ」に見合ったポリシーを作成し、それを「devuser」 にアタッチすることで適用されます。
後者は「このリソースに対して誰がどんなアクションを実行できるか」です。
これを指定して作成したポリシーをリソースにアタッチすることで、指定した対象（プリンシパル）に
対してアクセスを許可する。といったものになります。
クロスアカウントアクセスのやり方
■やること
主アカウント（A）で副アカウント（B）のリソースを扱えるようにする。
■準備すること
①既存のAWSアカウントとは別にもう１アカウント作成する。また、Administratorのアカウントを作成しておく。
②主アカウント（A）のアカウントIDをメモしておく。（すぐ確認できるようにしておけばOK）
■手順
1.副アカウント（B）のAdministratorのアカウントでログインして、コンソールからIAMを選びます。
2.IAMの画面に移ったら、ロールの作成を選択します。
3.次に操作する側（主アカウント（A））のアカウントIDを入力します。また、MFAを使用している方はチェックを忘れずに。
4.次にアタッチするポリシーを選択。ここでは「AdministratorAccess」を選択。（こちらは本来はもっと弱い権限でおこなうのが一般的なので実務ではやらないようにしましょう）
5.次のタグはご自由にしていただいて結構です。最後に任意のロール名をつけたら、ロールの作成を押します。
6.ロールが作成される。（自分はhostAccessという名前にしました）
7.以下の画像にある「ロールARN」ですが、この部分を次に使用するので何かしらで控えておきます。
8.ポリシーを作成。（以下のコードのうち、「ここにコピペしてね」と書いてある部分に先程の「ロールARN」に記載されている文字をコピペして下さい。）
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"ここにコピペしてね"
]
}
]
}9.ポリシーの作成が終わったら、ロールにアタッチします。ここまでで、副アカウント（B）で必要なことは終わりです。（副アカウント（B）のアカウントIDと作成したロール名は控えておいて下さい。）
10.主アカウント（A）のマネジメントコンソール部で主アカウント（A）の名前部をクリックすると、「ロールの切り替え」というのが出るので押す。(オレンジ塗り潰しの箇所です)
11.以下画面のSwitch Roleボタンを押します。
12.この画面では、操作する相手先の（ここでは副アカウント（B））のIDとロール名を入力して、「ロールの切り替え」を押す。
13.これで、主アカウント（A）が副アカウント（B）を操作出来るようになりました。
アカウントの名前を押すとこのようになっていると思います。元のアカウントに戻るときも「〜〜に戻る」と書いてあるので楽チンですね。
※初期のままだと、ロールの最大セッション時間が1時間になっています。副アカウント（B）の方で作成したロールのアクセス権限を編集する画面で「1時間〜12時間」の範囲で選択出来ます。
おわりに
地味な内容だったかもしれませんが、僕はAWSのサービスの中で一番好きなサービスです。
みなさんも自分でアプリ作ってデプロイしたり、インフラ構築するときのためにもIAMはしっかり抑えておきたいところですね！
みなさんがIAMと仲良くなれますように！ではこのへんで！
