Machine ID: Terraform Cloud Workload Identity Delegated Joining

[strideynet]

What would you like Teleport to do?

It should be possible to use Terraform Cloud's Workload Identity to authenticate against the Teleport cluster in order to use the Teleport Terraform Provider.

What problem does this solve?

Having to store long-lived Teleport credentials in Terraform that provide high-levels of access to your cluster.

Details:

• https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials

[strideynet]

Join Method

Terraform Cloud does issue OIDC tokens to plan/apply executions in a similar way to how GitHub does. The information included in this token is rich enough for access control and auditing purposes:

{
  "jti": "1192426d-b525-4fde-9d42-f238be437bbd",
  "iss": "https://app.terraform.io",
  "aud": "my-example-audience",
  "iat": 1650486122,
  "nbf": 1650486117,
  "exp": 1650486422,
  "sub": "organization:my-org:project:Default Project:workspace:my-workspace:run_phase:apply",
  "terraform_organization_id": "org-GRNbCjYNpBB6NEH9",
  "terraform_organization_name": "my-org",
  "terraform_project_id": "prj-vegSA59s1XPwMr2t",
  "terraform_project_name": "Default Project",
  "terraform_workspace_id": "ws-mbsd5E3Ktt5Rg2Xm",
  "terraform_workspace_name": "my-workspace",
  "terraform_full_workspace": "organization:my-org:project:Default Project:workspace:my-workspace",
  "terraform_run_id": "run-X3n1AUXNGWbfECsJ",
  "terraform_run_phase": "apply"
}

Source

It would be fairly trivial with our prior experience to add a tbot compatible join method that integrates with this token.

Executing tbot

One challenge at this current point Terraform Cloud does not provide a simple way to execute arbitrary tasks prior to the plan or the apply stage (unlike other tools such as Spacelift).

It does provide for a "callback" to be run before/after a plan/apply but this does not provide a way to return data to the plan/apply (https://developer.hashicorp.com/terraform/cloud-docs/api-docs/run-tasks/run-tasks-integration) and hence this is not fit for our purposes.

There is also the possibility of using "provisioners" such as local-exec - I believe that this presents additional problems in terms of execution order and this would not officially be supported by Hashicorp.

Therefore, the last remaining possibility is to embed tbot, or parts of tbot, within the Terraform provider. This would produce a user experience that looks a little like:

provider "teleport" {
  # Update addr to point to your Teleport Cloud tenant URL's host:port
  addr               = "mytenant.teleport.sh:443"
  join_method  = "terraform-cloud"
  join_token     = "my-join-token"
}

I'd say this is pretty awesome and magic - and will work in a number of environments as well as Terraform Cloud (such as GitHub). The only join method we could not easily support at this time is token due to the binding between a certificate lineage and the bot user.

To execute this, we'd need to ensure that Machine ID's dependencies were purely on the api module where possible. This is no small task but is something we need to do to support other embedding use-cases without embedding the entirety of Teleport. See https://github.com/gravitational/teleport/issues/32632

[than-pet]

Any updates on this after the completion of https://github.com/gravitational/teleport/issues/32632?

[strideynet]

Any updates on this after the completion of #32632?

We've got an open RFD to embed tbot within Terraform provider which is the first step in this: https://github.com/gravitational/teleport/pull/42868