encrypt/decrypt interpolation functions

[jasonmcintosh]

Would like to suggest adding a decrypt/encrypt interpolation syntax to support encrypting or decrypting data. The main use case of this would be for allowing output of passwords or sensitive data to things like consul in an encrypted format. Below are some examples....

resource "aws_rds_cluster" "default" {
...
  master_username         = "foo"
  master_password         = "${decrypt("pgp", "PRIVATEKEYBASE64", ${var.password})}"
}

resource "consul_keys" "user_credentials" {
 key {
    path = "mydb/password"
    value = "${encrypt("pgp", "PUBLICKEY", ${var.password})}"
  }
}
output "encrypted_value" {
   value = "${encrypt("pgp", "PUBKEY", ${aws_rds_cluster.default.master_password})}"
}

Of course, state management in the above is still an issue as terraform is storing the unecrypted password in the state file... but at least now we can make sure that output (e.g. to consul) is encrypted.

If i had my true wish terraform would notice anytime "decrypt" was called and mark the attribute "sensitive" and only store a one-way hash in the state file of the input value vs. the clear text.

[mcameron]

+1

Looks like there have been efforts to resolve the state file issues you mentioned: terrahelp

[mcameron]

Possible dup of #15296

[mcameron]

Additionally encrypting the state looks like it's being handled here: #9556

[jasonmcintosh]

@mcameron The terrahelp may work (not checked) but it's not tied to core terraform. Issue #15296 is storing the input encrypted - this is letting terraform encrypt individual pieces (e.g. passwords) in state file (output). And the final one... I would personally disagree with encrypting ALL state - just sensitive entries. Encrypting it all in such a way makes collaboration much more difficult. Using interpolation functions let's you share state (e.g. vpc configuration) with others without worrying about data inside of it.

[mcameron]

Only further point I would make is that if you allow encryption of secrets in terraform code, then it only solves half the problem with the secrets - in terraform state, and leaves the plaintext secret in the code itself.

The decryption function sounds great.

[nbering]

@mcameron I agree on that point. Not having the symmetrical capabilities is why I don't use the encryption features with some of the AWS IAM resources. Helpers were included to encrypt values as a resource, but not decrypt. I understand the concerns about doing it wrong and causing a breach, but I feel like there's always risk associated with handling keys, and making it easy to do fairly well is better than leaving it wide open for someone to do it wrong.

[jasonmcintosh]

@mcameron The normal process would be to use terraform randomization NOT variables passed in. Then state does NOT store the data unencrypted, nor can anyone BUT the end user access the value. @nbering This request would then include a decyrpt function to be able to read it back - standard public key/private key solution.

Note, storing passwords in tfvars file was NEVER a good thing. if you're going to pass variables in, do so like they do with access/secret keys - environment variables or similar (note that's still not secure). It'd always be far better to use randomization style options. What's even better yet would be to do something like Hashicorp Vault, but the above encrypt/decrypt functions would allow most of this to work seamlessly while not breaking the world and existing systems.

[jasonmcintosh]

@nbering Regarding symetric on the IAM resources... see
https://www.terraform.io/docs/providers/aws/r/iam_access_key.html#pgp_key
and
https://www.terraform.io/docs/providers/aws/r/iam_access_key.html#encrypted_secret
and
https://www.terraform.io/docs/providers/aws/r/iam_user_login_profile.html#pgp_key

SO Terraform supports symetric via PGP. However, the problem is that very very few AWS Resources work this way. And it's tied to the AWS resource itself vs. being a more generic implementation. Which is again the reason for these functions as they are generic and can apply to ANY parameter considered sensitive.

[nbering]

@jasonmcintosh Yes, I understand the implementation of the current AWS PGP encryption. I looked into the implementation and it immediately converts the value to encrypted form using public-key only when received from the AWS API before storing it in state. While very secure, this forces users to choose being getting a value that useful in other parts of the config but not secure, or not available at all within terraform, but securely encrypted.

I think this existing feature in itself is probably a valid enough use case to push for the decrypt function to be included.

[mcameron]

The problem with using a random function is that it will be different on every run, so could cause the resource and dependents to get rebuilt for every terraform apply.

[jasonmcintosh]

Except that most of those resource changes don’t trigger a change state they’re only on create

…

-- Jason McIntosh Infrastructure architect Carfax, Inc 573-424-7612

On Nov 22, 2017, at 2:44 PM, Max Cameron ***@***.***> wrote: The problem with using a random function is that it will be different on every run, so could cause the resource and dependents to get rebuilt for every terraform apply. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[mcameron]

So following on from that, how do you trigger a state change when you need to rotate passwords for example?

[jasonmcintosh]

https://www.terraform.io/docs/providers/random/index.html provides a keeper mechanism that when changed forces a recreation of the random. Note, it's possible things have changed - it USED to be that an update to a password field on a number of resources did NOT trigger state changes. I THINK RDS passwords DO trigger state changes however.

**Note, I consider this a "first-phase" solution ** as in it's a start, not the end state. Hashicorp Vault is a SIGNIFICANTLY better resource for managing secrets, but is much more complicated to setup, and doesn't cover all use cases.

[manugarri]

this one is also related #17214