Kubernetes Authorization: How to Control Access and Fix Kubectl Forbidden Errors

The kubeconfig was perfect, but access was denied.

That’s when you know you’ve hit Kubernetes authorization. You have the right cluster, the right credentials, but kubectl refuses to run your command. Authorization in Kubernetes is the silent gatekeeper that decides what actions a user, service account, or application can take. Get it wrong, and the wrong person can run kubectl delete pod --all. Get it right, and your cluster is both secure and productive.

How Kubernetes Authorization Works

When you run kubectl, you go through three steps: authentication, authorization, and admission control. Authorization is the second step. After Kubernetes verifies who you are, it decides what you’re allowed to do.

The Kubernetes API server supports multiple authorization modules:

RBAC (Role-Based Access Control) – The most common choice, mapping roles to users or groups.
ABAC (Attribute-Based Access Control) – Deprecated in most cases, using policies in JSON files.
Webhook Authorization – Outsources decisions to a custom service.
Node Authorization – Special rights for kubelets to manage resources on their nodes.

You can enable more than one mode, but most clusters rely on RBAC because it is flexible and built-in.

Understanding RBAC

RBAC policies are made of Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings.

Continue reading? Get the full guide.

Kubernetes API Server Access + Customer Support Access to Production: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Role: Defines permissions in a single namespace.
ClusterRole: Permissions that work across the whole cluster.
RoleBinding: Grants a Role’s permissions to a user or group in a namespace.
ClusterRoleBinding: Grants ClusterRole permissions cluster-wide.

Example:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 namespace: dev
 name: pod-reader
rules:
- apiGroups: [""]
 resources: ["pods"]
 verbs: ["get", "list"]

And the binding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: read-pods
 namespace: dev
subjects:
- kind: User
 name: alice
 apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: Role
 name: pod-reader
 apiGroup: rbac.authorization.k8s.io

With this, alice can list pods in the dev namespace, and nothing else.

Debugging Authorization in Kubectl

If a command fails with a forbidden error, you can verify your permissions by running:

kubectl auth can-i delete pods --namespace dev

This checks if your current identity can delete pods in that namespace. You can swap verbs and resources to test different actions.

Best Practices

Start with least privilege.
Use service accounts for apps, not human credentials.
Regularly review RoleBindings and ClusterRoleBindings.
Avoid using cluster-admin unless absolutely necessary.
Audit API requests with audit logs.

Securing Kubectl at Scale

Managing authorization gets harder as clusters grow. Manual RBAC changes can lead to human error and security drift. Tools and platforms that automate and visualize these permissions reduce risk and save hours of guesswork.