ALBアクセスログ保存先のS3バケットポリシー設定時にでてくる3種類のService Principalをまとめてみた

「delivery.logs.amazonaws.com」と「logdelivery.elb.amazonaws.com」、そして「logdelivery.elasticloadbalancing.amazonaws.com」を整理します。
2022.09.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

清水です。ALBのアクセスログはS3に保存されます。この際に書き込み先のS3バケットではバケットポリシーにてアクセス制御がなされます。バケットポリシーの内容についてはApplication Load Balancerのユーザガイドに記載されていますが、過去から現在までに以下3つのService Principalを使ったS3バケットポリシーが記載されてきました。

  1. delivery.logs.amazonaws.com
  2. logdelivery.elb.amazonaws.com
  3. logdelivery.elasticloadbalancing.amazonaws.com

ぱっと見どれも同じようで、ややもすると混乱してしまいそうですよね。本エントリでは3つのService Principalについてそれぞれの用途などを混乱しないように整理してみたいと思います。

1. delivery.logs.amazonaws.com

まず一つ目、delivery.logs.amazonaws.comについて確認しましょう。3つの中で唯一、Principal名にELBやElastic Load Balancingなどが含まれていないものですね。また3つの中で一番目にする機会が多いPrincipal名かと思います。

このdelivery.logs.amazonaws.comですが、従来まではALBのアクセスログ保存用のS3バケットポリシーとして記載することがALBユーザガイドにて案内されていました。ポリシー例が以下となります。(後述しますが、最新のALBユーザガイドではこの記載になっていません。ご注意ください。)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::elb-account-id:root"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::bucket-name/prefix/AWSLogs/your-aws-account-id/*"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "delivery.logs.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::bucket-name/prefix/AWSLogs/your-aws-account-id/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-acl": "bucket-owner-full-control"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "delivery.logs.amazonaws.com"
      },
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::bucket-name"
    }
  ]
}

ポリシーの内容をざっと確認してみましょう。1つ目のStatementはAWS Account Principalです。2つ目、3つ目のStatementにdelivery.logs.amazonaws.comを指定したService Principalが登場します。

2つ目のStatementでは、ACLでbucket-owner-full-controlが指定されている場合のみS3へのPutObjectを許可、3つ目のStatementではS3バケットのGetBucketAclを許可しています。2つ目、3つ目のStatementともに、S3のACLに関するアクセス制御を行っていると言えます。

ところで、S3のACLについては2021年11月30日に無効化ができるようになりました。このS3のACL無効化は推奨項目とされています。

これを受けてか、上記のALBのアクセスログ保存用S3バケットのバケットポリシー例について、最新版のALBユーザガイドでは以下のようにS3のACLに関連する項目、つまりService Principalとして「1. delivery.logs.amazonaws.com」を指定しているものが削除されています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::elb-account-id:root"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::bucket-name/prefix/AWSLogs/your-aws-account-id/*"
    }
  ]
}

Bucket permissions (バケットのアクセス許可) - Application Load Balancer のアクセスログ - Elastic Load Balancing

Attach a policy to your S3 bucket - Enable access logs for your Application Load Balancer - Elastic Load Balancing

この「1. delivery.logs.amazonaws.com」のService Principalを使用したStatementの削除について、いつごろ実施された変更なのか確認してみましょう。Wayback Machineを確認したところ、2022/04/09の段階では「1. delivery.logs.amazonaws.com」のService Principalを使ったポリシーが記載されていましたが、2022/05/10からはなくなっていました。またGitHubの変更履歴では2022/06/21付で変更されていました。

またそもそも、この「1. delivery.logs.amazonaws.com」のService Principalが追加されたポリシーがALBユーザガイドに記載されるようになったのが、2020年初頭ごろのできごとです。

どういった経緯で追加されたのかといった詳細までは確認できませんでしたが、このService Principal「1. delivery.logs.amazonaws.com」を用いたStatementについては、VPC Flow LogsのS3出力や、NLBのアクセスログなどほかAWSサービスのログ出力のためのS3バケットポリシーでも使用されているものです。ALBで一時的にでも、ほかサービスとあわせたログ出力の方式に変更を試みたタイミングがあった、ということでしょうか。

ちなみに、EC2のマネジメントコンソール、ALBの属性画面でアクセスログの設定とともにS3バケットを作成する場合、S3のバケットポリシーには本章で確認したService Principalに「1. delivery.logs.amazonaws.com」を含めたものがまだ使用されていました。S3バケットのACLも無効化されておらず、最新の推奨項目が反映されていない状況なのかな、と推測しています。そしてS3バケットポリシーにこのService Principal「1. delivery.logs.amazonaws.com」のStatementが残っている状態でも、ALBのアクセスログは問題なく出力される認識です。

2. logdelivery.elb.amazonaws.com

続いて2つ目、logdelivery.elb.amazonaws.comです。elbとService Principalにサービス名の略称が含まれていますね。こちらについてはALBユーザガイドにズバリ記載がありますが、AWSをオンプレミスに拡張可能なサービスであるAWS Outposts環境下で使用する際のポリシーで使われています。

