Mastering Terraform: A Practical Guide to Building and Deploying Infrastructure on AWS, Azure, and GCP by Mark Tinderholt

Author:Mark Tinderholt [Tinderholt, Mark]
Language: eng
Format: epub
Tags: Computers, Software Development & Engineering, Systems Analysis & Design, Tools, System Administration, Linux & UNIX Administration
ISBN: 9781835088968
Google: P5kUEQAAQBAJ
Publisher: Packt Publishing Ltd
Published: 2024-07-25T22:00:00+00:00

Workload identity

With the cluster provisioned, we need to get the OIDC issuer certificate from the cluster so that we can use it to configure the OpenID Connect provider with AWS IAM. The following code uses the tls_certificate data source from the tls utility provider, which we covered in Chapter 3, to obtain additional metadata about the certificate:

data “tls_certificate” “container_cluster_oidc” { url = aws_eks_cluster.main.identity[0].oidc[0].issuer }

With this additional metadata, we can use the aws_iam_openid_connect_provider resource to connect the cluster to the AWS IAM OIDC provider by referencing sts.amazonaws.com:

resource “aws_iam_openid_connect_provider” “container_cluster_oidc” { client_id_list = [“sts.amazonaws.com”] thumbprint_list = [data.tls_certificate.container_cluster_oidc.certificates[0].sha1_fingerprint] url = data.tls_certificate.container_cluster_oidc.url }

We’ve already set up several IAM roles, including one for the EKS cluster and another for the worker nodes of the cluster. Therefore, I won’t reiterate the creation of the aws_iam_role resource for the workload identity. However, this new role does need to have a very distinct assumption policy. The workload identity IAM role needs to reference the OIDC provider and a yet-to-be-provisioned Kubernetes service account:

data “aws_iam_policy_document” “workload_identity_assume_role_policy” { statement { actions = [“sts:AssumeRoleWithWebIdentity”] effect = “Allow” condition { test = “StringEquals” variable = “${replace(aws_iam_openid_connect_provider.container_cluster_oidc.url, “https://”, “”)}:sub” values = [“system:serviceaccount:${var.k8s_namespace}:${var.k8s_service_account_name}”] } principals { identifiers = [aws_iam_openid_connect_provider.container_cluster_oidc.arn] type = “Federated” } } }

As you can see, in the preceding code, the service account follows a very specific naming convention: system:serviceaccount:<namespace>:<service-account-name>. We replace <namespace> with the name of the Kubernetes namespace and likewise, we replace <service-account-name> with the name of the service account. It’s important to point out that we are referencing resources that do not exist yet. As such, the reference to them within the workload identity IAM role’s assumption policy is a pointer or a placeholder to this yet-to-be-created resource. Both the Kubernetes namespace and the service account are resources that will need to be created within the Kubernetes control plane. We’ll tackle that in the next section using the kubernetes Terraform provider.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.