<commit_before>#Service Accounts

## Motivation

Processes in Pods may need to call the Kubernetes API.  For example:
  - scheduler
  - replication controller
  - minion controller
  - a map-reduce type framework which has a controller that then tries to make a dynamically determined number of workers and watch them
  - continuous build and push system
  - monitoring system

They also may interact with services other than the Kubernetes API, such as:
  - an image repository, such as docker -- both when the images are pulled to start the containers, and for writing
    images in the case of pods that generate images.
  - accessing other cloud services, such as blob storage, in the context of a larged, integrated, cloud offering (hosted
    or private).
  - accessing files in an NFS volume attached to the pod

## Design Overview
A service account binds together several things:
  - a *name*, understood by users, and perhaps by peripheral systems, for an identity
  - 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
    capabilities and controls on interaction with the file system and OS.
  - a set of [secrets](./secrets.md), which a container may use to
    access various networked resources.<commit_msg>Fix wrong link for security context<commit_after>#Service Accounts

## Motivation

Processes in Pods may need to call the Kubernetes API.  For example:
  - scheduler
  - replication controller
  - minion controller
  - a map-reduce type framework which has a controller that then tries to make a dynamically determined number of workers and watch them
  - continuous build and push system
  - monitoring system

They also may interact with services other than the Kubernetes API, such as:
  - an image repository, such as docker -- both when the images are pulled to start the containers, and for writing
    images in the case of pods that generate images.
  - accessing other cloud services, such as blob storage, in the context of a larged, integrated, cloud offering (hosted
    or private).
  - accessing files in an NFS volume attached to the pod

## Design Overview
A service account binds together several things:
  - a *name*, understood by users, and perhaps by peripheral systems, for an identity
  - a *principal* that can be authenticated and [authorized](../authorization.md)
  - a [security context](./security_context.md), which defines the Linux Capabilities, User IDs, Groups IDs, and other
    capabilities and controls on interaction with the file system and OS.
  - a set of [secrets](./secrets.md), which a container may use to
    access various networked resources.
{'fraction_non_alphanumeric': 0.0544069640914037, 'fraction_numerical': 0.0, 'mean_word_length': 3.83859649122807, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4098958', 'n_tokens_mistral': 690, 'n_tokens_neox': 655, 'n_words': 382}