Why no rsaencrypt or keybase encrypt ?

[gtmtech]

Current Terraform Version

Latest

Use-cases

I am using a resource which produces a secret. I want to handle this secret in a sensitive way, therefore I want to output it in an encrypted form.

For example:

output "my_secret" {
    value = encrypt(aws_my_resource.foo.plaintext_secret)
}

I realise that because its unencrypted in the resource attributes, it will be unencrypted in the statefile. I understand the things that sensitive and nonsensitive give you. However these just obscure data, and what I want is to take an output and safely communicate it to someone who has the private key to decrypt it.

I notice there is an rsadecrypt but no corresponding rsaencrypt which would be ideal. Or what would be even better, is to use keybase or gpg to encrypt via a publicly available public_key so that only the user with the private key can decrypt the output. Much like the way aws_keypair works.

However, I want that feature for any arbitrary output, even if its source comes from a non-encrypted source.

Attempted Solutions

None as yet

Proposal

Implement equivalant of keybase encrypt or gpg encrypt on arbitrary strings, as a function - that can be used by the user anyway they wish.

[crw]

Hi @gtmtech, thanks for the feature request! There is an on-going conversation about creating some mechanism to define "function providers," and cryptographic functions are one of the obvious candidates for external (not built-in) functions.

For a bit more info, please see: #28855 (comment), specifically:

We're being pretty cautious about adding new functions that overlap with existing use-cases because Terraform has grown quite an unwieldy collection of builtins over the years, and so we've been considering various ways to allow for externally-defined functions (e.g. #2771) to avoid continuing to grow that set. However, that's not something we'll be working on in the very near future, due to our current focus being elsewhere, so we'll revisit this at a later time and post any updates in those other issues.

There is also some conversation around this in #28209, in terms of examples of functions we think would be reasonable to be built-in functions.

I don't have any specific updates to share on this discussion, and will leave this ticket open to revisit in the future when we have gotten further in discussion and/or development of external functions.

[apparentlymart]

For the keybase portion in particular, it should be possible in principle to write a provider wrapping the Keybase API to perform this functionality.

It looks like the model of the Keybase API is that the client retrieves the key from the API and does the actual encryption operation locally, so I expect this would end up being a more involved Terraform provider than most in that it won't just be a thin wrapper around the remote API, but the Keybase Go library seems to encapsulate the client-side functionality needed to perform encryption and signing operations.

So far, aside from some early mistakes like the bcrypt function (which we maintain only for backward compatibility) we've found it's typically better to represent encryption as a managed resource rather than as a plain function, because encryption is typically combined with adding a salt to minimize the possibility of known cleartext attacks and a Terraform resource is able to maintain state about the salt so it can avoid regenerating a different encrypted string on each run.

Since Terraform already has an open ecosystem of providers, I'd suggest pursuing the development of a provider if you need this functionality today. As @crw mentioned, we are also considering allowing providers to contribute normal functions in future too, but the Terraform language design requires functions to behave as pure functions and so a random-salt-based encryption operation would not be suitable for implementation as a function.