S3 destination kms key not selected

[ghost]

This issue was originally opened by @guganscode as hashicorp/terraform#17740. It was migrated here as a result of the provider split. The original body of the issue is below.

---

Have a terraform testing configuration, terraform is able to apply the changes but no kms key is selected for the replication.

replication_configuration {
role = "${var.s3iamrole}"

rules {
    prefix = ""
    status = "Enabled"
    source_selection_criteria = {
                sse_kms_encrypted_objects={
                    enabled=true
                }
                 
    }
    destination {
        bucket        = "${var.destination}"
        storage_class = "STANDARD"
        replica_kms_key_id = "${var.destinationkms}"
    }
}

}

[thomaslarsen]

Would it be possible to get an update on this bug. It is causing a huge pain with our deployment.

Before Terraform added support for defining the KMS key for S3 bucket replication of encrypted objects, we had to enable this manually through the AWS console. This worked fine, and we could still manage other aspects of the S3 buckets.
However after this has been added, Terraform now wants to remove the replication settings we have enabled through the console.

This leaves us in a bit of pinch, as we can't get it managed by Terraform because of this bug, but we also can get a clean Terraform run because of the manually applied changes...

[dperdikou]

Any update on this?

[alstard]

Hello - Do you have any update for this issue please?

[cassiomoreto]

Is someone looking to this issue? :(

[fernandoiury]

+1

[rafops]

This is a bug with AWS, not the provider. I checked the source and everything looks correct. Additionally, I experimented creating the resources with Terraform and checked the API output with aws s3api get-bucket-replication. For my surprise, the configuration shows up in the output:

...
      "Destination": {
        "EncryptionConfiguration": {
          "ReplicaKmsKeyID": "arn:aws:kms:…"
        },
...

But doesn't show up in the console. After selecting the key via console, the API output looks exactly the same, but replication just works fine.

[TimOrme]

@rafops this threw me a bit as well. It turns out that when you enter via the console it is also updating the replication role policy for that bucket.

In my case, I wasn't properly setting the correct encrypt and decrypt permissions for the replication role; it needs decrypt on the source key and encrypt on the replication key. I also needed to add a few additional permissions as well, that I missed the first time.

These are all added when you setup replication via the console. If you look at your replication role after saving in the console, it will have an additional policy which has the needed permissions.

[thomaslarsen]

Quick followup (might be useful for others):

The issue I raised above was based on a misunderstanding of where the list of KMS keys needed to decrypt objects in the source S3 bucket is applied.
When looking at the AWS console, it implies that this list of KMS keys are part of the replication settings themselves as they are selected when setting up the replication.
This is not the case. When you setup the replication in the AWS console, AWS will take these keys and apply them to policy associated with the replication role.

This issue explains how to manage this correctly when setting up the replication of encrypted objects using Terraform: #6046

Lastly, this issue is actually not related to what I just described here...

[bflad]

Hi folks 👋 It appears the answer to the original report was solved with this comment: #6046 (comment)

There is also additional information in the comments above.

Since Terraform seems to be doing what it is should be doing and we would not attempt to perform additional API actions outside the given configuration, we are going to opt to close this issue. If you have suggestions for how to improve the documentation for handling S3 Bucket replication, please feel free to submit a new GitHub issue. Thanks!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!