Kubernetes RBAC for Small Teams: Users, Roles, and Service Accounts

Even a small cluster needs a least-privilege mindset: not everyone should be able to delete namespaces or read every secret. Kubernetes RBAC (Role-Based Access Control) defines who can do what. The core objects are Roles and ClusterRoles (what you can do), RoleBindings and ClusterRoleBindings (who gets those abilities), plus ServiceAccounts, which are identities for pods rather than humans.

The RBAC objects

A Role scopes permissions to one namespace; a ClusterRole scopes them cluster-wide. Bindings attach roles to subjects — users, groups, or ServiceAccounts.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: deployer
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]

Binding a role to a developer

Here the deployer Role is granted to a named user within production.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-deploy
  namespace: production
subjects:
  - kind: User
    name: dev-alice
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: deployer
  apiGroup: rbac.authorization.k8s.io

ServiceAccounts for pods

Pods do not carry human identities; they run under a ServiceAccount. The default one is fine for many apps, but giving sensitive workloads a dedicated, minimal account is better practice.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-runner
  namespace: production
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
  namespace: production
spec:
  replicas: 1
  template:
    spec:
      serviceAccountName: app-runner
      containers:
        - name: app
          image: myapp:1.4

The permission model

Verifying permissions

Kubectl can tell you what a subject may do without experimenting destructively.

kubectl auth can-i get pods --as=dev-alice
kubectl -n production get rolebindings
kubectl -n production get serviceaccounts
kubectl auth can-i delete deployments --as=dev-alice

Takeaway

RBAC lets small teams share one cluster safely: Roles define actions, Bindings attach them to subjects, and ServiceAccounts give pods scoped identities. Start cluster-wide (admin) for your two operators, then add a production Roles for developers and nothing more. Sketch this out on a single-node k3s cluster at Netbay and lock down the surface before it grows — netbayhosts.in.