resource/aws_rds_cluster_instance: PerformanceInsightsKMSKeyId is not necessarily an ARN

[ColinHebert]

According to the CreateDBInstance documentation, the parameter PerformanceInsightsKMSKeyId can be either a KMS key ARN, a KMS alias ARN or simply a KMS key ID.

In most cases, I would expect people to rely on either the KMS alias ARN or the key ARN, but because of the way data.aws_kms_key works, some users might end up with a raw key ID (not the ARN).

In this case the cluster instance creation will fail as the validation ensures that the performance_insights_kms_key_id is an ARN.

As a side note, the terraform documentation also mentions that we expect "The ARN for the KMS key to encrypt Performance Insights data.", it is probably worth specifying that an ARN to an alias is perfectly fine as well.

cc @kwent, @Ninir

(introduced in #2331)

[bflad]

Hi @ColinHebert 👋 Thank you for submitting this. While various AWS APIs may support multiple input values for KMS Keys, usually they return the full KMS Key ARN in the response. For two reasons, we typically just require the KMS Key ARN:

• Terraform Providers are expected to not have the attribute value change between a plan (the configuration value in this case) and apply (the API response value in this case). These surface as diffs didn't match errors in Terraform 0.11 and earlier or Provider produced inconsistent result after apply errors in Terraform 0.12 when attempting to reference attributes that change like this. This is a fundamental design principal in Terraform and the Terraform AWS Provider must follow suit to prevent those errors.
• Even without downstream references to the attribute that would generate the above errors, operators configuring the KMS Alias Key/ARN or Key ID will see a difference in their next Terraform run for the resource unless they also configure the lifecycle configuration block ignore_changes meta-argument. We would prefer to skip the complexity of documenting this every place where multiple values are possible on input and instead only allow the canonical input that would not require this workaround and potential confusion.

The aws_kms_alias data source and resource were augmented since this pull request was filed with a target_key_arn attribute to make these types of configurations easier and the usage of that is the preferred configuration method in these cases.

Since we would prefer not to introduce the above problems and ambiguity into resources, we are going to close this. Thanks again for this submitting this.

[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!