Request for feedback: Terraform AKS Workload Identity + Azure Key Vault reference implementation

Terraform
1

Hi everyone,

I’ve built a Terraform reference implementation for a secure Azure Kubernetes Service (AKS) Workload Identity pattern and would appreciate technical feedback before its first public release.

The goal is to let a Kubernetes workload access Azure Key Vault without storing a long-lived Azure client secret in the application, Kubernetes manifests, or CI/CD secrets.

The implementation includes:

  • A user-assigned managed identity for the workload
  • A Microsoft Entra federated identity credential tied to one Kubernetes namespace and service account
  • Least-privilege Azure Key Vault data-plane access through Azure RBAC
  • A small verification workload
  • Terraform formatting, validation, linting, security scanning, and tests
  • Architecture, threat model, RBAC, operational, rollback, and release documentation

The intended identity flow is:

Kubernetes workload → service account → AKS OIDC issuer → federated identity credential → managed identity → Azure Key Vault

I would particularly value feedback on:

  1. The workload identity trust boundary and federated credential design
  2. Whether the Key Vault RBAC scope is appropriately least-privilege
  3. Terraform module structure and maintainability
  4. Gaps in testing, documentation, verification, or rollback guidance
  5. Anything that should change before a public v1 release

Repository: GitHub - JbravoI/terraform-azurerm-aks-workload-identity · GitHub

This is based on and improves upon an earlier approach shared by Ned Bellavance, and I have credited that influence in the project post (linkedin).

Thanks in advance

1 Like