Vault-Backed Dynamic Credentials

For most use cases, separately configuring dynamic provider credentials with different cloud providers works well. However, Vault-backed dynamic credentials are for those looking for a way to:

1. Use Vault's secrets engines as a centralized way to manage and consolidate cloud credentials management.
2. Generate short-lived credentials without exposing their Terraform Enterprise instance's OIDC metadata endpoints to the broader public internet.

The "Vault-backed" in "Vault-backed dynamic credentials" refers to Vault's secrets engines, which allow you to generate short-lived dynamic secrets for the AWS, GCP, or Azure providers. If you are using Terraform Enterprise and your Vault instance is configured within the same secure network, you can generate secrets while keeping your environment air-gapped.

Vault-backed dynamic credentials combine the features of dynamic provider credentials and Vault's secrets engines. This means you can authenticate a Vault instance using workload identity tokens and use secrets engines on that instance to generate dynamic credentials for the AWS, GCP, and Azure providers.

Configure Vault-Backed Dynamic Credentials

Using Vault-backed dynamic credentials in a workspace requires the following steps for each cloud platform:

1. Set up Dynamic Provider Credentials with the Vault Provider: You must first configure dynamic credentials with the Vault provider.
2. Configure the desired Secrets Engine: You must configure the desired secrets engine in your Vault instance (i.e., AWS, GCP, or Azure).
3. Configure Terraform Cloud Workspace: You must add specific environment variables to your workspace to tell Terraform Cloud how to authenticate to other cloud providers during runs. Each cloud platform has its own set of environment variables that are necessary to configure dynamic credentials.

Setting up Vault-backed dynamic credentials differs slightly for each cloud provider. You can configure Vault-backed dynamic credentials on the following platforms:

• Amazon Web Services
• Google Cloud Platform
• Azure

TFE Specific Requirements

Access to Metadata Endpoints

In order to verify signed JWTs, Vault must have network access to the following static OIDC metadata endpoints within TFE:

1. /.well-known/openid-configuration - standard OIDC metadata.
2. /.well-known/jwks - TFE’s public key(s) that cloud platforms use to verify the authenticity of tokens that claim to come from TFE.

These endpoints do not need to be publicly exposed as long as your Vault instance can access them.

External Vault Policy

If you are using an external Vault instance, you must ensure that your Vault instance has the correct policies setup as detailed in the External Vault Requirements for Terraform Enterprise documentation.