How to Configure Kubernetes RBAC on RHEL 8

December 15, 2025
Linux
Comment off

Role-Based Access Control (RBAC) is the primary authorization mechanism in Kubernetes, allowing you to define exactly which users and service accounts can perform which actions on which resources. On RHEL 8 clusters this is especially important when multiple teams share the same cluster or when you need to grant applications only the permissions they need to function. This tutorial covers the four RBAC building blocks — Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings — and demonstrates how to create them, bind them to users and ServiceAccounts, verify permissions with kubectl auth can-i, and generate a restricted kubeconfig for a developer. Understanding RBAC properly is essential before any production Kubernetes deployment.

Prerequisites

A running Kubernetes cluster on RHEL 8
kubectl configured with cluster-admin privileges
Basic familiarity with Kubernetes namespaces and pods
OpenSSL available for generating user certificates (optional, for kubeconfig section)

Step 1 — Understand RBAC Concepts

Kubernetes RBAC uses four object types. A Role grants permissions within a single namespace. A ClusterRole grants permissions cluster-wide or to non-namespaced resources. A RoleBinding attaches a Role or ClusterRole to subjects (users, groups, or ServiceAccounts) within a namespace. A ClusterRoleBinding attaches a ClusterRole to subjects across the entire cluster.

# List all cluster-wide RBAC resources
kubectl get clusterroles
kubectl get clusterrolebindings

# List namespace-scoped RBAC resources in the default namespace
kubectl get roles -n default
kubectl get rolebindings -n default

Kubernetes ships with several pre-built ClusterRoles: view (read-only access), edit (read-write, no RBAC changes), and admin (full namespace control excluding quota/LimitRange). Use these before creating custom roles when possible.

Step 2 — Create a Namespace-Scoped Role

Save the following YAML as pod-reader-role.yaml. This Role allows listing, getting, and watching pods in the dev namespace only.

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

kubectl create namespace dev
kubectl apply -f pod-reader-role.yaml
kubectl get role pod-reader -n dev -o yaml

Step 3 — Create a RoleBinding

A RoleBinding connects the pod-reader Role to a specific user. Save the following as pod-reader-binding.yaml, replacing alice with the actual username in your cluster’s authentication system.

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

kubectl apply -f pod-reader-binding.yaml
kubectl get rolebinding pod-reader-binding -n dev -o yaml

Step 4 — Create a ServiceAccount and Bind a Role

Pods authenticate to the API server using ServiceAccounts, not user certificates. Create a ServiceAccount and give it read access to ConfigMaps in the dev namespace so an application pod can read its own configuration.

kubectl create serviceaccount config-reader -n dev

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: configmap-reader
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: configmap-reader-binding
  namespace: dev
subjects:
  - kind: ServiceAccount
    name: config-reader
    namespace: dev
roleRef:
  kind: Role
  name: configmap-reader
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f configmap-reader.yaml

Step 5 — Verify Permissions with kubectl auth can-i

Use kubectl auth can-i to check permissions for any subject without needing to switch contexts. This is invaluable for auditing RBAC rules.

# Check what the current user can do
kubectl auth can-i --list -n dev

# Check if 'alice' can list pods in the dev namespace
kubectl auth can-i list pods -n dev --as=alice

# Check if 'alice' can delete pods (should be denied)
kubectl auth can-i delete pods -n dev --as=alice

# Check ServiceAccount permissions
kubectl auth can-i get configmaps -n dev 
  --as=system:serviceaccount:dev:config-reader

Step 6 — Generate a Restricted kubeconfig for a User

Create a client certificate for alice, sign it with the cluster CA, and embed it in a kubeconfig that restricts her to the dev namespace.

# Generate private key and CSR
openssl genrsa -out alice.key 2048
openssl req -new -key alice.key -out alice.csr -subj "/CN=alice/O=dev-team"

# Sign with cluster CA (adjust path to your CA files)
sudo openssl x509 -req -in alice.csr 
  -CA /etc/kubernetes/pki/ca.crt 
  -CAkey /etc/kubernetes/pki/ca.key 
  -CAcreateserial -out alice.crt -days 365

# Build kubeconfig for alice
kubectl config set-cluster mycluster 
  --certificate-authority=/etc/kubernetes/pki/ca.crt 
  --server=https://$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}' | sed 's|https://||') 
  --kubeconfig=alice-kubeconfig.yaml

kubectl config set-credentials alice 
  --client-certificate=alice.crt 
  --client-key=alice.key 
  --kubeconfig=alice-kubeconfig.yaml

kubectl config set-context alice-context 
  --cluster=mycluster 
  --namespace=dev 
  --user=alice 
  --kubeconfig=alice-kubeconfig.yaml

kubectl config use-context alice-context --kubeconfig=alice-kubeconfig.yaml

Test the restricted kubeconfig:

kubectl get pods -n dev --kubeconfig=alice-kubeconfig.yaml
kubectl get pods -n kube-system --kubeconfig=alice-kubeconfig.yaml  # should be denied

Conclusion

You have implemented Kubernetes RBAC on RHEL 8 from the ground up: creating namespace-scoped Roles with precise resource and verb rules, binding them to users and ServiceAccounts via RoleBindings, auditing permissions with kubectl auth can-i, and generating a certificate-backed kubeconfig for a restricted developer account. Applying least-privilege RBAC policies is one of the highest-impact security controls you can apply to a Kubernetes cluster.

Next steps: Audit existing ClusterRoleBindings for overly broad cluster-admin grants, Integrate RBAC with an OIDC identity provider for SSO, and Use OPA Gatekeeper to enforce RBAC policy as code.