WARNING WARNING WARNING WARNING WARNING

PLEASE NOTE: This document applies to the HEAD of the source tree

If you are using a released version of Kubernetes, you should refer to the docs that go with that version. The latest 1.0.x release of this document can be found [here](http://releases.k8s.io/release-1.0/docs/user-guide/service-accounts.md). Documentation for other releases can be found at [releases.k8s.io](http://releases.k8s.io). -- # Service Accounts A service account provides an identity for processes that run in a Pod. *This is a user introduction to Service Accounts. See also the [Cluster Admin Guide to Service Accounts](../admin/service-accounts-admin.md).* *Note: This document describes how service accounts behave in a cluster set up as recommended by the Kubernetes project. Your cluster administrator may have customized the behavior in your cluster, in which case this documentation may not apply.* When you (a human) access the cluster (e.g. using kubectl), you are authenticated by the apiserver as a particular User Account (currently this is usually "admin", unless your cluster administrator has customized your cluster). Processes in containers inside pods can also contact the apiserver. When they do, they are authenticated as a particular Service Account (e.g. "default"). ## Using the Default Service Account to access the API server. When you create a pod, you do not need to specify a service account. It is automatically assigned the `default` service account of the same namespace. If you get the raw json or yaml for a pod you have created (e.g. `kubectl get pods/podname -o yaml`), you can see the `spec.serviceAccount` field has been [automatically set](working-with-resources.md#resources-are-automatically-modified). You can access the API using a proxy or with a client library, as described in [Accessing the Cluster](accessing-the-cluster.md#accessing-the-api-from-a-pod). ## Using Multiple Service Accounts. Every namespace has a default service account resource called "default". You can list this and any other serviceAccount resources in the namespace with this command: ```console $ kubectl get serviceAccounts NAME SECRETS default 1 ``` You can create additional serviceAccounts like this: ```console $ cat > /tmp/serviceaccount.yaml < Note that if a pod does not have a `ServiceAccount` set, the `ServiceAccount` will be set to `default`. ## Manually create a service account API token. Suppose we have an existing service account named "build-robot" as mentioned above, and we create a new secret manually. ```console $ cat > /tmp/build-robot-secret.yaml < Annotations: kubernetes.io/service-account.name=build-robot,kubernetes.io/service-account.uid=870ef2a5-35cf-11e5-8d06-005056b45392 Type: kubernetes.io/service-account-token Data ==== ca.crt: 1220 bytes token: ``` > Note that the content of `token` is elided here. ## Adding Secrets to a service account. TODO: Test and explain how to use additional non-K8s secrets with an existing service account. TODO explain: - The token goes to: "/var/run/secrets/kubernetes.io/serviceaccount/$WHATFILENAME" [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/user-guide/service-accounts.md?pixel)]()