Using KMS_Key_alias for EBS encryption always recreate the EBS volume

[bnightstar]

Hi there,

I have an issue with EBS volumes KMS encryption.

I'm trying to create a module for EBS volume with KMS encryption. I want to use default aws/ebs key and be able to replace it with another key in case of need. Since key arns are linked to the account I didn't want to use full arns because I can't hardcode it in module variables.tf file since the variables block doesn't have interpolations i can't construct the arn dynamically ether I want to use this module in a lot of different AWS accounts. Instead, I decided to use data aws_key_alias to get the arn dynamically from alias/aws/ebs and provide the alias name with variable with default value alias/aws/ebs and change it when I invocate the module.

However I run into a bug where using kms_key_alias.arn cause the EBS volume to be recreated each time because the key_id of the key is different than the key_id of the alias.

Please Advice how this problem should be handled.

Terraform Version

Terraform v0.11.0

• provider.aws v1.3.1

Affected Resource(s)

Please list the resources as a list, for example:

• aws_ebs_volume

Terraform Configuration Files

data "aws_kms_alias" "key" {
  name = "${var.kms_key_alias}"
}

resource  "aws_ebs_volume" "ebs_volume_name" {
  availability_zone = "${var.availability_zone}"
  size = "${var.ebs_volume_size}"
  type = "${var.ebs_volume_type}"
  encrypted = "true"
  kms_key_id = "${data.aws_kms_alias.key.arn}"
  #tags = { "Name" = "${var.ebs_tag_name}",
  tags = { "Service" = "${var.ebs_tag_volume}"
}
}

Expected Behavior

Encrypting with KMS Alias ARN should work

Actual Behavior

When EBS is encrypted with KMS Alias ARN the aws_key_id is rebuild each time:

-/+ module.add_volume.aws_ebs_volume.ebs_volume_name (new resource required)
id: "vol-078ab0eee324219ab" => (forces new resource)
arn: "arn:aws:ec2:eu-west-1::volume/vol-078ab0eee324219ab" =>
availability_zone: "eu-west-1a" => "eu-west-1a"
encrypted: "true" => "true"
iops: "" =>
kms_key_id: "arn:aws:kms:eu-west-1::key/cd164727-b4ef-4d8d-bedc-bb6a8f084814" => "arn:aws:kms:eu-west-1::alias/fori_test_kms_key" (forces new resource)
size: "5" => "5"
snapshot_id: "" =>
tags.%: "1" => "1"
tags.Service: "hristofor_test_ebs_volume_encrypted" => "hristofor_test_ebs_volume_encrypted"
type: "gp2" => "gp2"

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. create kms_alias
2. use data kms_alias to get arn.
3. us arn from kms_alias for ebs volume
4. run terraform plan
5. run terraform apply
6. run terraform plan agian
7. ebs volume got recreated.

[bflad]

Sorry you're having trouble with this. As a workaround (at least until the key is rotated), you should be able to recreate the alias's key ARN via:

"${replace(data.aws_kms_alias.XXX.arn, data.aws_kms_alias.XXX.name, "key/${data.aws_kms_alias.XXX.target_key_id}")}"

See also: #2009

[bnightstar]

Thank you this workaround seams to work.

[ebarault]

hi @bnightstar, @bflad,
I'm joining the discussion here as i'm also trying to work with kms encryption at rest and kms aliases.

While the workaround works while the actual key cryptographic material does not change, how could this possibly be a reliable fix as, as soon as you'd be changing the actual KMS key, the EBS in your example would still require the former key to be decrypted... and so even if terraform at some point does accept not to create new resources because the KMS key alias does not change, you would find yourself in a situation where the volume and the new KMS key would not fit together.

Am i missing something here in your rationale?

[bflad]

Ran across this older issue which I commented on before I was a full time maintainer with the project. It turns out we eventually implemented a target_key_arn attribute on the aws_kms_alias data source back in February, which fits this exact use case. With that, this issue should be resolved.

As for when the key associated with the alias changes, most operators will opt to implement ignore_changes or go back and switch directly to coding old key itself, to keep their configuration from destroying old resources.

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