目次
「AWS Lambda実践ガイド」でI AMの理解が深まった
AWSの基礎的な概念のひとつである「I AM」の仕組みについて、頭で理解出来たつもりでも、今ひとつ腹落ちしない部分があリました。
何事も実際に手を動かして体感してみることが一番の習得方法だと思いますが、個人的には書籍「AWS Lambda実践ガイド」掲載の実例を試したことがとても良かったので、同じようにI AMの仕組みをいまひとつ理解出来ていない方へ向けて、書籍で学んだポイントを整理して紹介します。
書籍「AWS Lambda実践ガイド」ですが、AWSのマネージドサービスである「Lambda」について取り扱った内容となっており、当然AWSの初歩、基礎を学ぶための内容ではありませんが、Lambdaの実例を試す中で実際にI AMがどのような役割で使われていて、何のために設定を行うのかを必然的に学ぶことが出来ます。
Lambdaについてまだ学習をしたことがない方であっても掲載されている例のうち、いくつかはシンプルでハードルも高くありませんので、
I AMの学習を目的とした利用であっても十分許容出来る内容ではないかと思います。
（Lambdaについて学習するきっかけにもなり、一石二鳥です！）
I AMユーザとI AMロールの基本概念
書籍の内容に触れる前に、まず、I AMユーザとI AMロールの基本についてあらためて整理しておきます。
I AMユーザー
AWSの各サービスを利用するための実行ユーザのこと
AWSのアカウント契約を行った大元のrootユーザーから複数作成することができ、実際にプロジェクト等でAWSの各サービスを利用する際は通常はI AMユーザーでログイン（サインイン）して行うことが推奨されている。
I AMユーザーごとに「ポリシー」と呼ばれるAWSの各サービスを利用するための実行権限を付与することができる。
I AMロール
ユーザーではなく、AWSのサービス自体の実行権限のこと。（ヒトではなくモノ）
I AMユーザーと同様、こちらもAWSの各サービスを利用できるようにするためのポリシーをアタッチする。
I AMユーザーとI AMロールの使い分け
I AMユーザーとI AMロールの実際の使い分けですが、
例えばサインインを行ったI AMユーザーで「EC2」というサービスを使って仮想サーバを起動する場合、そのI AMアカウント自体にEC2サービスを操作するポリシーをアタッチしないと操作することが出来ません。
I AMロールは、あるサービスから別のサービスを利用するための権限なので、後ほど書籍の解説でも紹介しますが、AWSサービスの一つである「Lambda」から異なるサービスである「S3」への操作を行う場合、「S3」を操作するためのポリシーがアタッチされたI AMロールの元でLambdaを実行する必要があります。
（Lambda関数は作成時に実行ロールの設定を行うことができる）
「第４章 S3のイベント処理」を解説
今回は書籍内の「第４章 S3のイベント処理」の実例に必要な、I AMの設定を整理していきます。
章の内容で取り扱う、LambdaとS3を使用した実例について、ざっくりと解説すると、
S3バケットに画像などのファイルが配置された際にLambda関数を実行し、ファイルを暗号化zip形式に変換して別のS3バケットに保存させるというものです。
I AMユーザ、I AMロールにそれぞれポリシーを割り当てる
I AMユーザー側、I AMロール側に割り当てるポリシーはそれぞれ下記となります。
I AMユーザー側
AWSLambda_FullAccess （Lambdaの全ての操作権限）
こちらの権限が無いと、サインインしているI AMユーザーにコンソール上からLambda関数の作成、実行などの操作を行うことが出来ません。
I AMロール側
AmazonS3FullAccess （S3の全ての操作権限）
AWSLambdaBasicExecutionRole (Lambda関数を実行するための基本的な権限)
前者は実行するLambda関数からS3バケットに対してファイルの読み書き操作、後者は作成したLambda関数自体を実行するために必要なポリシーとなります。
これらのポリシーを割り当てた※I AMロールをLambda関数作成時に実行ロールとして設定します。
※書籍では「role-lambdaexec」という名前で作成
AdministratorAccessについて
I AMを操作するためには、サインインしているI AMアカウントにAdministratorAccessという管理者権限のポリシーが必要ですので、
無い場合は同ポリシーを持つI AMユーザーへサインインし直して上記のI AMの操作を行うか、新しいI AMユーザーに同ポリシーをアタッチしてから操作を行います。
S3バケット側で権限を設定するには？
前述のように、書籍ではLambda関数からS3バケットを操作できるようにするために、Lambda関数の実行ロールにポリシーを設定する方法が解説されていました。
書籍では解説が省かれていたS3バケット側でポリシーを設定する方法について紹介します。
I AMロール「role-lambdaexec」に設定したLambdaの実行権限、AmazonS3FullAccesseはデタッチ（除外）しておきます。
この状態でLambda関数を実行すると、S3への操作権限が無いため下記のエラーが発生します。
[ERROR] ClientError: An error occurred (AccessDenied) when calling the GetObject operation: Access Denied
バケットポリシーの設定
2つのS3バケットのバケットポリシーを作成してLambda関数からのアクセス権限を設定します。
（マネジメントコンソールより）
S3バケットを選択 > アクセス許可 > バケットポリシー
編集メニューから、JSONの形式でポリシーを記載するようになっていますが、ここでは「ポリシージェネレーター」を使ったJSONの作成方法を紹介します。
編集メニューにある「ポリシージェネレーター」のボタンをクリック、別ウィンドウで開いたフォームに、必要な値を入力してポリシーを作成します。
「Step 1: Select Policy Type」
Select Type of Policy: 「S3 Bucket Policy」をプルダウン選択
「Step 2: Add Statement(s)」
Effect: 「Allow（許可）」を選択
Principal: バケットの操作許可を与える実行ロールの名称
ロール名称の確認方法
I AM > ロール
対象のロールの「ロール ARN」の値
arn:aws:iam::688xxxxxxxxxx:role/role-lambdaexec
Actions:
読み込み対象バケットの場合、プルダウンから「GetObject」を選択
書き込み対象バケットの場合、プルダウンから「PutObject」を選択
Amazon Resource Name (ARN): バケット名
バケット名の確認方法
Amazon S3 > 対象のバケット > プロパティ
「Amazon リソースネーム (ARN)」
arn:aws:s3:::examplereadxxx/*
arn:aws:s3:::examplewritexxx/*
バケット名の後ろに/*を記述する必要があります。
（バケット内のリソースも操作対象とする）
必要な値が入力できたら、「Add Statement」ボタンをクリックし、ボタンの下にポリシーが作成されていることを確認します。
新たに表示された、「Generate policy」ボタンをクリックすると、JSON形式のデータがポップアップで表示されますので、内容を全て選択してコピーします。
バケットのアクセス許可画面に戻り、空白の状態のポリシー欄にコピーしたJSONをそのまま貼り付けます。
下部にある変更の保存ボタンをクリックし設定を完了させます。
これを両方のバケットに行うことでAmazonS3FullAccesseポリシーをアタッチしていた時と同様に、Lambda関数からS3の操作が実行出来るようになりました。
まとめ
I AMついて、ドキュメントや解説だけではきちんと理解するのが難しい部分もありますが、書籍の実例のとおりに実際にサービスとして利用してみることや、設定を正しく行わなかった場合に起きるエラーなどを確認することで、ルールや仕組みをより深く理解することが出来ました。
書籍情報
https://book.impress.co.jp/books/1116101044
Follow me!
