github.com/enmand/kubernetes@v1.2.0-alpha.0/docs/admin/service-accounts-admin.md (about) 1 <!-- BEGIN MUNGE: UNVERSIONED_WARNING --> 2 3 <!-- BEGIN STRIP_FOR_RELEASE --> 4 5 <img src="http://kubernetes.io/img/warning.png" alt="WARNING" 6 width="25" height="25"> 7 <img src="http://kubernetes.io/img/warning.png" alt="WARNING" 8 width="25" height="25"> 9 <img src="http://kubernetes.io/img/warning.png" alt="WARNING" 10 width="25" height="25"> 11 <img src="http://kubernetes.io/img/warning.png" alt="WARNING" 12 width="25" height="25"> 13 <img src="http://kubernetes.io/img/warning.png" alt="WARNING" 14 width="25" height="25"> 15 16 <h2>PLEASE NOTE: This document applies to the HEAD of the source tree</h2> 17 18 If you are using a released version of Kubernetes, you should 19 refer to the docs that go with that version. 20 21 <strong> 22 The latest 1.0.x release of this document can be found 23 [here](http://releases.k8s.io/release-1.0/docs/admin/service-accounts-admin.md). 24 25 Documentation for other releases can be found at 26 [releases.k8s.io](http://releases.k8s.io). 27 </strong> 28 -- 29 30 <!-- END STRIP_FOR_RELEASE --> 31 32 <!-- END MUNGE: UNVERSIONED_WARNING --> 33 34 # Cluster Admin Guide to Service Accounts 35 36 *This is a Cluster Administrator guide to service accounts. It assumes knowledge of 37 the [User Guide to Service Accounts](../user-guide/service-accounts.md).* 38 39 *Support for authorization and user accounts is planned but incomplete. Sometimes 40 incomplete features are referred to in order to better describe service accounts.* 41 42 ## User accounts vs service accounts 43 44 Kubernetes distinguished between the concept of a user account and a service accounts 45 for a number of reasons: 46 - User accounts are for humans. Service accounts are for processes, which 47 run in pods. 48 - User accounts are intended to be global. Names must be unique across all 49 namespaces of a cluster, future user resource will not be namespaced). 50 Service accounts are namespaced. 51 - Typically, a cluster's User accounts might be synced from a corporate 52 database, where new user account creation requires special privileges and 53 is tied to complex business processes. Service account creation is intended 54 to be more lightweight, allowing cluster users to create service accounts for 55 specific tasks (i.e. principle of least privilege). 56 - Auditing considerations for humans and service accounts may differ. 57 - A config bundle for a complex system may include definition of various service 58 accounts for components of that system. Because service accounts can be created 59 ad-hoc and have namespaced names, such config is portable. 60 61 ## Service account automation 62 63 Three separate components cooperate to implement the automation around service accounts: 64 - A Service account admission controller 65 - A Token controller 66 - A Service account controller 67 68 ### Service Account Admission Controller 69 70 The modification of pods is implemented via a plugin 71 called an [Admission Controller](admission-controllers.md). It is part of the apiserver. 72 It acts synchronously to modify pods as they are created or updated. When this plugin is active 73 (and it is by default on most distributions), then it does the following when a pod is created or modified: 74 1. If the pod does not have a `ServiceAccount` set, it sets the `ServiceAccount` to `default`. 75 2. It ensures that the `ServiceAccount` referenced by the pod exists, and otherwise rejects it. 76 4. If the pod does not contain any `ImagePullSecrets`, then `ImagePullSecrets` of the 77 `ServiceAccount` are added to the pod. 78 5. It adds a `volume` to the pod which contains a token for API access. 79 6. It adds a `volumeSource` to each container of the pod mounted at `/var/run/secrets/kubernetes.io/serviceaccount`. 80 81 ### Token Controller 82 83 TokenController runs as part of controller-manager. It acts asynchronously. It: 84 - observes serviceAccount creation and creates a corresponding Secret to allow API access. 85 - observes serviceAccount deletion and deletes all corresponding ServiceAccountToken Secrets 86 - observes secret addition, and ensures the referenced ServiceAccount exists, and adds a token to the secret if needed 87 - observes secret deletion and removes a reference from the corresponding ServiceAccount if needed 88 89 #### To create additional API tokens 90 91 A controller loop ensures a secret with an API token exists for each service 92 account. To create additional API tokens for a service account, create a secret 93 of type `ServiceAccountToken` with an annotation referencing the service 94 account, and the controller will update it with a generated token: 95 96 ```json 97 secret.json: 98 { 99 "kind": "Secret", 100 "apiVersion": "v1", 101 "metadata": { 102 "name": "mysecretname", 103 "annotations": { 104 "kubernetes.io/service-account.name": "myserviceaccount" 105 } 106 }, 107 "type": "kubernetes.io/service-account-token" 108 } 109 ``` 110 111 ```sh 112 kubectl create -f ./secret.json 113 kubectl describe secret mysecretname 114 ``` 115 116 #### To delete/invalidate a service account token 117 118 ```sh 119 kubectl delete secret mysecretname 120 ``` 121 122 ### Service Account Controller 123 124 Service Account Controller manages ServiceAccount inside namespaces, and ensures 125 a ServiceAccount named "default" exists in every active namespace. 126 127 128 <!-- BEGIN MUNGE: GENERATED_ANALYTICS --> 129 [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/admin/service-accounts-admin.md?pixel)]() 130 <!-- END MUNGE: GENERATED_ANALYTICS -->