Catalogue
Allowing CloudFront and Other S3 Bucket Access Logs to Be Stored via the Log Bucket's ACL

Allowing CloudFront and Other S3 Bucket Access Logs to Be Stored via the Log Bucket's ACL

🌐 日本語で読む

In Terraform, you configure it as follows.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
resource "aws_s3_bucket" "logs" {
# NOTE: S3 logging を有効化する為、 S3 group Log Delivery に権限を付与する
# https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html#grant-log-delivery-permissions-general
grant {
permissions = [
"READ_ACP",
"WRITE",
]
type = "Group"
uri = "http://acs.amazonaws.com/groups/s3/LogDelivery"
}

# NOTE: CloudFront からログ保存できる様、 CloudFront Log Delivery Canonical User に権限を付与する
grant {
id = data.aws_cloudfront_log_delivery_canonical_user_id.current.id
permissions = ["FULL_CONTROL"]
type = "CanonicalUser"
}

# S3 Bucket 所有者に権限付与する
grant {
id = data.aws_canonical_user_id.current.id
permissions = ["FULL_CONTROL"]
type = "CanonicalUser"
}

The CloudFront Log Delivery Canonical User ID Can Now Be Retrieved via a Data Source!

While following the issue below, I found it had been addressed!
https://github.com/hashicorp/terraform-provider-aws/issues/12512

Until now there was no data source, so I had been specifying the string directly. This is very welcome!

Summary

The configuration itself is quick to finish once you know it, but if you don’t, there’s a pitfall where you only notice when you actually try to look at the logs.

If you manage multiple AWS accounts with Terraform, turning this into a module and rolling it out is also effective for preventing configuration omissions.

That’s all.
I hope this is helpful.

kenzo0107

kenzo0107