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:
opened 08:27PM - 02 Feb 22 UTC
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.
3 Likes