You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Similar to what we did for setting up GitHub OIDC for AWS IAM access, Terraform Cloud can also be configured so as to assume roles dynamically without storing any credentials anywhere.
This should be a fairly simple module, as all it will do is create the aws_iam_openid_connect_provider for Terraform Cloud, which will look like this:
terraform {
required_providers {
aws={}
tls={}
}
}
datatls_certificatedefault {
# should be configurable for terraform enterpriseurl="https://app.terraform.io"
}
resourceaws_iam_openid_connect_providerdefault {
url=data.tls_certificate.default.urlclient_id_list=["aws.workload.identity"]
thumbprint_list=[data.tls_certificate.default.certificates[0].sha1_fingerprint]
}
This is essentially all that needs doing for the actual infrastructure, but we should also provide an example for usage.
Usage Example
Once this is created, we need to create IAM roles with an assume policy that allows the OIDC provider to assume the given role.
dataaws_iam_policy_documentassume {
statement {
sid="AllowAssumeFromTerraformCloud"effect="Allow"actions=["sts:AssumeRoleWithWebIdentity"]
principals {
type="Federated"identifiers=[aws_iam_openid_connect_provider.default.arn]
}
condition {
test="StringEquals"variable="app.terraform.io:aud"values=["aws.workload.identity"]
}
condition {
test="StringLike"variable="app.terraform.io:sub"values=[
# here we can constrain things fairly specifically, we have the org name, project name,# workspace name, and run phase (plan or apply). we can wildcard too, so that's nice"organization:my-org:project:my-project:workspace:*:run_phase:*"
]
}
}
}
Particularly of note is that we can get extremely granular with the permissions here. We can hardcode the org/project/workspace/run phase, or we can wildcard to, say, allow any workspace in a specific org or org/project to assume the role. We can even limit the assume to only be applicable during the plan phase or run phase, to provide read-only access during plan.
Terraform Cloud Setup
With this finished, we have to do some configuration of Terraform Cloud. We'll need to set the following environment variables on all workspaces using the OIDC provider to access AWS:
TFC_AWS_PROVIDER_AUTH should be set to true
TFC_AWS_RUN_ROLE_ARN should be set to the ARN of the role to be assumed.
The text was updated successfully, but these errors were encountered:
Docs
hashicorp/terraform-dynamic-credentials-setup-examples
: Sample Code for AWS SetupOverview
Similar to what we did for setting up GitHub OIDC for AWS IAM access, Terraform Cloud can also be configured so as to assume roles dynamically without storing any credentials anywhere.
This should be a fairly simple module, as all it will do is create the
aws_iam_openid_connect_provider
for Terraform Cloud, which will look like this:This is essentially all that needs doing for the actual infrastructure, but we should also provide an example for usage.
Usage Example
Once this is created, we need to create IAM roles with an assume policy that allows the OIDC provider to assume the given role.
Particularly of note is that we can get extremely granular with the permissions here. We can hardcode the org/project/workspace/run phase, or we can wildcard to, say, allow any workspace in a specific org or org/project to assume the role. We can even limit the assume to only be applicable during the plan phase or run phase, to provide read-only access during plan.
Terraform Cloud Setup
With this finished, we have to do some configuration of Terraform Cloud. We'll need to set the following environment variables on all workspaces using the OIDC provider to access AWS:
TFC_AWS_PROVIDER_AUTH
should be set totrue
TFC_AWS_RUN_ROLE_ARN
should be set to the ARN of the role to be assumed.The text was updated successfully, but these errors were encountered: