OIDC Auth AWS & Azure

Satak · February 9, 2022, 1:34pm

Is there some way to authenticate Terraform in Terraform cloud against Azure and AWS by using this new OIDC authentication method? I don’t mean OIDC for user authentication but instead the Terraform itself so it can manage AWS and Azure resources. I would really want to setup Azure and AWS credentials so that I don’t have to store secret key in Terraform cloud but instead just use the AWS assume role and for Azure the client ID. Is this possible or is this in the pipeline coming soon? What about open source Terraform version, is OIDC auth supported for Azure and AWS?

bendrucker · February 17, 2022, 9:42pm

Terraform Cloud does not currently support OIDC. In other words, it’s not signing a token for each run that can be sent to an external service and verified. I’ve submitted a support request inquiring about whether this is being considered.

Terraform providers can support OIDC. The AWS provider already does. EKS relies on OIDC to exchange a projected Kubernetes service account token (which is an OIDC token) for IAM role credentials. There’s a recently opened issue about allowing configuration via provider attributes rather than exclusively via environment variables:

github.com/hashicorp/terraform-provider-aws

Allow AssumeRole with WebIdentity in provider's configuration

opened 08:27PM - 02 Feb 22 UTC

mwieczorek

enhancement provider authentication

### Community Note * Please vote on this issue by adding a 👍 [reaction](https…://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request * Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request * If you are interested in working on this issue or have submitted a pull request, please leave a comment ### Description I'd like to propose better support for AssumeRoleWithWebIdentity in provider configuration. #### Context Recent changes in Github Actions allow using GHA issued JWT token to access AWS (using AssumeRoleWithWebIdentity). I'd like to be able to use JWT to configure provider (or rather multiple providers) and authenticate using AssumeRoleWithWebIdentity. Currently, it is possible to leave `assume_role` block empty and use standard environment variables `AWS_ROLE_ARN` / `AWS_WEB_IDENTITY_TOKEN_FILE` and access AWS this way. But this solution won't work if we'd like to use two or more provider configurations in one Terraform plan but with different roles to assume. (f.e. we want to create and accept VPC peering in one TF plan, or setup Route53 hosted zone delegation to another account, etc.) #### Proposed solution Extend provider's configuration, in particular `assume_role` block, by adding `web_identity_token` argument. Example: ```hcl provider "aws" { assume_role { role_arn = "arn:aws:iam::123456789012:role/my-role" web_identity_token = var.web_identity_token } } ``` If `web_identity_token` is empty, the provider will behave as it does right now. In case `web_identity_token` is not empty, the provider will use AssumeRoleWithWebIdentity (instead of `AssumeRole`) to authenticate, in this case, no AWS credentials are required. #### Additional notes As an alternative solution, we could add a new block like `assume_role_with_webidentity` to the provider's configuration as not all arguments in `assume_role` are supported in `AssumeRoleWithWebIdentity`. I'd prefer to reuse the existing block and add validation to exclude some of the arguments when `web_identity_token` is passed. I looked into the code (if possible/desired I could prepare a PR) and I understand that it will be required to extend https://github.com/hashicorp/aws-sdk-go-base. I plan to open an issue there too when I'll get feedback for this issue. ### References * https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html * https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services

Not sure whether the Azure provider currently supports this. But in any case, it’s up to the provider rather than Terraform core.

To make use of a provider’s OIDC support, you’d have to execute Terraform in an environment capable of issuing OIDC tokens, such as GitHub Actions or an EKS cluster.

ned1313 · May 24, 2022, 7:48pm

This goes beyond just AWS and Azure too. This could enable OIDC auth to Vault and GCP too. No more storing static credentials! I’d really like to see support added by HashiCorp to TFC and eventually TFE.

Satak · September 2, 2022, 4:32am

Now both providers Azure and AWS has generic OIDC auth support, not only GitHub actions. This means Terraform Cloud could have OIDC implemented if Hashicorp would do it. I really, really would like to see this happen.

james1 · September 19, 2022, 1:24pm

Hi, this is an important feature for us. Is it something Hashicorp is working on?

apparentlymart · September 19, 2022, 5:49pm

For those who are interested in Terraform Cloud support for OpenID Connect authentication, I’d suggest sending those requests via HashiCorp Support, since that’s the primary channel that the Terraform Cloud teams expect to receive feedback from.

This forum is instead more aimed at helping folks use the open source parts of Terraform that have no explicit support channel otherwise. Terraform Cloud teams do sometimes participate in discussions here, but it’s primarily to help with using existing Terraform Cloud features rather than to gather feedback about potential new features.

ebrahim.moshaya · October 6, 2022, 3:02pm

This is absolutely a must needed feature… We can’t really switch to remote terraform runs until we have OIDC support.

viliampucik · January 31, 2023, 6:55pm

Terraform Cloud just added beta support of OIDC called as dynamic provider credentials: https://www.hashicorp.com/blog/terraform-cloud-adds-dynamic-provider-credentials-vault-official-cloud-providers

Satak · February 1, 2023, 6:26am

This is a amazing news! Thanks Hashicorp for implementing this.