Removal of state security visibility perimeter of access keys

[gtmtech]

Deprecated in 0.12 but already in most providers e.g. google provider v3.

references #516

Since pgp_key was removed, what is the official recommended way now to share state with other developers, but keep certain state from being discovered within a statefile. (e.g. by:

• ability to use terraform_remote_state provider but not let external team read the values of access keys or other critical information
• protecting other members in the same team from seeing aspects of state, when they can see the state.

Now it's been removed, how have you addressed this? Or do you recommend

• where it's important to users they remain on terraform 0.12 and e.g. google < 3.0.0 until such time as there is a solution in place. Or
• all such information is completely extracted from all terraform repos and stored in a separate repo(s) which just contains this information and has to be run via automation with a statefile viewable by nobody. Or
• abandoning use of anything previously supporting pgp_key entirely. e.g. never use google_service_account_key or aws_iam_access_key but instead shell out to a null-resource provider to generate the keys instead, or something like https://github.com/matti/terraform-shell-resource - to store, encrypt and store the pgp version as before. Or
• not do that either since you're deprecating variable use in null_resource local-exec destroy provisioners, so do something else entirely?

Many thanks.

[danieldreier]

@gtmtech I think that this is basically a duplicate of #516 which is a totally valid issue that we hear a lot about. The current status of the state file is that anyone who has access to it can see all of it; there is no selective encryption.

There is no officially recommended way to share state files. Most state files have secrets in them. Most users solve this by storing state in state backends that are encrypted, which limits access to just the people who have access to those backends, e.g. one team.

I'm going to close this for now because it's already recorded as an issue, and having multiple issues tracking the same request will dilute votes and discussion between them. Please don't interpret that as a lack of interest in solving this problem - there are just more legitimate improvements people have requested than we immediately have capacity to build.

Beyond asking for a feature, you're also asking for implementation guidance. That's reasonable, but this isn't the forum for it. We use GitHub issues for tracking bugs and enhancements, rather than for questions. When we've tried to have extensive discussion in here in the past, it has overwhelmed our capacity to track bugs and enhancements, and generally makes it harder to fix the things people are asking for in the first place. While we can sometimes help with certain simple problems here, it's better to use the community forum.

If you want more of a voice in our planning, it would be helpful if you could email me (Terraform Core Engineering Manager, ddreier@hashicorp.com) and Petros (Terraform Core Product Manager, petros@hashicorp.com) a description of your workflows that require state to be shared between different people who are not allowed to see the same credentials. I can't guarantee that this will result in your use case being met, but it would definitely help us understand it. There are a lot of permutations of "handle secrets in state better", and different underlying needs, and it would help to understand what you're after.

[gtmtech]

Thanks @danieldreier , I will chase up through enterprise support channel instead.

[danieldreier]

Oh! I didn’t realize you were running into this with TFE! Yes, that is a better channel. Thank you!

[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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.