Kubernetes RBAC

Scoped Access, User Certificates, and Vault Integration

When managing a Kubernetes cluster, eventually you might need to give someone — or yourself — access without handing over too much control. Maybe it’s a team member who needs to deploy workloads, or you want a restricted account that can’t accidentally nuke your entire cluster.

Authentication vs Authorization

This is the most important concept to understand before anything else. In Kubernetes these are two completely separate things:

Understanding RBAC

Kubernetes RBAC revolves around four objects:

Built-in ClusterRoles

Before creating custom roles, it’s worth knowing what Kubernetes already ships with. You can inspect any of them to understand what they grant and use them as a starting point.

For example, kubectl get clusterrole admin -o yaml will list permissions for the admin role. You can output this to a file with > newfile.yml to modify it and create a new ClusterRole, which is what I’ll demonstrate shortly.

Discovering API Groups and Resources

Every resource in Kubernetes belongs to an API group. Before writing roles you need to know what groups and resources exist on your cluster:

kubectl get apiservice

Then drill into a specific group to see its resources:

kubectl api-resources --api-group=apps
kubectl api-resources --api-group=batch
kubectl api-resources --api-group=networking.k8s.io
kubectl api-resources --api-group=""    # core resources — pods, services, configmaps etc

Verbs

Verbs are the actions you can grant on any resource:

Creating the ClusterRole

For this lab we duplicated the built-in admin role as a starting point and named it admin-role. In practice you can use any built-in role as a base, create one from scratch, or just bind directly to a built-in role entirely. The important thing is understanding what you’re granting.

Below is a slimmed down version of the admin ClusterRole. The key omission — no RBAC resources. This user simply cannot create or modify roles and bindings, so there’s no way to escalate their own permissions.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: admin-role
rules:
- apiGroups: [""]
  resources: ["pods", "pods/exec", "pods/log", "pods/portforward", "services",
              "configmaps", "secrets", "persistentvolumeclaims", "serviceaccounts"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets", "daemonsets", "statefulsets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["batch"]
  resources: ["jobs", "cronjobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["networking.k8s.io"]
  resources: ["ingresses", "networkpolicies"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list", "watch"]

kubectl apply -f admin-role.yml

kubectl edit clusterrole admin-role

Groups in Kubernetes

Kubernetes doesn’t have group objects you create. Groups are derived from the O (Organization) field embedded in a user’s certificate. When a user authenticates, Kubernetes reads their cert and uses CN as the username and O as the group.

Creating the ClusterRoleBinding

Rather than binding to an individual user, bind to the group. Any future user created with O=naxslabs-admins in their cert gets the same permissions without touching this file:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: naxslabs-admins-binding
subjects:
- kind: Group
  name: naxslabs-admins
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin-role
  apiGroup: rbac.authorization.k8s.io

kubectl auth can-i get pods --as-group=naxslabs-admins --as=darnell

Generating User Certificates

Rather than running commands manually every time, a script handles the whole process. Kubernetes only cares about two fields in the CSR subject — CN becomes the username, O becomes the group. Everything else (country, state, city) is ignored.

#!/bin/bash
user=$1
org=$2

openssl genrsa -out $user.key 2048
openssl req -new -key $user.key -out $user.csr \
  -subj "/C=US/ST=RI/L=Providence/O=$org/CN=$user"
cat $user.csr | base64 | tr -d "\n" > $user-encoded.csr
sed "s/KEY/`cat $user-encoded.csr`/; s/USER/$user/" csr-template.yml > $user-csr.yml

bash certgen.sh darnell naxslabs-admins

The script generates the key, CSR, base64 encodes it, and injects it into a Kubernetes CSR manifest automatically. You’ll end up with three files: the private key, the CSR, and a ready-to-apply Kubernetes manifest.

CSR Template

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: USER
spec:
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth
  request: KEY

Submit and Approve

kubectl apply -f darnell-csr.yml
kubectl certificate approve darnell
kubectl get csr darnell -o jsonpath='{.status.certificate}' | base64 -d > darnell.crt

Storing Credentials in HashiCorp Vault

Flat cert files sitting on disk are a liability. Store them in Vault instead:

vault kv put secret/kubernetes/users/darnell \
  [email protected] \
  [email protected]

Configuring kubeconfig Without Touching Disk

Once the certs are in Vault, configure kubeconfig using process substitution — credentials never hit disk:

kubectl config set-credentials darnell \
  --client-certificate=<(vault kv get -field=cert secret/kubernetes/users/darnell) \
  --client-key=<(vault kv get -field=key secret/kubernetes/users/darnell) \
  --embed-certs=true

The <() process substitution passes Vault output directly as a file descriptor. --embed-certs=true bakes the cert data directly into the kubeconfig so it's self-contained — no external file dependency that can break if files move or get deleted.

Set the Context

kubectl config set-context darnell \
  --cluster=kubernetes \
  --user=darnell \
  --namespace=default

kubectl config use-context darnell

Distributing Credentials to Users via Vault

vault policy write darnell-policy - <<EOF
path "secret/kubernetes/users/darnell/*" {
  capabilities = ["read"]
}
EOF

This scales cleanly — each user gets their own policy scoped to their path, admins never touch raw cert files after initial generation, and Vault's audit log gives you a complete record of every credential access.

Rolling Back

To remove everything cleanly:

kubectl delete clusterrolebinding naxslabs-admins-binding
kubectl delete clusterrole admin-role
kubectl delete csr darnell
rm darnell.key darnell.crt darnell-encoded.csr darnell-csr.yml

Applying This at the Namespace Level

Everything covered in this post applies cluster-wide using ClusterRoles and ClusterRoleBindings — but the same exact approach works at the namespace level if you want tighter control. Say you have a contractor who should only be able to deploy to the staging namespace, or a junior dev who shouldn't touch production. Just swap ClusterRole for Role, ClusterRoleBinding for RoleBinding, and add a namespace field to the metadata:

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

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: staging-deployer-binding
  namespace: staging
subjects:
- kind: User
  name: contractor
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: staging-deployer
  apiGroup: rbac.authorization.k8s.io

Key Takeaways