Stage 5 · Platform

Compute & Containers

AKS Security

Workload identity, pod security standards, network policies, and Defender for Containers.

8 min readAzure Cloud EngineeringPlatform

AKS Security Layers

AKS security spans multiple layers: cluster-level (RBAC, network policies), node-level (hardened OS, limited access), pod-level (security contexts, service accounts), and workload-level (secrets, identity).

Cluster — RBAC, API server access, audit logging
Node — Restricted SSH, automatic OS patching, node auto-upgrade
Pod — Security contexts, read-only root filesystem, no privilege escalation
Workload — Workload identity, Key Vault integration, network policies

Workload Identity

Workload Identity connects Kubernetes service accounts to Azure managed identities. Pods can authenticate to Azure services (Key Vault, Storage, etc.) without any credentials in the pod or environment variables.

Enable workload identity on AKS


# Enable OIDC issuer and workload identity
az aks update \
  --resource-group rg-aks-prod \
  --name aks-payments-prod \
  --enable-oidc-issuer \
  --enable-workload-identity

 # Create a user-assigned identity
az identity create --name mi-payments --resource-group rg-aks

 # Get the OIDC issuer
ISSUER=$(az aks show \
  --resource-group rg-aks-prod \
  --name aks-payments-prod \
  --query "oidcIssuerProfile.issuerUrl" --output tsv)

 # Create a federated credential
az identity federated-credential create \
  --name fic-payments \
  --identity mi-payments \
  --issuer "$ISSUER" \
  --subject "system:serviceaccount:default:sa-payments"

 # Assign Key Vault access to the identity
az role assignment create \
  --assignee-object-id "$(az identity show --name mi-payments --query principalId --output tsv)" \
  --role "Key Vault Secrets User" \
  --scope "/subscriptions/{sub-id}/resourceGroups/rg-payments/providers/Microsoft.KeyVault/vaults/kv-payments"

Workload Identity replaces the deprecated AAD Pod Identity. It uses standard Kubernetes service account tokens and does not require any mutating webhooks.

Pod Security Standards

Pod Security Standards (PSS) define three security profiles: Privileged, Baseline, and Restricted. Pod Security Admission (PSA) enforces these profiles at the namespace level.

Enforce pod security standards


# Label a namespace to enforce the Baseline policy
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/warn=restricted

 # Check if a pod violates the policy
kubectl auth can-i create pods --namespace production --as=system:serviceaccount:production:sa-app

 # View pod security audit logs
kubectl get events --field-selector reason=FailedCreate --namespace production

The enforce label rejects pods that violate the policy. The warn label shows warnings but allows creation. Use both for gradual rollout.

Restricted is the target profile

Start with Baseline for existing workloads, then migrate to Restricted. Restricted enforces the strictest controls: non-root user, no privilege escalation, read-only root filesystem, and drop all capabilities.

Image Security

Image security starts with using minimal base images, scanning for vulnerabilities, and signing images to verify integrity. ACR integration and image pull policies are critical for cluster security.

Enforce image pull policy


apiVersion: apps/v1
kind: Deployment
metadata:
  name: payments-api
spec:
  template:
    spec:
      containers:
      - name: payments
        image: craksprodeastus.azurecr.io/payments:v1.0.0
        imagePullPolicy: Always
        securityContext:
          runAsNonRoot: true
          runAsUser: 1000
          readOnlyRootFilesystem: true
          allowPrivilegeEscalation: false
          capabilities:
            drop:
              - ALL

imagePullPolicy: Always ensures the latest image is pulled. Combined with immutable digests in production, this prevents running outdated or tampered images.

Secret Management

Kubernetes Secrets are base64-encoded (not encrypted) by default. For production, integrate with Azure Key Vault using the Secrets Store CSI Driver to inject secrets as mounted volumes.

Install Secrets Store CSI Driver


# Install the CSI Driver via Helm
helm install csi-secrets-store \
  --namespace kube-system \
  --repo https://raw.githubusercontent.com/Azure/secrets-store-csi-driver-provider-azure/master/charts

 # Create a SecretProviderClass
cat <<EOF | kubectl apply -f -
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-kv-payments
  namespace: default
spec:
  provider: azure
  parameters:
    usePodIdentity: "true"
    keyvaultName: "kv-payments"
    objects: |
      array:
        - |
          objectName: db-password
          objectType: secret
        - |
          objectName: tls-cert
          objectType: cert
EOF

The CSI Driver mounts secrets as files in the pod. The pod can read them from /mnt/secrets-store/. Combined with workload identity, no credentials are stored in the cluster.

Defender for Containers

Microsoft Defender for Containers provides runtime threat protection, vulnerability assessment, and compliance monitoring for AKS clusters. It runs as a daemonset on every node.

Enable Defender for Containers


# Enable Defender for Containers pricing plan
az security pricing create --name Containers --tier Standard

 # Enable on a specific AKS cluster
az security auto-provisioning-setting update \
  --name default \
  --auto-provision On

Defender for Containers monitors pod execution, network connections, and file system changes. It generates security alerts in Microsoft Defender for Cloud when suspicious activity is detected.

Use Azure Policy for AKS

Azure Policy enforces compliance rules on AKS clusters. Use the Azure Policy Add-on to apply built-in policies like 'container must not run as root' or 'images must come from approved registries'.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.