Feature Request | can OIDC be added to the provider

[scott-doyland-burrows]

Would it be possible to get OIDC on the roadmap for provider authentication.

We'd like to authenticate from Terraform Cloud to Cloudsmith using OIDC.

It doesn't look like the provider supports OIDC at all?

I know Cloudsmith can use OIDC, but we have only just started to use Cloudsmith so I am not sure if this would need just a provider change, or also a change to Cloudsmith?

Something similar to this please:
https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials/aws-configuration

[cloudsmith-iduffy]

Hi Scott,

Great news! What you're looking to achieve is already possible by combining Terraform Cloud's workload identity token generation with Cloudsmith's OpenID Connect functionality.

Let me walk you through the implementation I've created. I've set up a complete working example in my repository at terraform-cloud-oidc, which demonstrates how to exchange a Terraform Cloud JWT for a Cloudsmith JWT using a data provider.

The setup process involves two main components:

First, we need to configure the OIDC provider in Cloudsmith. Based on the JWT specifications detailed in Terraform Cloud's documentation, I've configured the Cloudsmith OIDC provider with these settings:

Provider URL: https://app.terraform.io
Claims Configuration:
{
    "aud": "cloudsmith",
    "terraform_organization_name": "iduffy-demo"
}

Second, we need to enable the workload identity feature in Terraform Cloud. This is done by setting an environment variable named TFC_WORKLOAD_IDENTITY_AUDIENCE with the value cloudsmith.

Once these components are in place, the system works seamlessly: when your Terraform code executes in Terraform Cloud, it automatically uses the data resource to obtain a Cloudsmith token, which is then passed to the Cloudsmith provider. You can find more details about this process in the Manually generating workload identity tokens documentation.

Please let me know if you'd like me to clarify any part of this setup or if you have questions about implementing it in your environment.

[scott-doyland-burrows]

Thanks. That worked.

It would be nice if this could work without the need for using the bash script though.

Our organization is looking to prevent local-exec and the external data resource from running when we use terraform cloud, as there are security risks with this, ie it is possible to display sensitive variables in clear text.

[cloudsmith-iduffy]

It would be nice if this could work without the need for using the bash script though.

Agreed! Will discuss this with the team and see what we can come up with. Copying something along the lines of the AWS_WEB_IDENTITY_TOKEN_FILE used in the AWS credentials provider chain would be nice.

Our organization is looking to prevent local-exec and the external data resource from running when we use terraform cloud, as there are security risks with this, ie it is possible to display sensitive variables in clear text.

That is completely fair. The tokens are short lived and ideally any terraform state is stored encrypted at rest but totally understand that potential exposure - sadly data resources to my knowledge can't be marked as sensitive.

Another alternative is to use hooks to fetch and place the temporary credential into a TF_VAR environment variable https://developer.hashicorp.com/terraform/cloud-docs/agents/hooks - sadly this looks to require terraform cloud enterprise.

[scott-doyland-burrows]

Just to clarify the reason there is concern re local-exec and the external data resource.

It makes it possible for someone with write access to a GitHub repo, to create a feature branch, put a local-exec (or external data resource) in the code, then create a GitHub tag and cause that code to be executed (if using a VCS workspace running on tag creation).

If they run a "printenv" from the local-exec, it will print out all envars including sensitive variables.

So, the concern isn't a short lived cloudsmith token, it is really around tokens that are static until we rotate them, such as cloudflare tokens.

If we give someone access to the repo and access to review plans and applies, then they can access sensitive variables.

But as you say, it's not currently possible to prevent certain terraform resources from being executed.