Terraform-provider-aws: Decryption of aws_kms_secret is not correct when using it in other resources

[hashibot]

_This issue was originally opened by @MattiasGees as hashicorp/terraform#13533. It was migrated here as part of the provider split. The original body of the issue is below._

---

Terraform Version

Terraform v0.9.2

Affected Resource(s)

Please list the resources as a list, for example:

• aws_kms_secret

Terraform Configuration Files

provider "aws" {
  region = "eu-west-1"
}

data "aws_kms_secret" "mysql_password" {
  secret {
    name    = "db_user"
    payload = "<encrypted_key>"

    context {
      mysql = "password"
    }
  }
}

provider "mysql" {
  endpoint = "127.0.0.1:3306"
  username = "root"
  password = "myrootpassword"
}

resource "mysql_user" "user" {
  user     = "db_user"
  host     = "%"
  password = "${data.aws_kms_secret.mysql_password.db_user}"
}

output "db_password"{
  value = "${data.aws_kms_secret.mysql_password.db_user}"
}

Expected Behavior

The user gets created and we are able to login with the password we encrypted with KMS

Actual Behavior

The user gets created correctly but we are not able to login with the mysql password we generated and that was encrypted with KMS. The output of Terraform matches with the original key and gets decrypted correctly. There is probably something wrong with the pass from the data source to the mysql_user user.

When we give the password in plain text to the mysql_user resource it works without any problems and we are able to login to mysql with that user.

Steps to Reproduce

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

1. Create KMS key
2. Encrypt password

echo 'password' > /tmp/plaintext-password
aws kms encrypt --key-id keyid --plaintext fileb:///tmp/plaintext-password --encryption-context mysql=password --output text --query CiphertextBlob --region eu-west-1
rm /tmp/plaintext-password

1. Fill the encrypted value in the terraform example
2. terraform plan
3. terraform apply
4. mysql -u db_user -p

[tanhaa]

Is this bug the reason why I get the following error:

Error modifying DB Instance my_db: InvalidParameterValue: The parameter MasterUserPassword is not a valid password. Only printable ASCII characters besides '/', '@', '"', ' ' may be used.

when using this in a aws_db_instance resource:

resource "aws_db_instance" "my_db" {
  identifier           = "${var.app_name}-${var.env}"
  allocated_storage    = 20
  storage_type         = "gp2"
  engine               = "postgres"
  engine_version       = "9.4.7"
  instance_class       = "${var.db_instance_class}"
  name                 = "mydb"
  username             = "myusername"
  password             = "${data.aws_kms_secret.db.master_password}"
[...]

Or is this not intended to work with the aws_db_instance resource?

Terraform v0.9.8

[ringods]

@tanhaa yes, because the behaviour of this bug is to add a newline at the end of the decrypted value.

[tanhaa]

While this was resolved in #932 and documents updated in #940 helped run it, I noticed that terraform plan would show that the password had changed if i would modify it from a previous "plaintext" password stored in the config to an encrypted one using the kms data source. However, after running apply and examining the state revealed that the password hasn't changed at all. Is that intentional or should a new bug be opened for terraform to not show a change if a previously unencrypted password is changed to an encrypted one in the tf file?

[Ninir]

Hi @MattiasGees,

Could you add the -n option to the echo command and replay your scenario?
As in:

echo -n 'password' > /tmp/plaintext-password

Thanks!

[natan-hoppe]

Hi @Ninir,

I stumbled upon the same problem and tried your suggestion.

Using echo -n 'password' > /tmp/plaintext-password Terraform successfully creates the DB instances.

Using echo 'password' > /tmp/plaintext-password Terraform raises the exception:
Error creating DB Instance: InvalidParameterValue: The parameter MasterUserPassword is not a valid password. Only printable ASCII characters besides '/', '@', '"', ' ' may be used.

Hope this helps.

[MattiasGees]

Yes tested it and echo -n works

[Ninir]

Closing this since the documentation is now reflected the need for echo -n.

[hashibot[bot]]

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!