{
    "Effect": "Allow",
    "Principal": {
        "Service": "logdelivery.elb.amazonaws.com"
    },
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::bucket-name/prefix/AWSLogs/your-aws-account-id/*",
    "Condition": {
        "StringEquals": {
            "s3:x-amz-acl": "bucket-owner-full-control"
        }
    }
}

Bucket permissions (バケットのアクセス許可) - Application Load Balancer のアクセスログ - Elastic Load Balancing

Attach a policy to your S3 bucket - Enable access logs for your Application Load Balancer - Elastic Load Balancing

Outposts環境下でALBのアクセスログを扱う場合は、S3バケットポリシーにAWSアカウントIDを指定するといった記述方法ではなく、上記のようにService Principal「2. logdelivery.elb.amazonaws.com」を使ったポリシーとなります。Outposts環境を使用するケースは通常のリージョンを使う場合と比べて多くないかと思いますが、特別なポリシー記述方法になる点、覚えておきましょう。

3. logdelivery.elasticloadbalancing.amazonaws.com

3つ目のlogdelivery.elasticloadbalancing.amazonaws.comについてです。「2. logdelivery.elb.amazonaws.com」と比べると先頭のlogdeliveryは同じですが、サービスの略称ではなくフル名称のelasticloadbalancingという文字列が続きます。

最新版のApplication Load Balancers User Guide(英語版)、「Enable access logs for your Application Load Balancer」の項目を確認してみましょう。「Attach a policy to your S3 bucket」に以下ポリシー例があります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "logdelivery.elasticloadbalancing.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::bucket-name/prefix/AWSLogs/aws-account-id/*"
    }
  ]
}

Attach a policy to your S3 bucket - Enable access logs for your Application Load Balancer - Elastic Load Balancing

ALB User Guideの記載の内容をもとに、こちらのポリシーの使い方を確認しましょう。まず以下のリージョンのALBについてはこのポリシーではなく「1. delivery.logs.amazonaws.com」で確認したAWS Account Principalに対してPutObjectを許可するポリシーを使用します。使用頻度が多いと思われる東京リージョン、大阪リージョンなどもこちらに該当します。(ポリシーについても再掲します。)

  • US East (N. Virginia)
  • US East (Ohio)
  • US West (N. California)
  • US West (Oregon)
  • Africa (Cape Town)
  • Canada (Central)
  • Europe (Frankfurt)
  • Europe (Ireland)
  • Europe (London)
  • Europe (Milan)
  • Europe (Paris)
  • Europe (Stockholm)
  • Asia Pacific (Hong Kong)
  • Asia Pacific (Tokyo)
  • Asia Pacific (Seoul)
  • Asia Pacific (Osaka)
  • Asia Pacific (Singapore)
  • Asia Pacific (Sydney)
  • Asia Pacific (Mumbai)
  • Middle East (Bahrain)
  • South America (São Paulo)
  • AWS GovCloud (US-West)
  • AWS GovCloud (US-East)

AWS 1=Principalに対してPutObjectを許可するポリシー

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::elb-account-id:root"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::bucket-name/prefix/AWSLogs/your-aws-account-id/*"
    }
  ]
}

続いて上記のリストに含まれないリージョンについては、本章で確認しているService Principalに「3. logdelivery.elasticloadbalancing.amazonaws.com」を用いたポリシーを使用します。このリージョンについてですが、使用対象としては先日2022/08/29にオープンした中東UAEリージョン (me-central-1)が挙げられています。これから開設されるリージョンについては、このService Principalを使用する記載方法が主流になっていくのかもしれませんね。

なお、上記「Enable access logs for your Application Load Balancer」のページについては、現段階(2022/09/07)で日本語版のページは存在しない状況です。言語選択で日本語を選んでも、「このページはお客様の言語に翻訳されていません。」と表示されます。

Enable access logs for your Application Load Balancer - Elastic Load Balancing

これまで(今日2022/09/07の段階での日本語版ユーザガイド)は1つ階層が上の「Application Load Balancer のアクセスログ」 / 「Access logs for your Application Load Balancer」にバケットポリシー例が記載されてきましたが、最新版では1つ下の階層「Enable access logs for your Application Load Balancer」でバケットポリシー例が記載されるようになっているわけですね。日本語版ユーザガイドもまもなく更新されると思いますが、注意しておきましょう。

なおGitHubで変更履歴を確認してみると2022/09/03付で更新されていたようです。

この「3. logdelivery.elasticloadbalancing.amazonaws.com」のService Principalを使ったポリシー記載方法、従来のAWS Account Principalを使ったポリシーと比べてみましょう。Actionで許可している権限(s3:PutObject)ならびに許可対象のResource(arn:aws:s3:::bucket-name/prefix/AWSLogs/aws-account-id/*)については同様です。ただしアカウントIDの入力の代わりにService Principalを使用するため、リージョンごとにPrincipal部分を書き換える必要がなくなっています。なにより「何に対して操作を許可しているのか」が明確ですよね。現在は中東UAEといった一部リージョンのみの記載方法ですが、既存リージョンにも広がっていくと嬉しいなと思いました。

まとめ

ALBのアクセスログ保存時に使用するS3バケットのバケットポリシーについて、Service Principalを用いる記述方法3つを整理してみました。「1. delivery.logs.amazonaws.com」は通常のリージョンでの使用時に記述されてきましたが、最新のALBユーザガイドでは案内されていない点に注意しましょう。「2. logdelivery.elb.amazonaws.com」はAWS Outposts環境下で使用します。「3. logdelivery.elasticloadbalancing.amazonaws.com」は中東UAEリージョンで使用するポリシー記述方法で、ほかリージョンの記述方法でのAWS Account Principalの代わりにService Principalを使う記法となっています。