Lambdaの実行ロール Lambda実行時のAWS_ACCESS_KEY_IDとかは何になる？

はじめに

Lambdaをdeployしたものの、AWS SDKのクライアントに渡るCredential情報であるAWS_ACCESS_KEY_IDやAWS_SECRET_ACCESS_KEYって何になるの？で混乱したので調べて分かった事を備忘録としてを残しておく。

※Lambdaが実行される時のIAMのロールは何が適用されるの？に関して理解を深めてみた。

Lambda関数の権限管理の仕組み

Lambda関数には実行ロールという概念があり、このロールを持った状態でLambda関数が実行される

どういうことか実際にLambdaを動かした時にどうなるかというと、

exports.handler = async (event) => {
    console.log(process.env.AWS_ACCESS_KEY_ID)
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response ;
};

START RequestId: dfd399ec-5c22-47df-a50e-6811c8bc44a3 Version: $LATEST
2021-08-24T07:46:00.095Z	dfd399ec-5c22-47df-a50e-6811c8bc44a3	INFO	ASIAxxxxxxxxxxxxxxxx
END RequestId: dfd399ec-5c22-47df-a50e-6811c8bc44a3
REPORT RequestId: dfd399ec-5c22-47df-a50e-6811c8bc44a3	Duration: 52.47 ms	Billed Duration: 53 ms	Memory Size: 128 MB	Max Memory Used: 65 MB	Init Duration: 144.98 ms

なので例えば、Management Consoleから見た時にLambdaの設定が以下のような場合、実行ロール（今回だとtest-role-o19dxgu5）に付与されている権限の事しかこのLambdaは実行できない

・参考：AWS Lambda 実行ロール
・参考：定義されたランタイム環境変数

Lambda関数作成時にロールを設定する

いずれの場合もIAMのロールを設定する手間は存在するが、個人的にはAWS CLIでやる方が意図しないRoleが作成されたいしないのでいいような気がする

AWS CLI

AWS CLIコマンドで行う場合は、--roleオプションが必須になっているのであらかじめIAMにロールを作成していないとLambda関数が作れないようになっているので分かりやすい（と思っている）

aws lambda create-function --function-name {作成したいfunction名} --role arn:aws:iam::{aws account id(12桁の数字)}:role/service-role/{lambda実行時のロール(execution role)} --runtime {functionのruntime言語バージョン} --zip-file fileb://{zipファイル名} --handler {ハンドラ名(言語指定方法違う)}

・AWS CLIコマンドについて参考：https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html

Management Console

Management Consoleから関数を作成する場合は、特に注意していないとAWS側で勝手に新規でロールを作成し、それがLambda関数の実行時のロールになる

1. https://aws.amazon.com/jp/getting-started/tools-sdks/
   そのため、Lambda関数内でAWS SDKなどのclient¹を使っている場合、AWSのCredentialは環境変数（AWS_ACCESS_KEY_ID・AWS_SECRET_ACCESS_KEY・AWS_SESSION_TOKENなど）から自動的に読み込まれるが、その環境変数は実行ロールの情報でそれが作成される事になる
   （実行ロールを持つ仮想的なユーザが自動で作られ、そのユーザのAWS_ACCESS_KEY_IDやAWS_SECRET_ACCESS_KEYが環境変数に自動的に組み込まれるというイメージでもいいかも） ↩

2. AWS Account Idが同じIAMユーザのアクセスキーIDの初め何文字かはユーザ間で同じなので、自分で作成したIAMユーザのアクセスキーIDではない事という事が分かる
   のように、ASIAxxxxxxxxxxxxxxxxというAWS_ACCESS_KEY_IDが表示されるが、これが実行ロールを持つ仮想的なユーザのAWS_ACCESS_KEY_IDという感じ² ↩

3. iam:CreateRoleを付与しないとか
   ので、Lambda関数を作るユーザのIAMを制限³して新規で意図しないロールが作成されないようにするなどの注意が必要な気がする
   ↩