Managing ServiceAccounts for Pods

1. Why Create Custom ServiceAccounts?

Before we jump into the "how," let's solidify the "why." Using the default ServiceAccount for all your applications is a security anti-pattern. If you grant permissions to the default account to make one application work, you inadvertently grant those same permissions to every other application in that namespace that doesn't have a specific ServiceAccount assigned.

If a single one of those applications has a vulnerability, an attacker could potentially leverage the default ServiceAccount's permissions to move laterally within your cluster.

By creating a unique ServiceAccount for each application or logical group of applications, you isolate their identities and can grant them only the precise permissions they need to function.

2. Creating and Assigning a ServiceAccount

Creating and using a new ServiceAccount is a two-step process:

1. Define and create the ServiceAccount object itself.
2. Modify your Pod's manifest to use this new ServiceAccount.

Given your experience with Terraform, you'll appreciate that the preferred way to manage Kubernetes resources is declaratively, using YAML manifests.

Step 1: Create the ServiceAccount

A ServiceAccount is a very simple object. At its most basic, it just needs a name.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa

You can save this as a .yaml file and apply it with kubectl apply -f <filename>.yaml.

Step 2: Use the ServiceAccount in a Pod

To tell a Pod to use your new ServiceAccount, you add the serviceAccountName field to the Pod's spec.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  serviceAccountName: my-app-sa  # This line assigns the ServiceAccount
  containers:
  - name: my-app-container
    image: nginx

When this Pod is created, the kubelet will mount the token from my-app-sa instead of the default one.

3. A Complete End-to-End Demonstration

Let's watch a video that ties everything together. It will demonstrate creating a custom ServiceAccount, assigning it to a Pod, and then—crucially—showing how that Pod can be granted permissions that the default account doesn't have. This will give you a concrete example and a perfect preview of our next lesson.

This demonstration makes the entire concept tangible. Creating a ServiceAccount gives your Pod a unique name badge (authentication), but that badge is useless until you add it to an access list (authorization via RBAC).

The diagram below visualizes this relationship. Our focus today is on the link between the Pod and the ServiceAccount. The video gave you a preview of how that ServiceAccount is then linked to permissions via a RoleBinding.

Conclusion

You've now learned the practical steps for creating and assigning unique identities to your in-cluster applications. This is a fundamental security practice in Kubernetes that moves you from a novice user to a security-conscious platform engineer.

Key Takeaways:

• Always create custom ServiceAccounts for your workloads to adhere to the principle of least privilege. Avoid granting permissions to the default ServiceAccount.
• A ServiceAccount is a simple API object created via a YAML manifest or kubectl create serviceaccount.
• Assign a custom ServiceAccount to a Pod by setting the serviceAccountName field in the Pod's spec.
• A new ServiceAccount has an identity but no permissions by default. Granting permissions is a separate authorization step.

Next Up:
In this lesson, we saw a preview of how a RoleBinding can grant permissions. In our next session, we will dive deep into that topic. You will learn to configure namespace-scoped RBAC using Roles and RoleBindings, giving you full control over what your applications are allowed to do.