Master Kubernetes RBAC: Create Users, Roles, and Token Authentication Step‑by‑Step

1. Identity Authentication

In a Kubernetes cluster only the master node has a KUBECONFIG environment variable pointing to /etc/kubernetes/admin.conf. Attempting to run kubectl get nodes on a worker node fails because the kubeconfig is missing. kubectl get nodes Copy the admin kubeconfig to a worker node and set the KUBECONFIG variable to enable kubectl commands:

# Copy admin.conf to node1
scp /etc/kubernetes/admin.conf node1:~
# Use the copied config
export KUBECONFIG=/root/admin.conf
kubectl get nodes

Node Operations

After copying the config, the worker node can query the cluster, but commands must reference the config file unless the variable is set globally.

# Append the export to /etc/profile
echo "export KUBECONFIG=/root/admin.conf" >> /etc/profile

Creating a Regular User and Granting Permissions

1. Generate a Private Key

openssl genrsa -out client.key 2048

2. Create a Certificate Signing Request (CSR)

openssl req -new -key client.key -subj "/CN=zhangsan" -out client.csr

3. Sign the CSR with the Kubernetes CA

openssl x509 -req -in client.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out client.crt -days 3650

4. Create a Namespace and a Test Pod

kubectl create ns zhangsan
kubectl config set-context --current --namespace zhangsan
kubectl run test01 --image nginx --image-pull-policy IfNotPresent

5. Create a Role

# Role that can read pods
kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods

6. Bind the Role to the User

kubectl create rolebinding zhangsan --role=pod-reader --user=zhangsan

7. Edit the kubeconfig for the New User

Reference the official kubeconfig documentation for the file structure.

# Set cluster entry
kubectl config --kubeconfig=kube-zhangsan set-cluster cluster-zs --server=https://<master-ip>:6443 --certificate-authority=ca.crt --embed-certs=true
# Set user credentials
kubectl config --kubeconfig=kube-zhangsan set-credentials zhangsan --client-certificate=client.crt --client-key=client.key --embed-certs=true
# Set context
kubectl config --kubeconfig=kube-zhangsan set-context context-zs --cluster=cluster-zs --namespace=zhangsan --user=zhangsan

8. Verify Permissions

Using the new kubeconfig, the user can list pods in its namespace but cannot create pods or list namespaces, confirming the least‑privilege setup.

# List pods (allowed)
kubectl get pods --kubeconfig=kube-zhangsan
# Attempt to create a pod (forbidden)
kubectl run test02 --image nginx --kubeconfig=kube-zhangsan
# Attempt to list namespaces (forbidden)
kubectl get ns --kubeconfig=kube-zhangsan

Static Token Login

Generate a token‑based CSV file and configure the API server to use it.

# Generate token file
openssl rand -hex 10 > /etc/kubernetes/pki/jerry.csv
# Example line: 3127c2e2b863d4c23878a,jerry,2000

Add the --token-auth-file flag to kube-apiserver.yaml and restart the kubelet.

# Edit manifest
- --token-auth-file=/etc/kubernetes/pki/jerry.csv
systemctl restart kubelet

Login with the token (skip TLS verification for testing):

kubectl --server=https://<master-ip>:6443 --token=3127c2e2b863d4c23878a --insecure-skip-tls-verify=true get pod -n default

Role and RoleBinding

Create a role named jerry that can get, list, and watch pods, then bind it to the token user.

# Create role (dry‑run to YAML)
kubectl create role jerry --verb=get --verb=list --verb=watch --resource=pods --dry-run=client -o yaml > jerry.yaml
kubectl apply -f jerry.yaml
# Bind role to user
kubectl create rolebinding jerry --role=jerry --user=jerry --token="3127c2e2b863d4c23878a"

Verify the user can list pods but cannot create them. Extend the role by adding create verb to allow pod creation.

# Edit jerry.yaml to add create verb
# Apply updated role
kubectl apply -f jerry.yaml
# Now the user can create pods
kubectl run test02 --image nginx --kubeconfig=kube-zhangsan

Extending Permissions for Deployments

To allow deployment creation, add the deployments resource and the apps API group to the role.

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

After applying the updated role, the user can create a deployment but initially cannot scale it. Add deployments/scale and the patch verb to the role to enable scaling.

# Updated role includes deployments/scale and patch verb
- apiGroups: ["", "apps"]
  resources: ["pods", "deployments", "deployments/scale"]
  verbs: ["get", "list", "watch", "create", "patch"]

Apply the role and the user can now scale the deployment:

kubectl scale deployment test03 --replicas=3 --kubeconfig=kube-zhangsan

ClusterRole and ClusterRoleBinding

ClusterRoles are cluster‑wide templates. Create a cluster-pod ClusterRole that can read pods across all namespaces.

kubectl create clusterrole cluster-pod --verb=get,list,watch --resource=pods --dry-run=client -o yaml > clusterrole.yaml
kubectl apply -f clusterrole.yaml

Bind the ClusterRole to a token user using clusterrolebinding:

kubectl create clusterrolebinding cluster-tom --clusterrole=cluster-pod --user=tom --token="958a15cfa9431e088e0b"

After binding, the user can list pods in any namespace, demonstrating the difference between Role (namespace‑scoped) and ClusterRole (cluster‑scoped).

# List pods in default namespace
kubectl get pods --server=https://<master-ip>:6443 --token=958a15cfa9431e088e0b --insecure-skip-tls-verify=true -n default
# List pods in kube-system namespace
kubectl get pods --server=https://<master-ip>:6443 --token=958a15cfa9431e088e0b --insecure-skip-tls-verify=true -n kube-system