Friday, December 13, 2024

Access AWS from HCP Terraform with OIDC federation

Share


Storing access keys in HCP Terraform poses a security risk. While HCP Terraform secures sensitive credentials as write-only variables, you must audit the usage of long-lived access keys to detect if they are compromised. Not only is leaking the access key a risk, but many organizations have a policy to block the creation of such access keys.

Fortunately, in many cases, you can authenticate with more secure alternatives to access keys. One such alternative is AWS IAM OIDC federation, which uses identity and access management (IAM) to grant external identities (such as HCP Terraform) the ability to assume an IAM role.

HCP Terraform’s dynamic provider credentials allow Terraform runs to assume an IAM role through native OpenID Connect (OIDC) integration and obtain temporary security credentials for each run. These AWS credentials allow you to call AWS APIs that the IAM role has access to at runtime. These credentials are usable for only one hour by default, so their usefulness to an attacker is limited.

This brief tutorial will show you how to set up an OIDC provider and access AWS from HCP Terraform using dynamic provider credentials and OIDC federation.

»

method available to authenticate to your AWS account.

»

S3 buckets, or EC2 instances.

In the aws_iam_policy_document, define a condition that evaluates the OIDC subject claim for HCP Terraform organization, project, workspace, and run phase. The subject claim in the example searches for specific organization, project, and workspace. However, you can make the claim more flexible by using wildcards (*), such as organization:ORG_NAME:project:PROJECT_NAME:workspace:*:run_phase:*.

This claim allows for matching of all workspaces and run phases within a specific HCP Terraform project and organization, which can be helpful in scenarios like using HCP Terraform’s no-code modules to provide self-service infrastructure, where workspace names may not be known in advance.

Note that wildcards in OIDC subject claims can simplify access policies but introduce potential security risks. To balance flexibility and security, use wildcards carefully. While you can scope claims down to a specific HCP Terraform workspace or run phase for maximum security, wildcards can be used selectively to replace certain values, offering a compromise between granularity and convenience.

You can add additional permissions to an IAM role by using the aws_iam_policy_document data source and the aws_iam_policy resource. See the example below:

data "aws_iam_policy" "s3_full_access" {
  arn = "arn:aws:iam::aws:policy/AmazonS3FullAccess"
}
 
resource "aws_iam_role_policy_attachment" "example_s3_full_access" {
  policy_arn = data.aws_iam_policy.s3_full_access.arn
  role       = aws_iam_role.example.name
}

»

ARN that HCP Terraform should assume at runtime.

resource "tfe_variable" "tfc_aws_provider_auth" {
  key          = "TFC_AWS_PROVIDER_AUTH"
  value        = "true"
  category     = "env"
  workspace_id = tfe_workspace.example.id
}
 
resource "tfe_variable" "tfc_example_role_arn" {
  sensitive    = true
  key          = "TFC_AWS_RUN_ROLE_ARN"
  value        = aws_iam_role.example.arn
  category     = "env"
  workspace_id = tfe_workspace.example.id
}

HCP Terraform will automatically assume the IAM role and inject the temporary credentials for you, using the workspace environment variables, allowing you to focus on creating infrastructure.

»

HCP Terraform variable set. This enables the platform/cloud team to create HCP Terraform workspaces with pre-configured AWS authentication, scoped to a specific IAM role and permissions.

Whether you create an OIDC provider per AWS account, per environment, or use a single OIDC provider, providing pre-configured AWS authentication for teams’ HCP Terraform workspace is a win-win for both the platform/cloud team and the teams they enable to work autonomously.

Below is an example configuration that creates a variable set for a specific IAM role and sets two environment variables. HCP Terraform uses these environment variables to assume the IAM role and obtain temporary security credentials at runtime, injecting them into the provider to enable access to any AWS API allowed by the IAM role’s policies.

First, create the variable set:

resource "tfe_variable_set" "example" {
  name         = aws_iam_role.example.name
  description  = "OIDC federation configuration for ${aws_iam_role.example.arn}"
  organization = "XXXXXXXXXXXXXXX"
}

Next, set up the required environment variables and link them to the variable set:

resource "tfe_variable" "tfc_aws_provider_auth" {
  key             = "TFC_AWS_PROVIDER_AUTH"
  value           = "true"
  category        = "env"
  variable_set_id = tfe_variable_set.example.id
}
 
resource "tfe_variable" "tfc_example_role_arn" {
  sensitive       = true
  key             = "TFC_AWS_RUN_ROLE_ARN"
  value           = aws_iam_role.example.arn
  category        = "env"
  variable_set_id = tfe_variable_set.example.id
}

Finally, share the variable set with another HCP Terraform workspace. This ensures that the targeted workspace receives and uses the environment variables, allowing HCP Terraform to automatically assume the IAM role and inject the temporary security credentials:

resource "tfe_workspace_variable_set" "example" {
  variable_set_id = tfe_variable_set.example.id
  workspace_id    = "ws-XXXXXXXXXXXXXXX"
}

»

»

Dynamic Credentials with the AWS Provider and OIDC federation documentation. Find a more complete example of configuring the AWS IAM OIDC identity provider on GitHub.



Source link

Read more

Local News