記事のタイトルが長くなってしまったのですが、主要な構成は以下です。
アカウントA
- APIGateway(IAM認証付き)
- Lambda
アカウントB
- Lambda
フロー
アカウントB.Lambda ⇒ アカウントA.APIGateway ⇒ アカウントA.Lambda
細かく見ていきましょう。
Githubリポジトリ
今回記事で解説している構成を作成した際のソースをgithubにプッシュしました。
もし同じような構成を作っていて困っている方がいたら、ソースをいじってデプロイしてみてください!
※使う際はいくつかのパラメータをご自身の環境に合わせて設定していただく必要があります。
注意
- こちらの記事はPython, AWS SAMを利用しています。
- Pythonではさらに、Boto3, aws_requests_auth のライブラリを利用しています。
- 動くところまでどうにか作ったものなので、もっと良い構成や実装、間違っている点があればご指摘頂けると勉強になります。
本記事の対象者
コアなケースですので、あまり対象者はいないかもしれません。それ故に情報が無かったので、記事にすることにしました。
- AWSのAPIGateway, Lambda, IAMロールが分かる人
- 「APIGatewayにIAM認証をかける」が分かる人
- SAM、又はCloudFormationを利用してAWSリソースをデプロイした経験がある人
- 他アカウントのLambdaからIAM認証をかけたAPIGatewayを呼び出したい人
構成について
今回実装した構成は、APIGatewayのアカウントとAPIGatewayを呼び出すLambdaのアカウントが別であり、APIGatewayにはIAM認証が必要という構成図です。
以下構成図です。
構成の詳細: APIGateway Account
まず、こちらの構成の詳細を解説します。
APIGateway Accoutでは、IAM認証のかかったAPIGateway、呼び出し先のLambdaが基本の構成です。
こちらのAPIGatewayが別アカウントから呼び出され、最終的にLambda関数の結果が戻されます。
このアカウントでポイントとなるのが、__IAMロール__の存在です。
こちらのIAMロールのSAMテンプレートを見てみましょう。すべて見る必要は全くないです。ポイント1,ポイント2だけ見てください。
APIGatewayRole:
Type: "AWS::IAM::Role"
Properties:
RoleName: !Ref RoleName
Path: "/"
ManagedPolicyArns:
- "arn:aws:iam::aws:policy/service-role/AmazonAPIGatewayPushToCloudWatchLogs"
Policies:
- PolicyName: "authorizerLambdaInvokeAccess"
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: "Allow"
Action:
#...............ポイント1:Lambda周りの権限も必要
- lambda:InvokeAsync
- lambda:InvokeFunction
- execute-api:Invoke
Resource: "*"
#...............ポイント2:このIAMロールを他で使えるようにAssumeRolePolicyを規定する
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: "AllowApiGatewayServiceToAssumeRole"
Effect: "Allow"
Action:
- "sts:AssumeRole"
Principal:
AWS:
- !Sub "arn:aws:iam::${AnotherAccountID}:role/FromLambdaRole"
ポイント1: Lambda周りの権限も必要
ポイント2: このIAMロールを他で使えるようにAssumeRolePolicyを設定する
Lambda周りの権限も必要
今回の構成では、APIGatewayに渡ってきた認証情報を、APIGatewayのロールとして利用します。
詳しくは、以下の記事に書いた情報を確認ください。
そのため、APIGatewayがLambdaを実行できる権限も必要なため、その権限を付けています。
AssumeRolePolicyを設定する
AssumeRolePolicyとは、STS(Security Token Serivce )にてAssumeRoleする際に利用するPolicyです。
では、STSのAssumeRoleとはなんでしょう?
それは、IAMロールが持っている権限を一時的に別のユーザーやロールに付与する動作のことです。
今回はAPIGateway Accountで作成したIAMロールによってAPIGatewayのIAM認証を行うので、こちらのIAMロールの権限をLambda AccountのIAMロールに付与する必要があります。
そこで、AssumeRolePolicyに権限を付与する対象を記載しているのです。
以下を見てみましょう。
Principal:
AWS:
- !Sub "arn:aws:iam::${AnotherAccountID}:role/FromLambdaRole"
他アカウントのIAMロールであるFromLambdaRoleに「AssumeRoleをしてもよい」という許可を出しています。
構成の詳細: Lambda Account
次に、Lambdaアカウントの構成を解説します。
ポイントとなるのは、「APIGateway AccountのIAMロール」から権限をもらうことが許可されている、__IAMロール__です。
こちらのIAMロールをLambdaにアタッチすることで、Lambdaにて「APIGateway AccountのIAMロール」を利用することができます。そして、「APIGateway AccountのIAMロール」を使ってLambdaからAPIGatewayを呼び出すことができます。
呼び出し時のソースを見てみましょう。
credentials = get_credentials() # ...............ポイント1: IAMの認証情報を取得する
auth = AWSRequestsAuth(
aws_access_key=credentials['AccessKeyId'],
aws_secret_access_key=credentials['SecretAccessKey'],
aws_host=aws_host,
aws_region=REGION_NAME,
aws_service='execute-api'
)
headers = {'x-amz-security-token': credentials['SessionToken']}
# ............... ポイント2: IAMの認証情報を送る
response = requests.post(
url, json={"foo": "bar"}, auth=auth, headers=headers)
def get_credentials():
client = boto3.client('sts')
IAM_ROLE_ARN = os.environ['IAM_ROLE_ARN']
IAM_ROLE_SESSION_NAME = 'other_account_session'
response = client.assume_role(
RoleArn=IAM_ROLE_ARN,
RoleSessionName=IAM_ROLE_SESSION_NAME
)
return response['Credentials']
- ポイント1: IAMの認証情報を取得する
- ポイント2: IAMの認証情報を送る
STSを利用し、IAMの認証情報を取得する
先ほどAPIGateway Accountの解説の際に出てきたSTSのAssumeRoleを利用し、IAMロールの認証情報を取得しています。
こちらをAPIGatewayを呼び出す際にヘッダーに渡してあげることで、IAM認証のかかったAPIGatewayを呼び出すことが出来ます。
IAMの認証情報を送る
requests.postの中で、IAMロールの認証情報を一緒に送信して上げましょう。
response = requests.post(
url, json={"foo": "bar"}, auth=auth, headers=headers)
以上のようにすることで、別アカウントからのAPI呼び出しが可能になります。
感想
1番辛かった作業は、SAMの書き方を調べながら書くことです。
SAMは使っている人が少ないせいもあり、なかなか情報が少ないです。
また、公式ドキュメントも最低限の情報しか書いてないので中々苦労します。日本語訳が割と雑なのはまだ良いのですが、英語で読んでも欲しい情報に中々辿り着けません。
今度IaCするときは、terraformとかを使ってみようかなと思いました。
参考記事