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_B2s \
  --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. The mutating webhook injects the token path and environment; your code (or, here, the Key Vault CSI/SDK) exchanges that token for access and pulls the secret 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 --identity && 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 a single explicit allow for the one connection the app legitimately needs. Everything unlisted is now refused.

# deny all ingress and egress in the namespace, then allow frontend -> backend:3000 only
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-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels: { app: backend }
  ingress:
  - from:
    - podSelector:
        matchLabels: { app: frontend }
    ports:
    - port: 3000
EOF

Prove it. Stand up a throwaway pod with no allowed path and try to reach the backend — it should hang and fail, not connect.

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

The cluster bills until it's gone. One resource-group delete removes the AKS nodes, the identity, and the vault together. Do this now, not tomorrow.

az group delete -n campux-zt-rg --yes --no-wait
az group exists -n campux-zt-rg      # -> false, once the async delete completes

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 a single explicit allow. 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're tempted to paste a key: the durable lesson is that the safest secret is the one that never existed.