A workload with no secrets to steal.

A Kubernetes Secret feels like security, but it is just base64 sitting in etcd, copied into pods, and printed into anyone's terminal who runs the wrong kubectl. The moment it exists, it can leak; once leaked, rotating it is a scramble across every place it was pasted. Workload Identity removes the object entirely: the pod presents a short-lived token that Azure trusts because you federated its identity in advance, and Azure hands back exactly the access you granted — no long-lived credential ever touches the cluster.

You will enable that on AKS, tie a Kubernetes ServiceAccount to an Azure Managed Identity, and watch a pod read a Key Vault secret with nothing but its own identity. Then you will close the other half of zero trust — the network — by defaulting the namespace to deny all and allowing only the one path the app actually needs.

Identity you can federate; secrets you can only hope to rotate.

Create a resource group and a small AKS cluster with two capabilities most clusters ship without: an OIDC issuer (so Kubernetes can mint verifiable tokens) and Workload Identity (so Azure will accept them). Capture the issuer URL and your tenant id — you will need both to federate.

# Windows/Git Bash: stop it mangling resource-id arguments (harmless on macOS/Linux)
export MSYS_NO_PATHCONV=1

RG="campux-zt-rg"
az group create -n "$RG" -l eastus

az aks create -g "$RG" -n campux-zt-aks \
  --node-count 2 --node-vm-size Standard_D2s_v3 \
  --enable-oidc-issuer --enable-workload-identity \
  --network-plugin azure --network-policy azure \
  --generate-ssh-keys

az aks get-credentials -g "$RG" -n campux-zt-aks
kubectl create namespace production

# capture the two values federation needs
export OIDC_ISSUER=$(az aks show -g "$RG" -n campux-zt-aks --query "oidcIssuerProfile.issuerUrl" -o tsv)
export TENANT_ID=$(az account show --query tenantId -o tsv)
echo "issuer: $OIDC_ISSUER"

Create a user-assigned Managed Identity — the Azure-side identity the pod will borrow — and a Key Vault holding one secret. Grant the identity read access to that secret and nothing else. This is least privilege written as configuration.

az identity create -g "$RG" -n app-workload-id
export CLIENT_ID=$(az identity show -g "$RG" -n app-workload-id --query clientId -o tsv)

az keyvault create -g "$RG" -n kv-campux-zt --enable-rbac-authorization false
az keyvault secret set --vault-name kv-campux-zt --name db-password --value "SecureP@ssword123"

# the identity may read secrets — get/list only
az keyvault set-policy -n kv-campux-zt --spn "$CLIENT_ID" --secret-permissions get list

This is the join. A Kubernetes ServiceAccount, annotated with the identity's client id, is what pods run as. A federated credential tells Azure: "trust tokens this specific issuer mints for this specific ServiceAccount, and treat them as this Managed Identity." Subject and issuer must match exactly, or Azure rejects the token — most first-attempt failures are a typo here.

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: production
  annotations:
    azure.workload.identity/client-id: "$CLIENT_ID"
EOF

az identity federated-credential create \
  --name app-fed-credential \
  --identity-name app-workload-id \
  --resource-group "$RG" \
  --issuer "$OIDC_ISSUER" \
  --subject "system:serviceaccount:production:app-sa"

Deploy a pod that runs as app-sa and carries the azure.workload.identity/use label. Because the pod matches that label and that ServiceAccount, the workload identity mutating webhook injects four environment variables at admission — AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_AUTHORITY_HOST, and AZURE_FEDERATED_TOKEN_FILE (a path to a token Kubernetes rotates on disk) — no code in the pod spec asks for them. Your code (or, here, the Azure CLI) reads that token file and exchanges it for an Azure access token at runtime. No Secret object, no env-var password.

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
  namespace: production
spec:
  replicas: 1
  selector:
    matchLabels: { app: secure-app }
  template:
    metadata:
      labels:
        app: secure-app
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: app-sa
      containers:
      - name: app
        image: mcr.microsoft.com/azure-cli:latest
        command: ["/bin/sh","-c","az login --service-principal --username \$AZURE_CLIENT_ID --tenant \$AZURE_TENANT_ID --federated-token \$(cat \$AZURE_FEDERATED_TOKEN_FILE) && az keyvault secret show --vault-name kv-campux-zt --name db-password --query value -o tsv && sleep 3600"]
EOF

# the secret value should appear in the logs — fetched with no stored credential
kubectl logs -n production deploy/secure-app

Identity is half of zero trust; the network is the other half. By default Kubernetes lets every pod talk to every pod — the flat network an attacker loves. Apply a default-deny policy to the namespace, then explicit allows for the one connection the app legitimately needs, and nothing else. Everything unlisted is now refused.

First, something to point the policy at. An allow rule naming backend only means something if a backend actually exists — deploy one, small and real, with a Service in front of it so the name backend resolves.

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
  namespace: production
spec:
  replicas: 1
  selector:
    matchLabels: { app: backend }
  template:
    metadata:
      labels: { app: backend }
    spec:
      containers:
      - name: backend
        image: registry.k8s.io/e2e-test-images/agnhost:2.40
        args: ["serve-hostname", "--http", "--port=3000"]
        ports:
        - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: backend
  namespace: production
spec:
  selector: { app: backend }
  ports:
  - port: 3000
    targetPort: 3000
EOF

Now the policies. Default-deny covers both directions for every pod in the namespace, which also blocks DNS — a namespace-wide deny still has to let every pod resolve names, so an explicit DNS allow comes first. A Kubernetes NetworkPolicy requires both sides to agree: the source pod's egress and the destination pod's ingress must each allow the connection, or it does not happen — so the frontend→backend allow needs an egress rule on the frontend and an ingress rule on the backend, not just one.

# deny all ingress/egress in the namespace, then allow DNS, then allow frontend -> backend:3000 both ways
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: production
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress:
  - to:
    - namespaceSelector:
        matchLabels: { kubernetes.io/metadata.name: kube-system }
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend-ingress
  namespace: production
spec:
  podSelector:
    matchLabels: { app: backend }
  policyTypes: [Ingress]
  ingress:
  - from:
    - podSelector:
        matchLabels: { app: frontend }
    ports:
    - port: 3000
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend-egress
  namespace: production
spec:
  podSelector:
    matchLabels: { app: frontend }
  policyTypes: [Egress]
  egress:
  - to:
    - podSelector:
        matchLabels: { app: backend }
    ports:
    - port: 3000
EOF

Prove both halves. A pod with no frontend label should hang and fail; a pod labelled frontend should connect.

# no label — the default-deny wins
kubectl run probe-blocked -n production --image=busybox --restart=Never -- \
  sh -c "wget -T 5 -qO- backend:3000 || echo BLOCKED"
kubectl logs -n production probe-blocked   # -> BLOCKED (timed out, as designed)

# labelled frontend — the explicit allow lets it through
kubectl run probe-allowed -n production --image=busybox --restart=Never --labels="app=frontend" -- \
  sh -c "wget -T 5 -qO- backend:3000 && echo ALLOWED"
kubectl logs -n production probe-allowed   # -> the backend's hostname, then ALLOWED

The cluster bills until it is gone. One resource-group delete removes the identity and the vault, and deletes the AKS cluster resource itself — which in turn deletes the second resource group AKS created for you (named MC_campux-zt-rg_campux-zt-aks_eastus) along with it, taking the actual node VMs, disks, and load balancer with it. You never delete that second group yourself; Azure does it as part of deleting the cluster. Do this now, not tomorrow.

az group delete -n campux-zt-rg --yes --no-wait
# right after --no-wait this still says true — the delete just started; recheck in a few minutes
az group exists -n campux-zt-rg      # -> false, once the async delete completes
az group exists -n MC_campux-zt-rg_campux-zt-aks_eastus   # -> false too, once it's done

You ran a workload on AKS with zero static secrets, federating a Kubernetes ServiceAccount to an Azure Managed Identity so a pod read Key Vault with nothing but a short-lived token, and you enforced default-deny network policies with explicit allows for exactly the one connection the app needs. That is "implemented zero-trust workload identity and network segmentation on Kubernetes" — a senior line on any cloud-security posting — done, not described. The pattern transfers straight to GitHub Actions federating into Azure, to app-to-database access, and to any place you are tempted to paste a key: the durable lesson is that the safest secret is the one that never existed.