AWS LambdaのIAMポリシーとリソースポリシーを理解しよう

虎塚

2017.03.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、虎塚です。

先日のAWSアップデートで、Lambda関数ポリシーがAWS Management Consoleに表示されるようになりました。

AWS Developer Forums: Lambda function policies are now viewable on the Lambda console

Lambda関数のアクセス権限設定には、このようなLambda関数ポリシーと呼ばれるリソースベースのポリシーと、IAMポリシーと呼ばれるアイデンティティベースのポリシーがあります。この記事では、これら2種類のポリシーについて整理します。

2種類のポリシーの概要

IAMポリシー (アイデンティティベースのポリシー)

アイデンティティベースのポリシーは、IAMポリシーや実行ロールとも呼ばれます。この記事では、IAMポリシーと書くことにします。

Lambda関数を作る時、実行ロールとして1個のIAMロールを必ず指定します。実行ロールに適用するポリシーが、この記事でIAMポリシーと呼ぶものにあたります。

実行ロールのIAMポリシーには、AWS LambdaにLambda関数の実行をまかせるための信頼ポリシーや、Lambda関数がほかのAWSリソースにアクセスすることを許可するためのアクセスポリシーが含まれます。

リソースポリシー (リソースベースのポリシー)

リソースベースのポリシーは、Lambda関数ポリシーやリソースポリシーとも呼ばれます。この記事では、リソースポリシーと書くことにします。

Lambda関数を定義するとき、リソースポリシーの指定は必須ではありません。指定するには、AWS APIのAddPermissionを使います。

リソースポリシーでは、誰がそのLambda関数を呼び出せるかを定義します。リソースポリシーを使うと、Lambda関数を呼び出す主体として、AWSサービスやAWSアカウントを指定できます。

IAMポリシーとリソースポリシーの違い

IAMポリシーとリソースポリシーは、どちらもJSONで記述します。各ポリシー内の要素は、次のとおりです。

項目	IAMポリシー	リソースポリシー
リソース	ポリシー適用対象のリソースのARN	同左
アクション	リソースオペレーション	同左
効果	Allow or Deny	同左
プリンシパル	指定しない	権限を受け取りたいエンティティ(サービス、アカウント、ユーザ)

IAMポリシーでは、ポリシー適用対象のユーザやサービスが暗黙的にプリンシパルになります。

IAMポリシーとリソースポリシーの使い方

IAMポリシーの使い方

IAMポリシーは、次のいずれかの方法で作成します。

IAMポリシーを作成して、IAMロールに適用する
IAMロールにインラインのIAMポリシーを追加する

このようにして作成したIAMロールを、Lambda関数の実行ロールとして指定します。

リソースポリシーの使い方

一方、リソースポリシーは、Lambda関数に対して直接設定します。AWS CLIでは、aws lambda add-permissionコマンドで作成します。

今回のサービスアップデートで、AWS Management Consoleから見えるようになったのは、こちらのポリシーです。

Lambdaポリシーの表示

それぞれのポリシーをいつ使うか

IAMポリシーは、AWS Lambdaのイベントソースマッピングで、ストリームベースのAWSサービスに対してpull型のLambda関数呼び出しをするときに利用します。AWS LambdaがDynamoDB StreamやKinesis Streamをポーリングして、Lambda関数を呼び出す場合が当てはまります。

リソースポリシーは、AWS Lambdaのイベントソースマッピングで、あるAWSサービスからpush型のLambda関数呼び出しをするときに利用します。たとえば、S3、CloudFront、SNSなどからLambda関数を呼び出す場合が当てはまります。

上の基本的な方針に加えて、クロスアカウントでLambda関数呼び出すときは、たとえストリームベースのAWSサービスとLambda関数を連携する場合でも、リソースポリシーを使うと便利です。

クロスアカウントでLambdaからLambdaを呼び出す場合のポリシー例

ところで、AWSの公式ドキュメントに次のような記述があります。

IAMロールでアイデンティティベースのポリシーを使用する代わりに、Lambda関数ポリシーを使用して、クロスアカウントのアクセス権限を付与できます。たとえば、IAMロールを作成する代わりに、単純にLambda関数ポリシーにアクセス権限を追加することで、Amazon S3アクセス権限を付与して Lambda 関数を呼び出すことができます。

参照: AWS Lambda リソースへのアクセス権限の管理の概要 - AWS Lambda

クロスアカウントでLambda関数を呼び出すときには、IAMポリシーを使うことも、リソースポリシーを使うこともできるようです。それぞれどんなふうに使うのでしょうか。

次のようなAWS環境を題材に、ポリシーをどのように使うかを見てみましょう。

クロスアカウントでLambdaを呼び出す構成の例

参考: Lambdaから別アカウントのLambdaを呼び出す｜ Developers.IO

以下では、呼び出し側のLambda関数をcaller、呼び出される側のLambda関数をcalleeとします。callerはアカウント000000000000、calleeはアカウント111111111111にあります。

IAMポリシーを使う場合

IAMポリシーを使ったLambdaのクロスアカウント呼び出し

アカウント間の連携は、次の2箇所で実現されています。

