EC
Forbidden (RBAC)
KubernetesERRORNotableSecurityHIGH confidence

Action is forbidden by RBAC policy

Production Risk

Correctly configured RBAC is critical for security. However, overly restrictive rules can prevent applications from functioning correctly if they cannot access required resources.

What this means

A user or service account is attempting to perform an action (like reading secrets or listing pods) that it is not authorized to do. This is a direct rejection from the Kubernetes API server based on Role-Based Access Control (RBAC) rules.

Why it happens
  1. 1The user or service account does not have a Role or ClusterRole attached that grants the necessary permission
  2. 2The RoleBinding or ClusterRoleBinding that links the user to the role is missing or incorrect
  3. 3The action is being attempted in the wrong namespace where the permissions do not apply
How to reproduce

A `kubectl` command or an in-cluster application making an API call fails with a 'Forbidden' error message.

trigger — this will error
trigger — this will error
kubectl get secrets

expected output

Error from server (Forbidden): secrets is forbidden: User "system:serviceaccount:default:default" cannot list resource "secrets" in API group "" in the namespace "default"

Fix 1

Check permissions with 'can-i'

WHEN To quickly test if a user or service account has a specific permission

Check permissions with 'can-i'
kubectl auth can-i list secrets --as=system:serviceaccount:default:default

Why this works

This `auth` subcommand impersonates the specified user/service account and tells you if the action is allowed by the current RBAC policies, returning 'yes' or 'no'.

Fix 2

Create a Role and RoleBinding

WHEN Permissions need to be granted within a specific namespace

Create a Role and RoleBinding
kubectl apply -f my-role.yaml && kubectl apply -f my-rolebinding.yaml

Why this works

Applying a Role manifest defines a set of permissions, and a RoleBinding manifest grants those permissions to a specific user, group, or service account within that namespace.

What not to do

✕ Grant the 'cluster-admin' role to the service account

This gives the service account unrestricted superuser access to the entire cluster, which is a major security risk. You should always grant the least privilege necessary.

Sources
Official documentation ↗

k8s.io/apiserver/pkg/authorization/authorizer.go

Using RBAC Authorization ↗

Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev

← All Kubernetes errors