Kubernetes Myth #12: K8s Service Account Pulls Images

🔍 Myth: "A Kubernetes ServiceAccount is responsible for pulling container images."

💡 Reality: The Container Runtime on the worker node—not the ServiceAccount—pulls container images from the registry!

This misconception often leads to confusion when working with private registries and authentication. Let’s dive into the real mechanism.

🚀 Deep Dive: How Kubernetes Pulls Images

When a Pod is scheduled, Kubernetes ensures that the required container images are available on the node. But Kubelet itself does not pull images—it delegates this task to the container runtime (containerd, CRI-O, Docker).

Step-by-Step Image Pulling Process

Pod Creation & Scheduling:

• A user applies a Pod spec with an image (nginx:latest).

• The Kubernetes scheduler assigns the Pod to a node.

Kubelet Contacts the Container Runtime:

• Kubelet detects that a new Pod needs to run on its node.

• It checks if the required image is already present.

• If not, Kubelet instructs the container runtime to pull the image via the Container Runtime Interface (CRI).

Container Runtime Handles Authentication & Pulling:

• The container runtime (e.g., containerd, CRI-O) authenticates with the container registry.

• It checks for imagePullSecrets (for private registries).

• It fetches the image from the specified container registry (Docker Hub, ECR, GCR, etc.).

• Once downloaded, the image is stored locally on the node.

Container is Started:

• The container runtime unpacks the image and starts the container.

• Kubelet monitors the container's lifecycle.

🛑 ServiceAccount is NOT involved in this process! It does not fetch images or interact with the container registry.

🔑 What is a Kubernetes ServiceAccount Actually For?
A ServiceAccount in Kubernetes is used for Pod-to-API-Server authentication, not for pulling images. Here’s what it does:

• It provides a secure identity for Pods to interact with the Kubernetes API.
• It is automatically mounted into Pods to authenticate API requests.
• It can be used to manage RBAC permissions for Pods.
• It has NOTHING to do with pulling images from a registry!

🔥 Why Do People Think ServiceAccounts Pull Images?
This myth exists because:

• ImagePullSecrets can be linked to a ServiceAccount, making it seem like the ServiceAccount is responsible for authentication.
• ServiceAccount tokens are automatically mounted into Pods, leading to confusion about their purpose.
• Both ServiceAccounts and imagePullSecrets handle authentication, but for different things (API access vs. registry authentication).

✅ How to Pull Images Correctly in Kubernetes?

If your images are public, Kubernetes pulls them without any authentication. But for private registries, you must provide credentials explicitly using imagePullSecrets:

• Option 1: Define imagePullSecrets in the Pod

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: app
      image: my-private-registry.com/my-app:v1
  imagePullSecrets:
    - name: my-registry-secret

• Option 2: Attach imagePullSecrets to a ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-sa
imagePullSecrets:
  - name: my-registry-secret

Then reference the ServiceAccount in your Pod:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  serviceAccountName: my-sa
  containers:
    - name: app
      image: my-private-registry.com/my-app:v1

Even though we attach imagePullSecrets to a ServiceAccount, it's still the Container Runtime that pulls the image—not the ServiceAccount!

🎯 Key Takeaways – Myth Busted!
🚫 Kubernetes ServiceAccounts DO NOT pull container images.
✅ Kubelet pulls images using the container runtime.
✅ Use imagePullSecrets for private registries.
✅ ServiceAccounts handle API authentication, not image pulling.

Next time someone says, “ServiceAccount pulls images”, you’ll know the truth!