メモ: AWSマイスターシリーズ re:Generate 「AWS Identity and Access Management(IAM)」
次のニュースを見ておぉー！と思い、今日はひさしぶりにAWSのWebinarを視聴しました。
- 【AWS発表】EC2とRDSのリソースにリソースレベルのアクセス許可を設定可能に http://aws.typepad.com/aws_japan/2013/07/resource-permissions-for-ec2-and-rds-resources.html
90分もあってびっくりしました。途中から音声が途切れがちで、宇宙との交信というか、ボサノバみたいになってて大変そうでした（講師の片山さん、お疲れ様でした…）。
以下は覚書きメモです。
IAM概要
IAMは、AWSのAPIアクセスに対して権限をチェックする仕組みです。
ユーザ名は、128文字までのアルファベット、数字、+=,.@-_の記号が使えます。
オプションでパスを設定可能です。これは検索のフィルタリングに使えます。……IAMグループがあるのに、パスをどんなふうに使えば便利なのかがよく分かっていません。IAMポリシーと直接紐づかない、タグのような位置づけで使うとよいのでしょうか？
IAMにも多要素認証が使えるそうです。物理MFAだけでなく仮想MFAも使えます。（参考: http://aws.amazon.com/jp/mfa/virtual_mfa_applications/）
IAMポリシー（本日のメインテーマ）
ポリシーとして許可（あるいは拒否）するActionを指定します。「NotAction」で「〜以外」という否定の指定もできます。
書き方の詳細は公式の資料参照で。
EC2とRDSのリソースレベルのアクセス許可
これは、冒頭で触れた話ですね。
リソースに指定できるAction操作はまだ限定的なので、使う前に要確認です。今後徐々に範囲を広げてくれるそうです。
IAMポリシーの便利な設定例の紹介
（本日のWebinarで、今後一番役に立ちそうと思ったのはこのセクションでした）
EC2リソース用のポリシー変数に、EC2のタグを指定できます。これによって、「指定したタグのついたインスタンスのみ起動/停止可能」という制御が可能になりました（もちろん、同時にEC2へのタグ付けActionは禁止しておかなければいけません、とのこと。そりゃそうですね）。今までは「EC2インスタンスの上げ下げ」というActionベースの指定しかできなかったので、待ってましたという感じです。
また、RDSにもリソースレベルのアクセス許可が出せるようになったので、「MySQLかつmicroで"test"で始まる名前のRDSのみ作成可能」という権限の例が挙げられていました。開発環境の管理に便利そうです。
さらに、サポートと請求画面へのアクセス可否もIAMで設定できるそうです。アカウントを組織で共有している場合や、検証環境をお客さまと共有している場合の運用で使えそうです。
アクセス可否の決定ロジック
グループとユーザのそれぞれにアクセス可否を設定できます。で、どの指定が最終的に有効になるかについて。
デフォルトでDeny ＜ Allow指定 ＜ 明示的にDeny指定 です。
クロスアカウント
IAMポリシーは、AWSアカウントを越えて利用できます。
IAMロール
ユーザではなく、アプリやサービスに付与する認証認可の仕組みです。
IAMロール for EC2
EC2インスタンスにIAMロールを付与することができます。
インスタンス内に置いたアプリから、インスタンス自体の認証情報を取得して、AWSサービスへのリクエストに利用します。
この方法を使うことで、アプリのプログラム内や設定ファイルなどに、AWSのアクセスキーやシークレットキーIDを埋め込む必要がなくなります。
内部的には、事前に作ったIAMロールに対して、STSで認証情報を生成し、EC2のメタ情報に入れる感じ（？）だそうです。
ちょっと気になったのは、インスタンス内からのメタデータの取得にはどんな制約がかかっているかについて。インスタンス内部からのアクセスを装って、外から認証情報を取得されてしまう危険はないのでしょうか？ ロール名がバレない限り大丈夫？
