[やってみた]EventiBridge Pipesが生成するロールとポリシーを確認してみた

はじめに

CX事業本部の佐藤智樹です。

今回はEventiBridge Pipesでいくつかのパターンでパイプを作成し、どんなロールが生成されるのか確認してみました。EventBridge Pipes(以降Pipes)自体の役割は分かっていたのですが、どのように各リソースに対して権限を持つのか分からなく、CloudFormationでPipesを生成する場合にロールは自動生成にならなかったロールは自動生成にならなかったのでまず何ができるのか確認してみました。

結論

Pipesは、各ソース(Source)、強化(Enrichment)、ターゲット(Target)で設定したサービスに対するオーケストレータとなるため、ソースからはイベント情報の取得、強化/ターゲットにはイベント情報の通知を行うために必要な最低限の権限だけが与えられます。図で示すと以下のような関係になります。

上の概要図はソースとしてDynamoDB Streamからデータを取得し、強化でAPI Gatewayを実行し、ターゲットとしてLambdaを実行する場合です。Pipesをコンソールから作った場合、ソース、強化、ターゲットごとに個別のポリシーが生成され、Pipesに紐付けられたロールにポリシーが付与されます。ポリシーは最小権限の原則に沿ったリソースやアクションが設定されます。詳細が気になる場合は後半を確認ください。

Pipesを作ってみる

以下の2つのパターンでパイプを作ってどんなロールやポリシーが作成されるのか、ターゲットなどを変更時にロールやポリシーに再反映できるのかを確認します。

• パターン1：SQS(ソース)→Lambda(ターゲット)
• パターン2：DynamoDB Stream(ソース)→フィルター→API Gateway(強化)→Lambda(ターゲット)

パターン1

SQS(ソース)→Lambda(ターゲット)でパイプを作成してみます。フィルターと強化は省いて最低限の状態で何が生成されるのかを確認します。実際にパイプを作成するとAmazon_EventBridge_Pipe_{パイプ名}_{ハッシュ値}のサービスロールが生成され、それぞれのソースターゲットごとにポリシー名{リソース名}Pipe{Source|Target}Template-{ハッシュ値}のポリシーが生成されます。以下は全体の概要図です。

ポリシーはそれぞれ以下のようになっています。

SQS用Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sqs:ReceiveMessage",
                "sqs:DeleteMessage",
                "sqs:GetQueueAttributes"
            ],
            "Resource": [
                "arn:aws:sqs:ap-northeast-1:123456789012:sample-queue"
            ]
        }
    ]
}

Lambda用Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "lambda:InvokeFunction"
            ],
            "Resource": [
                "arn:aws:lambda:ap-northeast-1:123456789012:function:sample-lambda"
            ]
        }
    ]
}

上記ポリシーは必要なソースからのデータ取得に必要なアクションと対象リソース、ターゲット実行に必要な最低限のアクションと対象リソースに自動で設定されるため最小権限の原則を自動で満たすことができます。

パターン2

次はDynamoDB Stream(ソース)→フィルター→API Gateway(強化)→Lambda(ターゲット)でパイプを作成してみます。こちらはフィルターと強化を追加して内容を確認してみます。

概要図は以下のようになります。(再掲)

ロール名やポリシー名の規則はパターン1と変わらず、強化に対するポリシーもターゲットと同じようなポリシー名になるという部分だけが新しい内容でした。次に実際のポリシーを確認します。

DynamoDB Stream用Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:DescribeStream",
                "dynamodb:GetRecords",
                "dynamodb:GetShardIterator",
                "dynamodb:ListStreams"
            ],
            "Resource": [
                "arn:aws:dynamodb:ap-northeast-1:123456789012:table/pipe-sample/stream/2023-01-03T13:22:12.773"
            ]
        }
    ]
}

API Gateway用Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "execute-api:Invoke",
                "execute-api:ManageConnections"
            ],
            "Resource": [
                "arn:aws:execute-api:ap-northeast-1:123456789012:xxxxxxxxxx/prod/*"
            ]
        }
    ]
}

Lambda用Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "lambda:InvokeFunction"
            ],
            "Resource": [
                "arn:aws:lambda:ap-northeast-1:123456789012:function:sample-lambda"
            ]
        }
    ]
}

上記ポリシーはパターン1と同じようにデータを取得/イベント実行するための最小限のポリシーで設定されていました。API Gatewayはprod配下*になっています。prod配下のエンドポイントも指定してみましたが、ポリシーのリソース対象の設定はこれ以上詳細には設定されませんでした。

おまけ：パイプを編集した場合のロールについて

ソース、強化、ターゲットの内容を変更した場合、パイプ自体の更新を行っても作成済ロールの更新は発生しませんでした。もしターゲットの対象を変更する場合はロールを再作成する必要があります。「設定」の「編集」で「許可」から「この特定のリソースについて新しいロールを作成」を選択し、ロールを再作成します。

これにより、現在のパイプの状態に合わせて最小権限の原則に沿った最適なロールが生成されます。ただし、昔生成したロールは残り続けるので適宜削除してください。

所感

ちょっとした内容ですが記事にしてPipesとロール/ポリシーの関係を再確認しました。CDKやCloudFormationとPipesを組み合わせる場合参考になるかと思います。Pipes自体がCDKのL3 Constructと思想的には近いと思うのでうまく組み合わせる方法も検討していきたいです。

サーバレスに対する最初のハードルがリソース間のロール設定になるので、このロール自動生成機能でうまくハードルが下げられると面白そうです。この記事がどなたかのお役に立てば幸いです。