Master Kubernetes ServiceAccount, RBAC, and Config Management: A Step‑by‑Step Guide

1. ServiceAccount (SA)

ServiceAccount is designed for processes inside Pods to call the Kubernetes API or external services. It is namespace‑scoped, and each namespace automatically gets a default ServiceAccount. The Token controller creates a secret for each ServiceAccount.

When the ServiceAccount Admission Controller is enabled, every new Pod gets spec.serviceAccount set to default unless another ServiceAccount is specified. The controller also mounts the ServiceAccount token and ca.crt into /var/run/secrets/kubernetes.io/serviceaccount/.

# vim 01_k8s_pod_test.yml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: superopsmsb-sa
---
apiVersion: v1
kind: Pod
metadata:
  name: my-nginx-1
spec:
  containers:
  - image: nginx:1.23.0
    name: my-nginx
  serviceAccountName: superopsmsb-sa

# kubectl apply -f 01_k8s_pod_test.yml
# kubectl get sa
# kubectl get pods -o wide
# kubectl describe pod my-nginx-1

2. User Account (UA)

Create a user certificate signing request (CSR) and generate a client certificate using cfssl. Then configure a kubeconfig file that references the certificate, key, and cluster information.

# vim test-csr.json
{
  "CN": "test",
  "hosts": [],
  "key": {"algo": "rsa", "size": 2048},
  "names": [{"C": "CN", "ST": "Beijing", "L": "Beijing", "O": "system:test", "OU": "system"}]
}

# cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes test-csr.json | cfssljson -bare test
# cp test*.pem /etc/kubernetes/ssl/

# kubectl config set-cluster kubernetes --certificate-authority=ca.pem --embed-certs=true --server=https://192.168.16.250:16443 --kubeconfig=test.kubeconfig
# kubectl config set-credentials test --client-certificate=test.pem --client-key=test-key.pem --embed-certs=true --kubeconfig=test.kubeconfig
# kubectl config set-context kubernetes --cluster=kubernetes --user=test --kubeconfig=test.kubeconfig
# kubectl config use-context kubernetes --kubeconfig=test.kubeconfig
# kubectl --kubeconfig=test.kubeconfig get pods

3. kubeconfig File

The kubeconfig file defines the user, cluster address, and context that bind them together. Its precedence is: --kubeconfig flag specifies a file.

Environment variable KUBECONFIG.

Default location /root/.kube/config.

4. Role Creation

A Role defines a set of permissions on resources within a namespace.

# kubectl create role myrole --verb=get,list --resource=pods --dry-run=client -o yaml > 02_k8s_secure_role.yaml
# vim 02_k8s_secure_role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: myrole
rules:
- apiGroups: ["", "apps"]
  resources: ["pods", "deployments", "replicasets"]
  verbs: ["get", "list", "delete"]
# kubectl apply -f 02_k8s_secure_role.yaml
# kubectl describe role myrole

5. RoleBinding Creation

RoleBinding links a Role to a user or group.

# kubectl create rolebinding test-myrole --role=myrole --user=test --dry-run=client -o yaml > 03_k8s_test-myrole.yaml
# kubectl apply -f 03_k8s_test-myrole.yaml
# kubectl describe rolebinding test-myrole

6. ClusterRole and ClusterRoleBinding

ClusterRole grants permissions cluster‑wide, and ClusterRoleBinding binds it to a user.

# kubectl create clusterrole myclusterrole --verb=get,list,delete --resource=pods --dry-run=client -o yaml > 04_k8s_secure_clusterrole.yaml
# kubectl apply -f 04_k8s_secure_clusterrole.yaml
# kubectl create clusterrolebinding test-myclusterrole --clusterrole=myclusterrole --user=test
# kubectl get pods --kubeconfig=test.kubeconfig -n kube-system

By combining Role/ClusterRole with RoleBinding/ClusterRoleBinding, you can grant cluster‑wide capabilities while still restricting actions to specific namespaces.