Search code examples
kubernetesazure-akskubernetes-pod

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

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.

Solution

  • 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:

    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.