IAM権限周り勉強帖

SQSおよびSNSのチュートリアルをやっていて、あれ？ってなった。

前提として

SQSはプル型

SNSはプッシュ型

プル型というのは、普段は待機していて「叩かれるのを待っている」

プッシュ型というのは「自分が叩きに行く（叩かれる側は待っている）」

概ねこんな理解でまずは良いとしたのだが、SQS＋Lambdaのサンプルを見るとSQSのメッセージがトリガーになってラムダが動くので、まるでプッシュ型の動作をしているように見え、ちょっと混乱した。

その時、権限周りがどうなるのか気になった。

まず、プッシュ型のSNSの場合は理解しやすい。

AトピックとB関数があった場合、

AがBに配信しBを起動（Invoke）する必要があるので、リソースベースポリシーが必要になる。

このリソースベースポリシーはIAMの画面で作っても良いが、Aトピックで関数に対するサブスクリプションを作ると自動的に出来上がる。

そしてその内容はB関数の画面でも確認できる。

この場合B関数の実行ロールは関係ない。何しろB関数は受け身なので何も手を加えなくてもいいはず。

問題はSQS＋Lambdaの場合。

Qというキューがあって、C関数に「取りに行かせたい」場合。

「取りに行く」のはC関数なので、C関数の実行ロールに

“sqs:ReceiveMessage”,
“sqs:DeleteMessage”,
“sqs:GetQueueAttributes”,

といった権限が必要になる。

じゃQ側は？勝手にCを起動しているように見えるのだが、「トリガー」として動かしているので「ロール」ではなく「信頼性ポリシー」が必要とのことらしい。

これも、SQSのコンソール上で「Lambdaトリガー」を設定すると自動的に出来上がっている（？）少なくとも自ら作成しなくても良い。

その内容は一応C関数の設定画面で確認できる。

最後にIAMロールの読み方だが自分は以下のように日本語化して解いている

{
  "Version": "2012-10-17",
  "Id": "default",
  "Statement": [
    {
      "Sid": "sns-ap-northeast-1-xxxxxxxxxx-MyTopic",
      "Effect": "Allow",
      "Principal": {
        "Service": "sns.amazonaws.com"
      },
      "Action": "lambda:InvokeFunction",
      "Resource": "arn:aws:lambda:ap-northeast-1:xxxxxxxxxx:function:snsReader",
      "Condition": {
        "ArnLike": {
          "AWS:SourceArn": "arn:aws:sns:ap-northeast-1:xxxxxxxxxx:MyTopic"
        }
      }
    }
  ]
}

大きく間違ってはいないと思うが、どうなのだろうか？