github/kubernetes
4
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fixed markdown

Browse Source
This commit is contained in:
Maciej Szulik 2015-03-24 12:01:41 +01:00
parent d0b468f4b0
commit 6a2ee9ae9f
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/design/service_accounts.md
View File

@ -1,6 +1,6 @@
#Service Accounts #Service Accounts
## Motivation ## Motivation
Processes in Pods may need to call the Kubernetes API. For example: Processes in Pods may need to call the Kubernetes API. For example:
- scheduler - scheduler
@ -20,7 +20,7 @@ They also may interact with services other than the Kubernetes API, such as:
## Design Overview ## Design Overview
A service account binds together several things: A service account binds together several things:
- a *name*, understood by users, and perhaps by peripheral systems, for an identity - a *name*, understood by users, and perhaps by peripheral systems, for an identity
- a *principal* that can be authenticated and (authorized)[../authorization.md] - a *principal* that can be authenticated and [authorized](../authorization.md)
- a [security context](./security_contexts.md), which defines the Linux Capabilities, User IDs, Groups IDs, and other - a [security context](./security_contexts.md), which defines the Linux Capabilities, User IDs, Groups IDs, and other
capabilities and controls on interaction with the file system and OS. capabilities and controls on interaction with the file system and OS.
- a set of [secrets](./secrets.md), which a container may use to - a set of [secrets](./secrets.md), which a container may use to
@ -60,7 +60,7 @@ This includes a human running `kubectl` on her desktop and a container in a Pod
There is already a notion of a username in kubernetes, which is populated into a request context after authentication. There is already a notion of a username in kubernetes, which is populated into a request context after authentication.
However, there is no API object representing a user. While this may evolve, it is expected that in mature installations, However, there is no API object representing a user. While this may evolve, it is expected that in mature installations,
the canonical storage of user identifiers will be handled by a system external to kubernetes. the canonical storage of user identifiers will be handled by a system external to kubernetes.
Kubernetes does not dictate how to divide up the space of user identifier strings. User names can be Kubernetes does not dictate how to divide up the space of user identifier strings. User names can be
simple Unix-style short usernames, (e.g. `alice`), or may be qualified to allow for federated identity ( simple Unix-style short usernames, (e.g. `alice`), or may be qualified to allow for federated identity (
@ -84,7 +84,7 @@ The distinction is useful for a number of reasons:
- A Human typically keeps credentials on a machine that is not part of the cluster and so not subject to automatic - A Human typically keeps credentials on a machine that is not part of the cluster and so not subject to automatic
management. A VM with a role/service-account can have its credentials automatically managed. management. A VM with a role/service-account can have its credentials automatically managed.
- the identity of a Pod cannot in general be mapped to a single human. - the identity of a Pod cannot in general be mapped to a single human.
- If policy allows, it may be created by one human, and then updated by another, and another, until its behavior cannot be attributed to a single human. - If policy allows, it may be created by one human, and then updated by another, and another, until its behavior cannot be attributed to a single human.
**TODO**: consider getting rid of separate serviceAccount object and just rolling its parts into the SecurityContext or **TODO**: consider getting rid of separate serviceAccount object and just rolling its parts into the SecurityContext or
Pod Object. Pod Object.
@ -106,7 +106,7 @@ might have some types that do not do anything on apiserver but just get pushed t
### Pods ### Pods
The `PodSpec` is extended to have a `Pods.Spec.ServiceAccountUsername` field. If this is unset, then a The `PodSpec` is extended to have a `Pods.Spec.ServiceAccountUsername` field. If this is unset, then a
default value is chosen. If it is set, then the corresponding value of `Pods.Spec.SecurityContext` is set by the default value is chosen. If it is set, then the corresponding value of `Pods.Spec.SecurityContext` is set by the
Service Account Finalizer (see below). Service Account Finalizer (see below).
TBD: how policy limits which users can make pods with which service accounts. TBD: how policy limits which users can make pods with which service accounts.
@ -122,7 +122,7 @@ Service Account Finalizer is one place where this can happen (see below).
### Kubelet ### Kubelet
The kubelet will treat as "not ready to run" (needing a finalizer to act on it) any Pod which has an empty The kubelet will treat as "not ready to run" (needing a finalizer to act on it) any Pod which has an empty
SecurityContext. SecurityContext.
The kubelet will set a default, restrictive, security context for any pods created from non-Apiserver config The kubelet will set a default, restrictive, security context for any pods created from non-Apiserver config
sources (http, file). sources (http, file).
@ -141,7 +141,7 @@ like this:
**TODO**: example of pod with explicit refs. **TODO**: example of pod with explicit refs.
Another way is with the *Service Account Finalizer*, a plugin process which is optional, and which handles Another way is with the *Service Account Finalizer*, a plugin process which is optional, and which handles
business logic around service accounts. business logic around service accounts.
The Service Account Finalizer watches Pods, Namespaces, and ServiceAccount definitions. The Service Account Finalizer watches Pods, Namespaces, and ServiceAccount definitions.