The RoleBinding referenced by your pod or service account does not exist. Fix by ensuring the RoleBinding is created in the correct namespace, verify its name matches what's referenced, and confirm the Role it points to exists before the RoleBinding.
A RoleBinding is a Kubernetes resource that grants permissions (defined in a Role or ClusterRole) to users, groups, or service accounts. When Kubernetes cannot find a RoleBinding, it usually means the binding object was never created, was created in the wrong namespace, or was deleted. RoleBindings are namespace-scoped resources, so a RoleBinding in the default namespace is invisible to pods in other namespaces. This error often occurs during pod startup when the kubelet tries to validate RBAC permissions using a RoleBinding that doesn't exist, or when kubectl commands reference a non-existent binding. Unlike "Permission denied" errors (which mean a binding exists but lacks required permissions), "not found" means the binding itself is missing.
First, determine what RoleBinding your pod or service account expects. Check pod logs and events:
# View pod events
kubectl describe pod <pod-name> -n <namespace>
# Check recent events in the namespace
kubectl get events -n <namespace> --sort-by=.metadata.creationTimestamp | tail -20
# If using RBAC audit, check API server logs
kubectl logs -n kube-system -l component=kube-apiserver | grep RBACLook for error messages containing the RoleBinding name or "not found" in the output.
RoleBindings are namespace-scoped. List all RoleBindings in every namespace:
# List RoleBindings in current namespace
kubectl get rolebinding -n <namespace>
# List all RoleBindings across all namespaces
kubectl get rolebinding -A
# Check if a specific RoleBinding exists
kubectl get rolebinding <rolebinding-name> -n <namespace>If the output is empty or the binding doesn't appear, it doesn't exist yet. Note the namespace where your pod is running vs. where the RoleBinding should exist (they must match).
If the RoleBinding is missing, create it. First, verify the Role it references exists:
# List all Roles in the namespace
kubectl get role -n <namespace>
# View the Role definition
kubectl get role <role-name> -n <namespace> -o yamlThen create the RoleBinding using kubectl:
kubectl create rolebinding <rolebinding-name> \
--clusterrole=<role-name> \
--serviceaccount=<namespace>:<service-account-name> \
-n <namespace>Or use a YAML manifest:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: my-rolebinding
namespace: my-namespace
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: my-role
subjects:
- kind: ServiceAccount
name: my-service-account
namespace: my-namespaceApply it:
kubectl apply -f rolebinding.yamlRoleBindings reference a Role or ClusterRole. Both must exist. If using Infrastructure-as-Code (Terraform, Helm, Kustomize), ensure the Role is created before the RoleBinding:
# BAD: RoleBinding created first, then Role
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: my-binding
roleRef:
kind: Role
name: my-role # This role doesn't exist yet!
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: my-role
rules:
- apiGroups: [""]
resources: [pods]
verbs: [get, list]Reorder so Role comes first:
# GOOD: Role created first
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: my-role
rules:
- apiGroups: [""]
resources: [pods]
verbs: [get, list]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: my-binding
roleRef:
kind: Role
name: my-role
subjects:
- kind: ServiceAccount
name: defaultA common mistake is creating a RoleBinding in one namespace but expecting it to work for a service account in another namespace.
# Find which namespace your service account is in
kubectl get serviceaccount -A | grep <service-account-name>
# List RoleBindings in that same namespace
kubectl get rolebinding -n <correct-namespace>The RoleBinding MUST be in the same namespace as the service account it grants permissions to:
# Service account in "app" namespace
apiVersion: v1
kind: ServiceAccount
metadata:
name: app-sa
namespace: app
---
# RoleBinding must ALSO be in "app" namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-reader
namespace: app # SAME namespace!
roleRef:
kind: Role
name: pod-reader
subjects:
- kind: ServiceAccount
name: app-sa
namespace: appA common confusion: RoleBinding grants permissions only within a single namespace. If you need cluster-wide access, use a ClusterRoleBinding with a ClusterRole:
# This only grants permissions in the current namespace
kubectl create rolebinding my-binding \
--clusterrole=view \
--serviceaccount=default:default \
-n default
# For cluster-wide access, use ClusterRoleBinding
kubectl create clusterrolebinding my-cluster-binding \
--clusterrole=view \
--serviceaccount=default:defaultClusterRoleBindings reference ClusterRoles and grant permissions across all namespaces. Ensure you're using the correct resource type for your use case.
After creating the RoleBinding, test whether the service account now has the expected permissions:
# Test if service account can perform an action
kubectl auth can-i get pods \
--as=system:serviceaccount:<namespace>:<service-account-name> \
-n <namespace>
# Expected output
yes # Permissions granted
# or
no # Permissions still not granted
# View detailed RBAC decision
kubectl auth can-i get pods \
--as=system:serviceaccount:default:my-sa \
-n default \
--recordIf the output is "no", the RoleBinding exists but lacks the required permission. See the "Permission denied" error guide for solutions.
RoleBindings cannot be updated after creation; the roleRef field is immutable. If you need to change which Role a binding references, delete and recreate the binding. In managed Kubernetes (EKS, GKE, AKS), system namespaces like kube-system have default RoleBindings for system service accounts; if you accidentally delete these, cluster components may fail. Use kubectl describe and kubectl get -o yaml to inspect RBAC resources in detail. For troubleshooting across multiple clusters, note that RoleBindings are cluster-local; a binding created on one cluster doesn't exist on another. If using GitOps (Flux, ArgoCD), ensure RBAC resources are applied in the correct order and namespace. Helm charts should use ServiceAccount and RoleBinding helpers (e.g., helm.sh/hook dependencies) to ensure correct ordering. In clusters with multi-tenancy, always verify RoleBindings are created in the correct tenant namespace, not the shared admin namespace.
No subnets found for EKS cluster
How to fix "eks subnet not found" in Kubernetes
unable to compute replica count
How to fix "unable to compute replica count" in Kubernetes HPA
error: context not found
How to fix "error: context not found" in Kubernetes
default backend - 404
How to fix "default backend - 404" in Kubernetes Ingress
serviceaccount cannot list resource
How to fix "serviceaccount cannot list resource" in Kubernetes