Adopting Terraform Ephemeral Resources

Scenario 4: Resources or data sources that fetch generated secrets to store in another 3rd party system

There are many situations when a user would like to use Terraform to generate and hand off a secret between 2 3rd party systems. A typical workflow is asking Terraform to generate a API key that will be given to another 3rd party system to give it access. This is currently a feature gap for ephemerals.

Take the example of giving a HCP Terraform API token to give to another tool (GitHub Pipeline, auditing tool, etc):

resource "tfe_team_token" "test" {

  team_id     = tfe_team.test.id

  description = "my team token"

}

Although you may think an ephemeral resource for this could fix the issue, it sneakily does not. Heres why:

ephemeral "tfe_team_token" "example" {

  team_id = tfe_team.example.id

}

The above code would execute every plan & apply and delete the token at the end of the run. This means that for normal terraform run workflow, 2 team tokens would be generated and deleted. Even if you gave the token to a 3rd party system (AWS secrets manager), the value would be stored but the key deleted.

As stated above, these ephemerals can be used to authenticate providers. This is commonly done with the value dynamic credentials backends:

ephemeral "vault_terraform_token" "tf_token" {

  role_name = "tfe_admin"

}



provider "tfe" {

  token = ephemeral.vault_terraform_token.tf_token.token

}

Closing

This blog walked you through the scenarios and solutions you will encounter when trying to remove secrets from your Terraform statefile.

If you would like a way to detect when your workspaces are using resources that store secrets in state, check out this Sentinel Ephemerality Policy.