azure-aks-governance

Standard IDs

ID	Severity	What it checks
AKS-001	P0	Namespace/pod has no Pod Security Standards enforcement
AKS-002	P1	Container has no resource requests/limits configured
AKS-003	P0	No NetworkPolicy restricting pod-to-pod traffic
AKS-004	P0	Pod uses a client-secret/connection-string instead of Azure Workload Identity

This skill only applies when stack-detection identifies AKS as the compute target; shops on Azure Container Apps are governed by azure-bicep-patterns/azure-security-baseline instead — AKS introduces a distinct cluster-level governance surface those skills don't cover.

---

Check A — No Pod Security Standards enforcement (AKS-001)

Detection

Check the namespace manifest for Pod Security Admission labels (pod-security.kubernetes.io/enforce). Without at least the baseline standard, a pod spec can request privileged mode, host networking, or host path mounts — any of which gives a compromised container a path to the underlying node.

BAD — namespace with no Pod Security Standard set

apiVersion: v1
kind: Namespace
metadata:
  name: orders-prod
  # No pod-security.kubernetes.io/enforce label — any pod spec is admitted as-is.

GOOD — restricted standard enforced at the namespace level

apiVersion: v1
kind: Namespace
metadata:
  name: orders-prod
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted

---

Check B — No resource requests/limits (AKS-002)

Detection

Grep pod/deployment specs for containers with no resources.requests/resources.limits. Without requests, the scheduler can't bin-pack nodes sensibly (noisy-neighbor risk); without limits, one runaway container can consume all node memory and get OOM-killed alongside every other pod on that node.

BAD — no resource requests/limits set

containers:
  - name: orders-api
    image: acr.azurecr.io/orders-api:latest
    # No resources block — this container can consume unbounded CPU/memory on its node.