Dynamic provider credentials

The Dynamic provider credentials refer to Vault's secrets engines to generate short-lived dynamic secrets for various providers including AWS, GCP and Azure.

Note

HashiCorp recommends that you use these dynamic provider credentials to authenticate to the respective cloud providers instead of static credentials especially for cloud (AWS, GCP, Azure) credentials.

The steps to set up dynamic provider credentials for the cloud providers can be found at:

Why use Vault-backed dynamic credentials?

Vault-backed dynamic credentials include several advantages over using only dynamic provider credentials without Vault:

Consolidated management and auditing for all your cloud credentials and other secrets.
No OIDC setup required in your cloud provider.
Leverage existing Vault secrets engine configurations to generate short-lived credentials.
No need to expose inbound access to self-hosted Terraform Enterprise instances from cloud providers to validate OIDC metadata.

For more details see link

Here is an example to leverage Vault-backed dynamic credentials for authenticating to the AWS provider:

Set the following environment variables in your variable set and attach it to the workspace that requires the AWS credentials.

Key	Value
TFC_VAULT_BACKED_AWS_AUTH	true
TFC_VAULT_BACKED_AWS_AUTH_TYPE	Must be one of the following: iam_user, assumed_role, or federation_token.
TFC_VAULT_BACKED_AWS_RUN_VAULT_ROLE	The role to use in Vault

After setting up the variable set, ensure you are not using any of the arguments or methods mentioned in the authentication and configuration section of the provider documentation. Otherwise, these settings may interfere with dynamic provider credentials.

# Initialize the providers for Vault and AWS.
provider "vault" {
 
}
 
provider "aws" {
  region = "us-east-1"
}

On top of credentials used to authenticate to cloud providers, there are other types of secrets such as credentials to authenticate to database providers (eg: PostgreSQL, MongoDB, Oracle, Snowflake etc.), PKI certificates, SSH keys etc. It is recommended to generate such sensitive information with appropriate TTLs and roles instead of static credentials or secrets and use them as a part of your Terraform configuration.

Here is an example to leverage Vault to fetch dynamic credentials for authenticating to the MongoDB Atlas provider:

# Fetch MongoDB Atlas Credentials from Vault
provider vault {
 
}
 
data "vault_generic_secret" "mongodb_creds" {
  path = "mongodb/creds/access"
}
 
# Use Fetched MongoDB Atlas Credentials to Configure MongoDB Atlas Provider
provider "mongodbatlas" {
  public_key  = data.vault_generic_secret.mongodb_creds.data["username"]
  private_key = data.vault_generic_secret.mongodb_creds.data["password"]
}
 
# Example MongoDB Atlas Resource
resource "mongodbatlas_project" "example" {
  name   = "My Project"
  org_id = var.org_id
}

Here the MongoDB database secrets engine has been mounted at the path mongodb and has a role named access with the right privileges to perform actions in MongoDB. These credentials can be created with appropriate TTLs to expire post use.

Multi-tenancy using Vault-backed dynamic provider credentials can be achieved by leveraging “tags” and “aliases”. Detailed documentation for the setup of multiple dynamic credential configurations can be found here.

Vault Authentication

Reading/Writing Secrets