17

The API credentials for service accounts are normally mounted in pods as:

/var/run/secrets/kubernetes.io/serviceaccount/token

This token allows containerized processes in the pod to communicate with the API server.

What's the purpose of a pod's service account (serviceAccountName), if automountServiceAccountToken is set to false?

Ivan Aracki
  • 4,861
  • 11
  • 59
  • 73
Shuzheng
  • 11,288
  • 20
  • 88
  • 186

1 Answers1

12

A little of theory:

Let's start with what happens when pod should be created.

When you create a pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace

Reference.

So all pods are linked to service account anyway (default or specified in spec).

Then API access token is always generated for each service account.

automountServiceAccountToken flag defines if this token will automatically mounted to the pod after it has been created.

There are two options where to set this flag:

  • In a specific service account

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot
automountServiceAccountToken: false
...

  • In a specific pod

    apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: build-robot
  automountServiceAccountToken: false
  ...

Answer:

What's the purpose of a pod's service account (serviceAccountName), if automountServiceAccountToken is set to false?

It may make a difference depending on what processes are involved in pod creation. Good example is in comments in GitHub issue (where this flag eventually came from):

There are use cases for still creating a token (for use with external systems) or still associating a service account with a pod (for use with image pull secrets), but being able to opt out of API token automount (either for a particular pod, or for a particular service account) is useful.

lindhe
  • 806
  • 2
  • 14
  • 32
moonkotte
  • 3,661
  • 2
  • 10
  • 25
  • Thanks. I didn't knew that the service account was related to image pull secrets. Do you know what external systems are referred too in your quote? The API token is stored in `etcd`, so how would external systems know of it? – Shuzheng Oct 07 '21 at 07:35
  • For `imagePullSecrets` - this is related to private registry and credentials stored within secret, you can find [full example and details](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#create-a-pod-that-uses-your-secret). About `etcd` you're correct - all interactions happen via `api server`. – moonkotte Oct 07 '21 at 11:09
  • From my understanding, most common use case of `external systems` is different authenticators. A bit below [here](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens) there's a quote `Service account bearer tokens are perfectly valid to use outside the cluster and can be used to create identities for long standing jobs that wish to talk to the Kubernetes API.`. As for exact examples, unfortunately I can't tell you for sure. – moonkotte Oct 07 '21 at 11:10
  • Would like to ask if in a pod, I define only serviceAccountName but do not include "automountServiceAccountToken: false". Will the default token still be mounted to the pod? – Huiting Jul 14 '22 at 03:18
  • 2
    Note that this behaviour has changed as of v1.25.0 – lindhe Jan 17 '23 at 14:56
  • 1
    @moonkotte what i get from this explanation is that setting this attribute to false will not mount the token to pod. This will prevent attackers from gaining access to the cluster and performing operations. But as k8s rookie and someone who never had to deal with imagePullSecrets and stuff, could you please elaborate a little more on how it will be used? SA token is needed to pull images? like from a private registry? – Aniket Kariya Mar 05 '23 at 20:34