Security anti-patterns — the cluster's protection

Kubernetes defaults are permissive. A namespace with no NetworkPolicy accepts traffic from every Pod in the cluster, a namespace with no Pod Security Standards label admits privileged containers, and a RoleBinding to cluster-admin never expires. None of that produces an error or an event, so posture drifts quietly rather than failing loudly — this lesson covers finding each gap and closing it.

The security anti-patterns

The security anti-patterns are:

• Privileged containers. The container is privileged; the workload has root access.
• Default ServiceAccount. The workload uses the default ServiceAccount; the workload has unnecessary privileges.
• Secrets in manifests. The Secret is in the manifest; the credential is in the git repo.
• No NetworkPolicies. The workload has no NetworkPolicy; the workload is reachable from any Pod.
• No Pod Security Standards. The Pod has no pod-security.kubernetes.io/enforce label; the privileged containers are allowed.
• No RBAC. The user has cluster-admin; the user has unlimited privileges.

flowchart TD
    A[Security anti-patterns] --> B[Privileged]
    A --> C[Default SA]
    A --> D[Secrets in manifests]
    A --> E[No NetworkPolicy]
    A --> F[No PSS]
    A --> G[No RBAC]

The security anti-patterns are the cluster’s protection.

The diagnostic

The canonical diagnostic:

# Use Polaris to detect anti-patterns
polaris audit --format yaml

# Check the privileged containers
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].securityContext.privileged}{"\n"}{end}'

# Check the default ServiceAccount
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.serviceAccountName}{"\n"}{end}'

# Check the NetworkPolicy
kubectl get networkpolicy -A

The diagnostic is the Polaris audit, the privileged containers, the default ServiceAccount, and the NetworkPolicy.

The remediation

The remediation depends on the anti-pattern:

# Substitute your own values before running:
NS=production
DEPLOY=web
CONTAINER=web              # container name inside the Pod template
SA_NAME=web-sa
ROLE=web-reader
ROLE_BINDING=web-reader-binding
VERB="get"
RESOURCE="pods"
RBAC_USER=jane@example.com

# Option 1: Set the security context
kubectl patch deployment "$DEPLOY" -n "$NS" \
  -p '{"spec":{"template":{"spec":{"containers":[{"name":"'"$CONTAINER"'","securityContext":{"privileged":false,"runAsNonRoot":true}}]}}}}'

# Option 2: Set the ServiceAccount
kubectl patch deployment "$DEPLOY" -n "$NS" \
  -p '{"spec":{"template":{"spec":{"serviceAccountName":"'"$SA_NAME"'"}}}}'

# Option 3: Use an external secret store
# (e.g., External Secrets Operator)

# Option 4: Apply the NetworkPolicy
kubectl apply -f networkpolicy.yaml

# Option 5: Apply the Pod Security Standards
kubectl label namespace "$NS" pod-security.kubernetes.io/enforce=restricted

# Option 6: Apply the RBAC
kubectl create role "$ROLE" --verb="$VERB" --resource="$RESOURCE" -n "$NS"
kubectl create rolebinding "$ROLE_BINDING" --role="$ROLE" --user="$RBAC_USER" -n "$NS"

The remediation is the anti-pattern fix.

Production discipline

The security anti-patterns are the cluster’s hypothesis. The discipline is to walk the 11-step methodology applied to the anti-patterns, identify the cause, apply the remediation. The cluster’s discipline is the same scale-free: every anti-pattern gets a fix.

• Run the detection in CI. The CI is the cluster’s prevention.

Quiz