epomatti/azure-workload-identity-terraform

Azure Workload Identity full deployment with Terraform.

Azure Workload Identity w/ Terraform

Terraform modules to create an AKS Cluster with active OIDC that integrates with Workload Identity, allowing your pods to connect to Azure resources using Azure AD Application.

This example is a Terraform implementation of the Workload Identity Quick Start guideline.

Architecture

The overall architecture of the solution and it's main components that are managed by Terraform.

Project Structure

This project is composed by the following Terraform modules:

• Azure - Create the RG, AKS cluster w/oidc, KV, App Reg, Service Principal.
• Helm - Install the Azure Workload Identity System objects.
• Kubernetes - Create the Service Account and deploy a quick-start workload.

Modules are isolated for individual apply commands, following this warning from the Kubernetes provider.

Deployment Steps

You can deploy this example solution following these steps:

1 - Pre-Requisites

Check the installation docs in Managed Azure Kubernetes Service (AKS) and make sure the required feature flags are enabled.

2 - Project Setup

Create the local variables from the example file:

# Copy from the template
cp .config/example.local.tfvars .local.tfvars

# Set is as relative to work from the modules root
tfvars="../.local.tfvars"

You might want to change the app_name value to avoid conflict with existing resources. Just make sure that kv-${app_name} won't exceed 24 characters, as this is the Key Vault limit.

All other variables are optional and have default values, but you may edit to fit your needs.

3 - Deploy the Resources

Create the Azure Cloud resources:

terraform -chdir="azure" init
terraform -chdir="azure" apply -var-file=$tfvars -auto-approve

Apply the Helm module:

terraform -chdir="helm" init
terraform -chdir="helm" apply -var-file=$tfvars -auto-approve

Apply the Kubernetes module:

terraform -chdir="kubernetes" init
terraform -chdir="kubernetes" apply -var-file=$tfvars -auto-approve

On your own solutions you might choose to use yaml files, but here we are making it everything managed by TF for convenience.

That's it! You can now copy the output aks_get_credentials_command variable to test Workload Identity with the quick-start container.

4 - Test with Workload

Connect using kubectl and check the response:

az aks get-credentials -g "<resource-group-name>" -n "<aks-name>"

kubectl logs quick-start

You should see the output: successfully got secret, secret=Hello!

---

Clean Up

Delete the resources to avoid unwanted costs:

terraform -chdir='azure' destroy -var-file=$tfvars -auto-approve

azure-workload-identity-terraform's Issues

Project setup - wrong directory?

terraform -chdir='helm' apply -var-file=$tfvars -auto-approve
should be

tfvars='../.local.tfvars'

After that, it works!

lock.hcl together with used versions in required providers throw errors

Hi,

thanks for your code! It helps me to implement workload identities.

One thing I have to mention is, that with the hardcoded versions in azure -> in required providers and the terraform.lock.hcl in azure it stops after the terraform plan:

│ Error: expected "object_id" to be a valid UUID, got │ │ with azurerm_key_vault_access_policy.superadmin, │ on main.tf line 112, in resource "azurerm_key_vault_access_policy" "superadmin": │ 112: object_id = data.azurerm_client_config.current.object_id

After removing the versions out of the providers block and removing of the .lock.hcl, it works without errors with the hashicorp/azuread v2.31.0 and hashicorp/azurerm v3.34.0 versions.

So the solution is to remove the lock files here.

Cheers,
Michael