Why the pods in Kubernetes are automounting the service accounts secret?

Question

Need to understand why pods are automounting the service accounts secret.

If we disable the automout of service account, will this affect any operation of our application which is already have service account specified in the pod spec part, but automount of the service account is not disabled.

Quita

It's a default. "In version 1.6+, you can opt out of automounting API credentials for a service account by setting automountServiceAccountToken: false on the service account" - see here – Vinny

But disabling the servie account automount will affect the application? Why its enabled by default since its not a recommnded way to enable as per security considerations – Quita

Hello @Vowner. Could you share your current yaml configs? – Jolynjolynn

We are using normal deployment yaml with a service account mentioned in the pods spec. So I understood that this service account will be created when the deployment created. But would like to understand why the secrete of the Service account getting mounted to the pods eventhough it's a security escalation. What is the benefits by automounting the secrets inside pod by default and if we disable this , what will be the impact. Or how we can remediate this security vulnerability – Quita

Answer 1

How to disable automounting of the service account is explained in the linked documentation:

In version 1.6+, you can opt out of automounting API credentials for a service account by setting automountServiceAccountToken: false on the service account.

In version 1.6+, you can also opt out of automounting API credentials for a particular pod.

There are also some solutions suggested to mitigate the security issue:

• Using RBAC

• Using mutating webhooks

---

If we disable the automout of service account, will this affect any operation of our application which is already have service account specified in the pod spec part

If you disable automounting of the SA secret, the Pod won't be able to access the K8s API server or do any other operation that requires authenticating as a Service Account. It's hard to tell if that would impact your workload or not, only you can tell. A web server or a worker Pod that only talks to other user-defined services might do fine without SA access, but if they want e.g. to spawn K8s Jobs from an application Pod they would need the SA.

---

But would like to understand why the secrete of the Service account getting mounted to the pods eventhough it's a security escalation.

The point seems to be, as often in computer security, that we need to weigh convenience vs security. Automatically mounting SA secretes into a Pod makes it easy (=> goes to convenience) to use K8s API. Disabling this by default is more secure but also less convenient, as you need to explicitly mark those Pods that need access to the K8s API. Whether this is too much of a burden depends very much on the workload, and there's likely no default answer that fits everyone.

---

Why was it not changed to the more secure default?

This was answered here:

disabling by default is not backwards compatible, so is not a realistic option until (if) a v2 Pod API is made

and here:

I'm not saying that it's unreasonable, just that it's going to be a hard pill to swallow for GA distributions of Kubernetes. I could see this happening in the v2 pod API.

Propagation

Answer 2

If you're using workload identity to access azure services from your pod, then I believe you need the service account token. This is because the k8s service account token is exchanged for an azure service token by your pod's Azure CLI or SDK.

The Application Insights library for some runtimes, such as dotnet, makes use of the service account token to collect information about the deployment environment via the k8s API. The one for Java does not.

Hardi