Namespaces, RBAC & Service Accounts: Who Can Do What

In this module, you'll learn to:

• Name the three checks every API request passes, and read the error each one gives
• Grant permissions with Roles, ClusterRoles, and bindings
• Give pods their own identity with service accounts, and check permissions with kubectl auth can-i

Before you start: this builds on How a Cluster Works, in particular that every action goes through the API server.

Namespaces organize a cluster, RBAC controls it

A namespace is a named section of a cluster. Most objects (Deployments, Services, ConfigMaps, Secrets) live in exactly one namespace, and names only have to be unique within it. Teams typically get a namespace per application or per team, such as orders or payments, while cluster add-ons live in kube-system.

Namespaces are useful because other features can be scoped to them: permissions, resource quotas, and network policies. But a namespace by itself blocks nothing. Anyone allowed to act across the whole cluster can reach into every namespace, and some objects (nodes, CRDs, cluster-wide roles) belong to no namespace at all. That's why hard boundaries between environments need separate clusters, covered in Multi-Environment Clusters.

What happens to every request before it's allowed

Each request to the API server, from a person, a pipeline, or a pod, passes three gates in order. Knowing which gate rejected you tells you what to fix.

• You must be logged in to the server (Unauthorized) means authentication failed. The cluster doesn't recognise your credentials, or they've expired.
• ... is forbidden: User "..." cannot list resource "pods" means authentication worked but RBAC said no. You need a role binding, not new credentials.

Kubernetes has no user accounts of its own. Who you are comes from outside: a client certificate, an identity provider, or, on Amazon EKS, your AWS IAM identity. Kubernetes on Amazon EKS shows how an IAM role becomes a Kubernetes user and group. Everything after that first gate works the same on every cluster.

RBAC in four objects

Kubernetes RBAC is built from two kinds of object, each in a namespaced and a cluster-wide version:

RBAC only ever adds permissions. There's no "deny" rule, so anything not granted is refused. Here's a read-only role for the orders namespace, given to a Kubernetes group called orders-readers:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: read-only
  namespace: orders
rules:
  - apiGroups: ["", "apps"]
    resources: ["pods", "pods/log", "services", "deployments", "replicasets"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: orders-readers
  namespace: orders
subjects:
  - kind: Group
    name: orders-readers
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: read-only
  apiGroup: rbac.authorization.k8s.io

Kubernetes also ships ready-made ClusterRoles (view, edit, admin, cluster-admin). Binding view or edit in a single namespace with a RoleBinding is often all a team needs.

Identities for pods

People and pipelines sign in from outside. Pods use service accounts. Every namespace has a default service account, and each pod runs as one. A service account is what RBAC checks when a pod calls the Kubernetes API itself; a controller that watches Deployments, for example, needs a Role that lets it do that. Most application pods never call the API, so they should run with a dedicated service account that has no Kubernetes permissions at all.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: orders-api
  namespace: orders
automountServiceAccountToken: false   # this app never calls the Kubernetes API

The pod template then sets serviceAccountName: orders-api. On EKS, the same service account is also how a pod gets AWS permissions, which is a separate mechanism covered in Workload Identity & Secrets.

Check permissions without guessing

# What namespaces exist?
kubectl get namespaces

# Can I do this? (answers yes or no, without doing it)
kubectl auth can-i create deployments -n orders

# Everything I'm allowed to do in a namespace
kubectl auth can-i --list -n orders

# Check on behalf of a service account, before a pod finds out the hard way
kubectl auth can-i list pods -n orders \
  --as=system:serviceaccount:orders:orders-api

# Who am I, as far as the cluster is concerned?
kubectl auth whoami

Key terms

• Authentication: proving who you are to the API server.
• Authorization (RBAC): deciding what that identity may do.
• Role and ClusterRole: a list of allowed verbs on resources, in one namespace or across the cluster.
• RoleBinding and ClusterRoleBinding: give a role to users, groups, or service accounts.
• Service account: the identity a pod runs as.

Pop quiz

Five questions: three on the ideas in this module, and two scenarios where you apply them. The order changes every time you take it, and 4 out of 5 passes.