Scenario: Unauthenticated API Calls in Your Cluster

Your SIEM alerts on suspicious API calls to the Kubernetes API server. The audit logs show requests from system:anonymous with verbs like delete and update against deployments and namespaces. Even worse, an unknown IP has been seen pulling secrets.

Symptoms

• kubectl get events --all-namespaces shows unauthorized modifications.
• Audit logs (if enabled) reveal anonymous successful responses.
• Some production deployments have been altered.
• Your security team suspects a data breach.

Diagnosis

First, confirm the API server's authorization mode and anonymous settings:

kubectl get --raw /api/v1/namespaces/kube-system/configmaps | grep -i anonymous

If audit logs aren't available, review bindings:

kubectl get clusterrolebindings,rolebindings -A -o yaml | grep -B2 -A10 "system:anonymous"

Check what anonymous can do:

kubectl auth can-i --list --as system:anonymous

Commands to Audit and Harden

List all bindings referencing anonymous:

kubectl get clusterrolebinding,rolebinding -A -o json | jq '.items[] | select(.subjects[]?.name=="system:anonymous")'

Remove the dangerous binding (replace <binding-name>):

kubectl delete clusterrolebinding <binding-name> --dry-run=client -o yaml > backup.yaml
kubectl delete clusterrolebinding <binding-name>

Apply additional hardening:

# Enable Pod Security Admission (example: enforce baseline/default)
kubectl label --overwrite ns --all pod-security.kubernetes.io/enforce=baseline

Risk Controls

• Enforce Least Privilege RBAC: Strip anonymous and overly broad bindings; use groups and service accounts.
• Enable Audit Logging: Forward to SIEM.
• Use NetworkPolicies: Restrict pod-to-pod and egress.
• Disable Anonymous Access: Set --anonymous-auth=false if no unauthenticated health endpoints are needed.
• Rotate all credentials if compromise is suspected.

Rollback

If deleting a binding breaks something (e.g., monitoring agent loses access), reapply from backup:

kubectl apply -f backup.yaml

Test connectivity after rollback.

Verification

Confirm anonymous can’t read secrets:

kubectl auth can-i --list --as system:anonymous | grep -i secret
# should show no or "no" for get/list secrets

Simulate an anonymous request:

curl -ks https://$(kubectl get svc kubernetes -n default -o jsonpath='{.spec.clusterIP}'):443/api/v1/secrets
# Expected: 403 Forbidden

When to Submit an OpsGlobal Ticket

If you lack the time or expertise to perform a full security audit, if you can't identify all the compromised paths, or if you need forensic analysis, submit a ticket. OpsGlobal's SRE security specialists can help you harden your platform, implement best-practice RBAC, and set up continuous security monitoring.