If you’ve ever encountered the following error (or similar) when setting up an AWS load balancer to write its logs to an s3 bucket using Terraform then you are not alone. I decided to write a quick note about this problem because it is the second time I have been bitten by this and had to spend time Googling around for an answer. The AWS documentation for creating and attaching the policy makes sense but the idea behind why you need to do it is murky at best.
aws_elb.alb: Failure configuring ELB attributes: InvalidConfigurationRequest: Access Denied for bucket: <my-bucket> Please check S3bucket permission
status code: 409, request id: xxxx
For reference, here are the docs for how to manually create the policy by going through the AWS console. This method works fine for manually creating and attaching to the policy to the bucket. The problem is that it isn’t obvious why this needs to happen in the first place and also not obvious to do in Terraform after you figure out why you need to do this. Luckily Terraform has great support for IAM, which makes it easy to configure the policy and attach it to the bucket correctly.
Below is an example of how you can create this policy and attach it to your load balancer log bucket.
data "aws_elb_service_account" "main" {}
data "aws_iam_policy_document" "s3_lb_write" {
policy_id = "s3_lb_write"
statement = {
actions = ["s3:PutObject"]
resources = ["arn:aws:s3:::<my-bucket>/logs/*"]
principals = {
identifiers = ["${data.aws_elb_service_account.main.arn}"]
type = "AWS"
}
}
}
Notice that you don’t need to explicitly define the principal like you do when setting up the policy manually. Just use the ${data.aws_elb_service_account.main.arn} variable and Terraform will figure out the region that the bucket is in and pick out the correct parent ELB ID to attach to the policy. You can verify this by checking the table from the link above and cross reference it with the Terraform output for creating and attaching the policy.
You shouldn’t need to update anything in the load balancer config for this to work, just rerun the failed command again and it should work. For completeness here is what that configuration might look like.
...
access_logs {
bucket = "${var.my_bucket}"
prefix = "logs"
enabled = true
}
...
This process is easy enough but still begs the question of why this seemingly unnecessary process needs to happen in the first place? After searching around for a bit I finally found this:
When Amazon S3 receives a request—for example, a bucket or an object operation—it first verifies that the requester has the necessary permissions. Amazon S3 evaluates all the relevant access policies, user policies, and resource-based policies (bucket policy, bucket ACL, object ACL) in deciding whether to authorize the request.
Okay, so it basically looks like when the load balancer gets created, the load balancer gets associated with an AWS owned ID, which we need to explicitly give permission to, through IAM policy:
If the request is for an operation on an object that the bucket owner does not own, in addition to making sure the requester has permissions from the object owner, Amazon S3 must also check the bucket policy to ensure the bucket owner has not set explicit deny on the object
Note
A bucket owner (who pays the bill) can explicitly deny access to objects in the bucket regardless of who owns it. The bucket owner can also delete any object in the bucket.
There we go. There is a little bit more information in the link above but now it makes more sense.
Read More