calleeの実行ロールの信頼ポリシーで、呼び出す側のアカウントによるAssumeRoleを許可する
callerの実行ロールのアクセスポリシーで、calleeの実行ロールに対するAssumeRoleを許可する

calleeの実行ロールに付与する信頼ポリシーを次に示します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::000000000000:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

AWS LambdaへのAssumeRole許可に加えて、caller側アカウント (000000000000) によるAssumeRoleを許可しています。

一方、callerの実行ポリシーのアクセスポリシーは、次のようになります。アカウント間の連携に関係するステートメントを抜粋します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::111111111111:role/callee-role"
        }
    ]
}

呼び出し側のAWS Lambdaは、calleeの実行ロール (callee-role) を引き受けることで、calleeの実行ロールに付与されたアクセスポリシーを使うことができます。

また、一時的な認証情報をLambda関数のコードの中で扱います。callerのコード例を次に示します。

from __future__ import print_function

import base64
import boto3
import json
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def create_function_arn(data):
    region = data['region']
    account = data['accountId']
    function_name = data['functionName']
    return 'arn:aws:lambda:' + region + ':' + account + ':function:' + function_name

def create_role_arn(data):
    # I defined a role by adding a hyphen and 'role' after the function name.
    account = data['accountId']
    function_name = data['functionName']
    return 'arn:aws:iam::' + account + ':role/' + function_name + '-role'

def lambda_handler(event, context):
    logger.info(event)
    for record in event['Records']:
        data = json.loads(base64.b64decode(record['kinesis']['data']))

        role_arn = create_role_arn(data)
        function_arn = create_function_arn(data)
        params = {
            'instanceId': data['parameters']['instanceId']
            }

        sts_response = boto3.client('sts').assume_role(
            RoleArn = role_arn,                              
            RoleSessionName = 'AssumeCalleeRole',
            DurationSeconds=900
            )

        client = boto3.client(
            service_name='lambda',
            aws_access_key_id = sts_response['Credentials']['AccessKeyId'],
            aws_secret_access_key = sts_response['Credentials']['SecretAccessKey'],
            aws_session_token = sts_response['Credentials']['SessionToken']
            )

        response = client.invoke(
            ClientContext = 'string',
            FunctionName = function_arn,
            InvocationType = 'Event',
            LogType = 'Tail',
            Payload = json.dumps(params)
            )
        logger.info(response)

リソースベースのポリシーを使う場合

リソースポリシーを使ったLambdaのクロスアカウント呼び出し

アカウント間の連携は、calleeのリソースポリシーで定義します。実行ロールの信頼ポリシーにアカウント情報を記述したり、AssumeRoleの使用許可をアクセスポリシーで与えたりする必要はありません。calleeにリソースポリシーを付与するコマンドを次に示します。

aws lambda add-permission --profile callee \
  --function-name callee \
  --statement-id AllowActionFromCaller \
  --principal 000000000000 \
  --action lambda:InvokeFunction

callerによるcalleeの呼び出しは、callerの実行ロールに付けたアクセスポリシーで許可します。ポリシーを次に示します。

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "lambda:InvokeFunction",
        "Resource": "arn:aws:lambda:ap-northeast-1:111111111111:function:callee"
    }
}

また、一時的な認証情報は透過的にやりとりされ、コードの中には表われません。リソースポリシーでクロスアカウント呼び出しを実現する場合のcallerのコード例を次に示します。

from __future__ import print_function

import base64
import boto3
import json
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def create_function_arn(data):
    region = data['region']
    account = data['accountId']
    function_name = data['functionName']
    return 'arn:aws:lambda:' + region + ':' + account + ':function:' + function_name

def lambda_handler(event, context):
    logger.info(event)
    for record in event['Records']:
        data = json.loads(base64.b64decode(record['kinesis']['data']))

        function_arn = create_function_arn(data)

        params = {
            'instanceId': data['parameters']['instanceId']
        }
        response = boto3.client('lambda').invoke(
            ClientContext = 'string',
            FunctionName = function_arn,
            InvocationType = 'Event',
            LogType = 'Tail',
            Payload = json.dumps(params)
        )
        logger.info(response)

IAMポリシーまたはリソースポリシーを使うときの留意点

ここまで見てきたように、Lambda関数のクロスアカウント呼び出しは、IAMポリシーとリソースポリシーのどちらを使っても実現できます。IAMポリシーまたはリソースポリシーを使う時のそれぞれの留意点を整理します。

IAMポリシーを使うときの留意点

この場合、calleeの実行ロールの信頼ポリシーで、caller側アカウントのAssumeRoleを明示的に許可する必要があります。AWS Management ConsoleからLambdaサービスロールを作る時に自動で付与される信頼ポリシーは、AWS LambdaサービスへのAssumeRoleだけを許可する内容になっています。意図どおり動かないときは、信頼ポリシーが足りているか確認しましょう。

また、callerの実行ロールでは、calleeの実行ロールを正確に指定してAssumeRoleを許可しましょう。すべてのロールに対してAssumeRoleを許可すると、callee側アカウントにある他のIAMロールに対して意図しないAssumeRoleを許可してしまう可能性があります。