How to Fix Permission Denied Errors in Kubernetes

Permission denied errors in Kubernetes usually happen because the pod or user lacks the right RBAC permissions or volume access rights. Fix this by updating the Role or ClusterRole and binding it properly with a RoleBinding or ClusterRoleBinding, or by correcting volume mount permissions.

Why This Happens

Permission denied errors occur when Kubernetes objects like pods or users try to perform actions they are not allowed to. This can be due to missing or incorrect RBAC permissions or because the pod cannot access a mounted volume due to file system permissions.

yaml

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  serviceAccountName: default
  containers:
  - name: app
    image: busybox
    command: ["sh", "-c", "touch /data/file.txt"]
    volumeMounts:
    - mountPath: /data
      name: data-volume
  volumes:
  - name: data-volume
    persistentVolumeClaim:
      claimName: data-pvc

Output

Error from server (Forbidden): pods "example-pod" is forbidden: error looking up service account default/default: serviceaccount "default" not found
or
sh: touch: /data/file.txt: Permission denied

The Fix

Grant the pod the correct permissions by creating a Role or ClusterRole with needed rights and bind it to the pod's ServiceAccount. Also, ensure the volume permissions allow writing by setting the correct securityContext or adjusting the volume's file system permissions.

yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: example-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-access-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-access-binding
  namespace: default
subjects:
- kind: ServiceAccount
  name: example-sa
  namespace: default
roleRef:
  kind: Role
  name: pod-access-role
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  serviceAccountName: example-sa
  securityContext:
    fsGroup: 1000
  containers:
  - name: app
    image: busybox
    command: ["sh", "-c", "touch /data/file.txt"]
    volumeMounts:
    - mountPath: /data
      name: data-volume
  volumes:
  - name: data-volume
    persistentVolumeClaim:
      claimName: data-pvc

Output

pod/example-pod created
role.rbac.authorization.k8s.io/pod-access-role created
rolebinding.rbac.authorization.k8s.io/pod-access-binding created
serviceaccount/example-sa created

Inside pod, file /data/file.txt is created successfully without permission errors.

Prevention

Always assign minimal required permissions using RBAC and use dedicated ServiceAccounts for pods. Check volume permissions before mounting and use securityContext to set correct user and group IDs. Regularly audit permissions with tools like kubectl auth can-i to avoid surprises.

Related Errors

• Forbidden: Happens when RBAC denies access; fix by updating roles and bindings.
• MountVolume.SetUp failed: Volume permission or access issues; fix by adjusting volume permissions or security context.
• ImagePullBackOff: Not a permission error but often confused; check image pull secrets and registry access.

Key Takeaways

Fix permission denied errors by assigning correct RBAC roles and bindings to the pod's ServiceAccount.

Ensure volume mounts have proper file system permissions and use securityContext to set fsGroup.

Use dedicated ServiceAccounts with least privilege for pods to improve security and avoid permission issues.

Regularly audit permissions with kubectl commands to catch missing rights early.

Check related errors like Forbidden or MountVolume failures for clues on permission problems.