[最終更新] 2018年7月22日
AWSのLambdaでは実行ロールを用いてアクセス制御を行うわけだが、テンプレートポリシーのsimpleMicroServiceRoleを用いると、Cloud Watch LogsとDynamoDBの基本的な操作権限が与えられて便利だ。便利なのだが、Queryの権限がないので(Scanはあるのに)、その権限を追加するメモ。
Queryの権限を与える
AWSのLambdaでDynamoDBを操作したりなんだりするようなものを作ろうとしたとき、既存のロールとしてsimpleMicroServiceRoleあたりを使うサンプルが多いけれど、これはそのままだとdynamodb:Queryの権限がない。dynamodb:Scanはあるのに。
そこで、Queryの権限を与える必要がある。方法としては、simpleMicroServiceRoleの権限をいじるか、あるいはdynamodb:Scanを含むポリシーをアタッチしたロールを作成するか。全体的な影響を考えると、新たにロールを作ったほうが良いと思うが、まぁどちらも本質的にはdynamodb:Scanを含むポリシーをどうするか、というところだろう。
予め用意されているポリシーでは、まずAmazonDynamoDBFullAccessはもちろんQueryを含んでいる。しかし、これは中々強烈なロールなので抵抗がある。読み込みだけであれば、AmazonDynamoDBReadOnlyAccessもある。が、読み込みだけとはいえ明らかに使わない権限をたくさん与えてしまうことには変わりない。
ということで、dynamodb:Queryをもつポリシー作ったほうがよいかなと思うわけだが、既存のポリシーを改変するか、新たに作るか、まぁ新たに作ったほうが綺麗だとは思う。ポリシーはGUIで、IAMのポリシーの作成から割と楽に作れる。

テーブルの権限もちゃんとすべきなのだろうけれど、うちの環境ではまぁ特に問題なさそうだったので「すべて」にチェックを入れた。
で、このポリシーをsimpleMicroServiceRoleにアタッチするか、あるいは新たにロールを作ってアタッチし、そのロールをLambdaに適用するか。まぁ手間を惜しまず新たに作るほうが綺麗なのには違いなかろうが……。
と言いつつ、自分はsimpleMicorServiceRoleにあるポリシー自体を改変して対応してしまった。
LambdaでDynamoDBの権限を確認してみる。

ちゃんと追加されている。
以上。
関連記事
aws の記事
- [2018年8月3日] AWSのLambdaでcronみたいな感じで定期実行する
- [2018年7月31日] LambdaでS3をトリガーにした時にConfigurations overlap. Configurations on the same bucket cannot share a common event type.と怒られる
- [2018年7月31日] Lambdaで、S3に画像がアップロードされたら、別のバケットにコピーする(python3)
- [2018年7月27日] 既存システムにAWSのLambdaで作ったREST APIの認可で手こずる
- [2018年7月24日] S3で特定のバケットを誰でも読み取りできるようにするバケットポリシー
- ---本記事---
- [2018年7月12日] AWS Lambda + API Gateway で/hoge/{group}/{user}のように階層構造のREST APIでパスパラメータの受け渡し
- [2018年7月9日] AWS Lambda + API Gateway でREST APIを作成し、値を渡してDynamoDBに書き込んでついでに返り値を得るサンプル
- [2018年6月28日] AWS S3上のjsonファイルをgetJSONしたらNo ‘Access-Control-Allow-Origin’ header is present on the requested resourceと怒られた時の対応
- [2018年6月19日] AWSのELBでセッション維持の設定(スティッキーセッション)
- [2018年5月31日] MySQLクライアントでAWSのRDSに接続
スポンサーリンク