Kubernetes User Accounts vs Service Accounts: Deep Dive with Real-World Examples

Kubernetes is one of the most powerful container orchestration platforms, but it comes with a steep learning curve—especially when it comes to understanding authentication and authorization.

One common point of confusion for beginners and even intermediate users is the difference between Kubernetes User Accounts and Service Accounts. In this blog post, we’ll explore both concepts thoroughly, with real-world examples and best practices.

🔑 Authentication in Kubernetes

Kubernetes does not have a built-in user management system like Linux. Instead, it relies on external identity providers (e.g., certificates, OAuth, LDAP) for User Accounts and uses built-in mechanisms for Service Accounts.

Authentication in Kubernetes is the process of identifying who is making a request to the API server.

👤 What is a User Account?

A User Account in Kubernetes represents a real human who interacts with the cluster, typically via kubectl or CI/CD pipelines.

User accounts are not managed by Kubernetes directly. Instead, they are managed outside the cluster—e.g., by your company’s identity provider, a certificate authority, or a third-party auth system (e.g., OIDC, Google, AWS IAM).

🔐 User Authentication via Client Certificate

Here’s how you can create a user account manually using client certificates (for lab or test purposes):

✅ Step-by-Step: Creating a Kubernetes User Account (using certificates)

1. Generate private key and certificate signing request (CSR)

openssl genrsa -out imran.key 2048
openssl req -new -key imran.key -out imran.csr -subj "/CN=imran/O=devops-team"

2. Sign the certificate with the Kubernetes CA

openssl x509 -req -in imran.csr -CA /etc/kubernetes/pki/ca.crt \
  -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out imran.crt -days 365

3. Configure kubeconfig

kubectl config set-credentials imran --client-certificate=imran.crt --client-key=imran.key
kubectl config set-context imran-context --cluster=kubernetes --user=imran
kubectl config use-context imran-context

4. Create RBAC Role and RoleBinding

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

# imran-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: imran
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f imran-role.yaml
kubectl apply -f imran-rolebinding.yaml

Now the user imran can list pods in the default namespace.

🤖 What is a Service Account?

A Service Account is an account used by pods, controllers, and apps inside the cluster to interact with the Kubernetes API.

Unlike user accounts, service accounts are managed within Kubernetes itself and are automatically mounted into pods at /var/run/secrets/kubernetes.io/serviceaccount.

🔧 Default Service Account

Every namespace has a default service account, and if you don’t explicitly assign one, pods will use the default.

kubectl get serviceaccounts -n default

✅ Step-by-Step: Creating a Custom Service Account

1. Create a service account

kubectl create serviceaccount myapp-sa -n default

2. Attach the service account to a pod

# pod-with-sa.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  serviceAccountName: myapp-sa
  containers:
  - name: mycontainer
    image: busybox
    command: ["sh", "-c", "sleep 3600"]

kubectl apply -f pod-with-sa.yaml

3. Verify the token in the pod

kubectl exec -it myapp -- cat /var/run/secrets/kubernetes.io/serviceaccount/token

This token is automatically used by the pod to authenticate to the Kubernetes API.

🛡 Assigning Permissions to Service Accounts

Just like user accounts, service accounts need Role or ClusterRole and RoleBinding/ClusterRoleBinding.

# sa-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: sa-pod-reader
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

# sa-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: sa-pod-read-access
  namespace: default
subjects:
- kind: ServiceAccount
  name: myapp-sa
  namespace: default
roleRef:
  kind: Role
  name: sa-pod-reader
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f sa-role.yaml
kubectl apply -f sa-rolebinding.yaml

🧮 User Account vs Service Account: Summary Table

---

🚨 Best Practices

• ✅ Always use service accounts for in-cluster communication.

• ✅ Do not use default service accounts in production. Create specific ones per app.

• ✅ Bind least privilege RBAC roles to accounts.

• ✅ Rotate and monitor credentials for long-lived user accounts.

• ✅ Use OIDC or cloud IAM integration for real user authentication in production.

---

📦 Real-World Use Case: CI/CD with Service Account

Imagine your Jenkins or GitHub Actions runner runs inside your cluster. You can:

• Create a namespace ci

• Create a ci-runner service account

• Bind a ClusterRole that allows creating pods/deployments

• Mount the token in your pipeline pod to interact with the cluster safely.

---

🔚 Conclusion

Kubernetes makes a clear distinction between users (humans) and services (pods). Understanding this distinction and applying correct RBAC permissions is critical for cluster security and observability.

Whether you’re building microservices, managing clusters, or automating deployments, this knowledge is foundational.

---

👉 Have you worked with custom service accounts before? Share your experience in the comments!