Terraform plan file contains sensitive keys

[gidesh]

This is not an issue rather asking for a recommendation.

We use terraform to create our infrastructure in google cloud and also to create service account and its keys.

We use gitlab CI/CD to run terraform plan and terraform apply as two separate jobs.

The terraform-plan job outputs a plan file that we pass on as an artifact to the terraform-apply job.

It has come to our notice that the terraform plan file is in a zip format and contains a tfstate file that contains all the information including the service account keys which are sensitive. As this terraform plan file is passed on as an artifact in the GitLab job, this artifact is available to everyone in our organization.

Can you recommend any workaround or best practices for us so that the terraform plan file does not have this sensitive data?
We have thought of using Google KMS in the terraform-plan job to encrypt the plan file before passing it as an artefact to the terraform-apply job and the terraform-apply job decrypts the plan before applying the plan.

Can you suggest a better solution to this?

[apparentlymart]

Hi @gidesh!

For this sort of open-ended discussion I think the community forum would be a better location, because there are more folks there who can share their different approaches, whereas issues here are typically monitored only by the core development team.

With that said, indeed both saved plan files and the resulting state will contain sensitive information if you are working with sensitive information in your Terraform configuration. Saved plan files in particular are in effect a serialization of Terraform's full in-memory model of a plan, so they include everything that Terraform Core "knows".

Given that, you'll need to protect the saved plan files in similar ways to how you protect other sensitive information in your system. I can't recommend specific technology for this because there are many variations, both including encryption techniques as you described here and also authorization-based solutions (assuming you control the stack enough), all of which have different tradeoffs. Using a key management service to encrypt and then later decrypt the plan file does seem like a plausible direction though, as long as you set it up in a way that's compatible with your threat model.

(An example of a potential threat model caveat I'd think about here: CI/CD systems are often one of the first places we run third-party code when introducing it into a system, and so one possible threat is that an attacker poisons your dependencies in a way that causes your CI system to run malicious code. In that case, could the attacker escalate access in order to be able to decrypt your plan files using the same KMS credentials that the trusted jobs use? Tightly scoping which particular jobs have access to the KMS credentials could potentially help mitigate that particular threat, but the details will likely depend on exactly which software you choose and how you configure it.)

Since this is an open question about different ways to solve a general problem, rather than a specific feature request or bug report, I'm going to close the issue. Please do start a topic in the community forum if you'd like to hear more answers from the community about this topic. Thanks!

[github-actions]

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.