User vs. ServiceAccounts for Kubernetes Authentication

The Two Core Questions of Access Control

Before we discuss different account types, it's essential to understand the two questions that any security system must answer:

1. Authentication (AuthN): Who are you? This is the process of verifying identity. Are you really the user or process you claim to be?
2. Authorization (AuthZ): What can you do? Once your identity is confirmed, this is the process of checking if you have permission to perform the requested action (e.g., create a Pod, delete a Secret).

Kubernetes handles these two processes separately. Today, we are focusing on authentication—how Kubernetes knows who is making a request.

This visual helps set the stage for the two types of identities we'll be discussing: those for humans and those for automated processes.

1. User Accounts: The Outsiders

In Kubernetes, a user account is meant for a human—a developer, an SRE, or a cluster administrator who interacts with the cluster from the outside, typically using kubectl or another client.

The most surprising and crucial thing to understand is that Kubernetes does not have a native object for users. You cannot run kubectl create user <username>. Instead, Kubernetes expects user identities to be managed externally.

As the article highlights, a user's identity is established by an external system and presented to the Kubernetes API server for authentication. Common methods include:

• Client Certificates: A user presents a certificate signed by the cluster's Certificate Authority (CA). The Common Name (CN) in the certificate's subject becomes the username.
• Cloud IAM Integration: This is highly relevant given your experience with AWS, Azure, and GCP. In managed services like EKS, AKS, and GKE, you don't create users in Kubernetes. Instead, you grant cluster access to existing IAM users or roles. The cloud provider handles the authentication and passes a verified identity to Kubernetes.
• OIDC Providers: Using external identity providers like Okta, Azure AD, or Keycloak to manage users and issue tokens that the Kubernetes API server can validate.

The key takeaway is that user accounts are not part of the Kubernetes cluster's internal state. They are authenticated based on credentials managed elsewhere.

2. ServiceAccounts: The Insiders

A ServiceAccount, on the other hand, provides an identity for processes running inside Pods within the cluster. Think of them as the equivalent of IAM roles for your EC2 instances or managed identities for your Azure VMs, but specifically for Kubernetes Pods.

Unlike users, ServiceAccounts are native Kubernetes objects. You can create, view, and manage them with kubectl. Their primary purpose is to allow an application to authenticate to the Kubernetes API server so it can perform actions on the cluster, such as:

• A monitoring agent (like Prometheus) that needs to discover and scrape metrics from Pods.
• A CI/CD tool (like ArgoCD or Flux) that needs to create or update Deployments.
• An application that needs to read a ConfigMap or Secret.

Let's watch a short video that introduces this concept.

As the video explains, every Pod that runs in a cluster is assigned a ServiceAccount. If you don't specify one, it automatically gets the default ServiceAccount from its namespace. This ServiceAccount's authentication token is automatically mounted into the Pod, making it available for the application to use when calling the API server.

3. The Direct Comparison: User vs. ServiceAccount

We've established that users are for humans (external) and ServiceAccounts are for pods (internal). The official Kubernetes documentation provides a perfect summary of these differences.

Here is that comparison, which is essential to commit to memory:

Let's break this down:

• Location: This is the most fundamental difference. ServiceAccounts are resources that live in the cluster, defined by YAML and managed via the Kubernetes API. Users do not live in the cluster; their identities are asserted from the outside.
• Intended Use: This reinforces our main point. You should never give human user credentials (like a kubeconfig file) to an application running in a Pod. That's what ServiceAccounts are for. The principle is humans ≠ workloads.
• Access Control: While both can be granted permissions using Kubernetes RBAC (which we'll cover soon), the "subject" of those permissions is different. For a ServiceAccount, you grant permissions to a specific, namespaced Kubernetes object. For a user, you grant permissions to a string (the username) that corresponds to an external identity.

Conclusion

You have now learned the crucial difference between the two primary identity types in Kubernetes. This foundational knowledge is essential for building secure and maintainable clusters.

Key Takeaways:

• User Accounts are for humans interacting with the cluster from the outside. They are not native Kubernetes objects and are managed by external identity systems (like Cloud IAM or OIDC).
• ServiceAccounts are for processes/workloads running inside Pods. They are native Kubernetes objects and provide a way for applications to securely authenticate with the API server.
• The guiding principle is to use the right identity for the job: Users for people, ServiceAccounts for bots/processes.

Next Up:
Now that you can differentiate between these two identity types, our next lesson will dive deeper into the practical application of ServiceAccounts. We will explore the role of ServiceAccounts in providing an identity for pods to interact with the API server, see how tokens are mounted, and prepare to bind permissions to them.