Documentation · Infrastructure runs

Dynamic provider credentials

Authenticate a run to GCP, AWS or Azure with no static key. The issuer, the metadata endpoints, and the one subject-format difference from HCP Terraform.

Dynamic credentials let a run authenticate to your cloud without a static key stored anywhere. Instead of a secret, we mint a short-lived token for each plan and apply, your cloud verifies it against our public keys, and hands back temporary credentials scoped to that run.

Nothing long-lived is stored, and the permissions can be scoped to the organisation, the workspace and the run phase rather than to "whatever this key can do".

1. We generate a token for the run and configure the provider to present it.

2. Your cloud fetches our public keys and verifies the signature.

3. Your cloud returns temporary credentials.

4. The plan or apply uses them.

5. They are discarded when the run ends.

This is the Terraform Cloud implementation, using the same environment variables in the same way, including the form for configuring several provider blocks. Follow HashiCorp's documentation for your cloud and set the variables on the workspace.

GCP, AWS and Azure are supported.

Two things are ours rather than theirs, and both are places their instructions ask you for a value:

The issuer is https://tf.runners.io. Wherever the provider's setup asks for an issuer, an OIDC provider URL or an identity-pool issuer, that is the value.

The metadata endpoints are:

Both are public, so a cloud provider can reach them without anything being opened up on your side. GCP additionally lets you upload the key rather than fetch it, if you prefer a pool that never makes an outbound request:

curl https://tf.runners.io/.well-known/jwks -o key-to-upload.json

You do not generate a key pair. That step in the self-hosted instructions is ours to do and we have done it.

HCP Terraform has projects and we do not, so the subject has one fewer segment:

Any IAM condition, trust policy or attribute mapping you copy from their documentation needs the project: segment removed. This is the single most common reason a first attempt fails: the trust relationship is correct in every other respect and the subject simply does not match, which most clouds report as an unhelpfully generic refusal.

Their example configurations reference projects for the same reason and need the same edit.