Configure Service Accounts for Pods [page]deterministic

tasksnetworking

Kubernetes offers two distinct ways for clients that run within your cluster, or that otherwise have a relationship to your cluster's [control plane](#gloss:control-plane) to authenticate to the [API server](#gloss:kube-apiserver).

A _service account_ provides an identity for processes that run in a Pod, and maps to a ServiceAccount object. When you authenticate to the API server, you identify yourself as a particular _user_. Kubernetes recognises the concept of a user, however, Kubernetes itself does not have a User API.

This task guide is about ServiceAccounts, which do exist in the Kubernetes API. The guide shows you some ways to configure ServiceAccounts for Pods.

## Use the default service account to access the API server

When Pods contact the API server, Pods authenticate as a particular ServiceAccount (for example, `default`). There is always at least one ServiceAccount in each [namespace](#gloss:namespace).

Every Kubernetes namespace contains at least one ServiceAccount: the default ServiceAccount for that namespace, named `default`. If you do not specify a ServiceAccount when you create a Pod, Kubernetes automatically assigns the ServiceAccount named `default` in that namespace.

You can fetch the details for a Pod you have created. For example:

```shell kubectl get pods/<podname> -o yaml ```

In the output, you see a field `spec.serviceAccountName`. Kubernetes automatically sets that value if you don't specify it when you create a Pod.

An application running inside a Pod can access the Kubernetes API using automatically mounted service account credentials. See [accessing the Cluster](/docs/tasks/access-application-cluster/access-cluster/) to learn more.

When a Pod authenticates as a ServiceAccount, its level of access depends on the [authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules) in use.

The API credentials are automatically revoked when the Pod is deleted, even if finalizers are in place. In particular, the API credentials are revoked 60 seconds beyond the `.metadata.deletionTimestamp` set on the Pod (the deletion timestamp is typically the time that the delete request was accepted plus the Pod's termination grace period).

### Opt out of API credential automounting

If you don't want the [kubelet](#gloss:kubelet) to automatically mount a ServiceAccount's API credentials, you can opt out of the default behavior. You can opt out of automounting API credentials on `/var/run/secrets/kubernetes.io/serviceaccount/token` for a service account by setting `automountServiceAccountToken: false` on the ServiceAccount:

For example:

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

You can also opt out of automounting API credentials for a particular Pod:

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

If both the ServiceAccount and the Pod's `.spec` specify a value for `automountServiceAccountToken`, the Pod spec takes precedence.

## Use more than one ServiceAccount {#use-multiple-service-accounts}

Every namespace has at least one ServiceAccount: the default ServiceAccount resource, called `default`. You can list all ServiceAccount resources in your [current namespace](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference) with:

```shell kubectl get serviceaccounts ```

The output is similar to this:

``` NAME SECRETS AGE default 1 1d ```

You can create additional ServiceAccount objects like this:

```shell kubectl apply -f - <<EOF apiVersion: v1 kind: ServiceAccount metadata: name: build-robot EOF ```

The name of a ServiceAccount object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).

If you get a complete dump of the service account object, like this:

…(trimmed)