How to fix capability not allowed in Kubernetes

KubernetesINTERMEDIATEMEDIUMUpdated Dec 6, 2025· 146 views

Capability errors occur when requesting Linux capabilities denied by security policies. Fix by reviewing Pod Security Standards, dropping unnecessary capabilities, and adding only required ones.

Quick fix

Fixes capability not allowed

kubectl describe pod <pod-name>
kubectl logs <pod-name>
  1. Check which capability is being denied
  2. Understand Pod Security Standards baseline
  3. Drop all capabilities first, then add required ones
  4. Use correct uppercase capability names
kubernetes — error
kubectl describe pod <pod-name>
kubectl logs <pod-name>
capability not allowed

What this error means

Linux capabilities provide fine-grained control over privileged operations. When Kubernetes reports "capability not allowed," it means the Pod Security Policy, Pod Security Standard, or AppArmor/SELinux policies block the requested capability. This prevents the container from performing operations that require elevated privileges.

Typical symptoms

  • Container fails with "capability not allowed" error
  • Pod sandbox creation fails
  • Container runs but operations requiring capability fail
  • Error from runtime when dropping or adding capabilities
  • Non-root container cannot perform privileged operations
  • Pod Security Standard (PSS) rejects pod admission
  • AppArmor denies capability in logs
  • Application writes to /dev or /sys fails

Common causes

  1. Requesting capability not allowed by Pod Security Standard (default: Restricted)
  2. Pod Security Policy blocking the capability
  3. Running as non-root user while needing capabilities (kernel restrictions)
  4. Capability name case-sensitive and using lowercase instead of uppercase
  5. AppArmor or SELinux policy denying the capability
  6. Trying to request capability that does not exist
  7. Cluster security hardening blocklist includes the capability
  8. Container runtime not configured to support capability

How to fix "capability not allowed"

1Check which capability is being denied

Review pod events and container logs for specific capability:

bash
kubectl describe pod <pod-name>
kubectl logs <pod-name>

Look for capability name in error message (e.g., CAP_NET_ADMIN).

2Understand Pod Security Standards baseline

Know what capabilities are allowed at each level:

bash
kubectl get psp  # Check Pod Security Policies
kubectl label namespace default pod-security.kubernetes.io/enforce=baseline

Restricted (default): no capabilities
Baseline: allows some common ones
Unrestricted: allows most

3Drop all capabilities first, then add required ones

Start with secure baseline and add only what is needed:

yaml
securityContext:
  capabilities:
    drop:
      - ALL
    add:
      - NET_BIND_SERVICE
      - NET_RAW

Always use UPPERCASE for capability names.

4Use correct uppercase capability names

Linux capabilities must be in UPPERCASE with CAP_ prefix:
- Correct: CAP_NET_ADMIN, CAP_SYS_TIME, CAP_NET_BIND_SERVICE
- Wrong: cap_net_admin, NetAdmin, net_admin
See Linux man pages for full list of capabilities.

5Ensure container runs as root if needs capabilities

By default, non-root containers cannot use capabilities. If needed:

yaml
securityContext:
  runAsUser: 0  # Run as root
  capabilities:
    add:
      - CAP_NET_ADMIN

Prefer dropping ALL and adding specific capabilities instead.

6Switch pod to baseline or unrestricted PSS if needed

For workloads needing capabilities, adjust namespace policy:

bash
kubectl label namespace default \
  pod-security.kubernetes.io/enforce=baseline \
  --overwrite

Use baseline carefully - unrestricted is rarely needed.

7Check AppArmor or SELinux restrictions

Verify AppArmor/SELinux is not blocking capability:

bash
kubectl get pod <pod> -o yaml | grep -i apparmor
grep DENIED /var/log/audit/audit.log

Update AppArmor profile to allow capability if necessary.

8Validate capability in pod spec before deploying

Test pod locally before cluster deployment:

bash
kubectl apply -f pod.yaml --dry-run=server

This validates against current Pod Security Policies.

Advanced notes

For production, maintain restrictive security contexts by default. Document why each capability is needed. Use Kubernetes RBAC to limit who can deploy containers with elevated capabilities. Consider alternative approaches: use sidecar containers with required capabilities, use network policies instead of CAP_NET_ADMIN, or use host networking carefully. Monitor capability usage via audit logs.

Frequently asked questions

What does "capability not allowed" mean?
Linux capabilities provide fine-grained control over privileged operations. When Kubernetes reports "capability not allowed," it means the Pod Security Policy, Pod Security Standard, or AppArmor/SELinux policies block the requested capability. This prevents the container from performing operations that require elevated privileges.
How do I fix "capability not allowed"?
Capability errors occur when requesting Linux capabilities denied by security policies. Fix by reviewing Pod Security Standards, dropping unnecessary capabilities, and adding only required ones.
What causes "capability not allowed"?
Requesting capability not allowed by Pod Security Standard (default: Restricted) Pod Security Policy blocking the capability Running as non-root user while needing capabilities (kernel restrictions)
Is the "capability not allowed" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading