Kubernetes pod and namespace security model

docs/design/security.md

@@ -1,17 +1,106 @@
 # Security in Kubernetes
 
-General design principles and guidelines related to security of containers, APIs, and infrastructure in Kubernetes.
+Kubernetes should define a reasonable set of security best practices that allows processes to be isolated from each other, from the cluster infrastructure, and which preserves important boundaries between those who manage the cluster, and those who use the cluster.
 
+While Kubernetes today is not primarily a multi-tenant system, the long term evolution of Kubernetes will increasingly rely on proper boundaries between users and administrators. The code running on the cluster must be appropriately isolated and secured to prevent malicious parties from affecting the entire cluster.
 
-## Objectives
 
-1.  Ensure a clear isolation between container and the underlying host it runs on
+## High Level Goals
+
+1.  Ensure a clear isolation between the container and the underlying host it runs on
 2.  Limit the ability of the container to negatively impact the infrastructure or other containers
 3.  [Principle of Least Privilege](http://en.wikipedia.org/wiki/Principle_of_least_privilege) - ensure components are only authorized to perform the actions they need, and limit the scope of a compromise by limiting the capabilities of individual components
 4.  Reduce the number of systems that have to be hardened and secured by defining clear boundaries between components
+5.  Allow users of the system to be cleanly separated from administrators
+6.  Allow administrative functions to be delegated to users where necessary
+7.  Allow applications to be run on the cluster that have "secret" data (keys, certs, passwords) which is properly abstracted from "public" data.
+
+
+## Use cases
+
+### Roles:
+
+We define "user" as a unique identity accessing the Kubernetes API server, which may be a human or an automated process.  Human users fall into the following categories:
+
+1. k8s admin - administers a kubernetes cluster and has access to the undelying components of the system
+2. k8s project administrator - administrates the security of a small subset of the cluster
+3. k8s developer - launches pods on a kubernetes cluster and consumes cluster resources
+
+Automated process users fall into the following categories:
+
+1. k8s container user - a user that processes running inside a container (on the cluster) can use to access other cluster resources indepedent of the human users attached to a project
+2. k8s infrastructure user - the user that kubernetes infrastructure components use to perform cluster functions with clearly defined roles
+
+
+### Description of roles:
+
+* Developers:
+  * write pod specs.
+  * making some of their own images, and using some "community" docker images
+  * know which pods need to talk to which other pods
+  * decide which pods should be share files with other pods, and which should not.
+  * reason about application level security, such as containing the effects of a local-file-read exploit in a webserver pod.
+  * do not often reason about operating system or organizational security.
+  * are not necessarily comfortable reasoning about the security properties of a system at the level of detail of Linux Capabilities, SELinux, AppArmor, etc.
+
+* Project Admins:
+  * allocate identity and roles within a namespace
+  * reason about organizational security within a namespace
+    * don't give a developer permissions that are not needed for role.
+    * protect files on shared storage from unnecessary cross-team access
+  * are less focused about application security
+
+* Administrators:
+  * are less focused on application security. Focused on operating system security.
+  * protect the node from bad actors in containers, and properly-configured innocent containers from bad actors in other containers.
+  * comfortable reasoning about the security properties of a system at the level of detail of Linux Capabilities, SELinux, AppArmor, etc.
+  * decides who can use which Linux Capabilities, run privileged containers, use hostDir, etc.
+    * e.g. a team that manages Ceph or a mysql server might be trusted to have raw access to storage devices in some organizations, but teams that develop the applications at higher layers would not.
+
+
+## Proposed Design
+
+A pod runs in a *security context* under a *service account* that is defined by an administrator or project administrator, and the *secrets* a pod has access to is limited by that *service account*.
+
+
+1. The API should authenticate and authorize user actions [authn and authz](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/design/access.md)
+2. All infrastructure components (kubelets, kube-proxies, controllers, scheduler) should have an infrastructure user that they can authenticate with and be authorized to perform only the functions they require against the API.
+3. Most infrastructure components should use the API as a way of exchanging data and changing the system, and only the API should have access to the underlying data store (etcd)
+4. When containers run on the cluster and need to talk to other containers or the API server, they should be identified and authorized clearly as an autonomous process via a [service account](https://github.com/GoogleCloudPlatform/kubernetes/pull/2297)
+   1.  If the user who started a long-lived process is removed from access to the cluster, the process should be able to continue without interruption
+   2.  If the user who started processes are removed from the cluster, administrators may wish to terminate their processes in bulk
+   3.  When containers run with a service account, the user that created / triggered the service account behavior must be associated to the container's action
+5. When container processes runs on the cluster, they should run in a [security context](https://github.com/GoogleCloudPlatform/kubernetes/pull/3910) that isolates those processes via Linux user security, user namespaces, and permissions.
+   1.  Administrators should be able to configure the cluster to automatically confine all container processes as a non-root, randomly assigned UID
+   2.  Administrators should be able to ensure that container processes within the same namespace are all assigned the same unix user UID
+   3.  Administrators should be able to limit which developers and project administrators have access to higher privilege actions
+   4.  Project administrators should be able to run pods within a namespace under different security contexts, and developers must be able to specify which of the available security contexts they may use
+   5.  Developers should be able to run their own images or images from the community and expect those images to run correctly
+   6.  Developers may need to ensure their images work within higher security requirements specified by administrators
+   7.  When available, Linux kernel user namespaces can be used to ensure 5.2 and 5.4 are met.
+   8.  When application developers want to share filesytem data via distributed filesystems, the Unix user ids on those filesystems must be consistent across different container processes
+6. Developers should be able to define [secrets](https://github.com/GoogleCloudPlatform/kubernetes/pull/2297) that are automatically added to the containers when pods are run
+   1.  Secrets are files injected into the container whose values should not be displayed within a pod. Examples:
+       1. An SSH private key for git cloning remote data
+       2. A client certificate for accessing a remote system
+       3. A private key and certificate for a web server
+       4. A .kubeconfig file with embedded cert / token data for accessing the Kubernetes master
+       5. A .dockercfg file for pulling images from a protected registry
+   2.  Developers should be able to define the pod spec so that a secret lands in a specific location
+   3.  Project administrators should be able to limit developers within a namespace from viewing or modify secrets (anyone who can launch an arbitrary pod can view secrets)
+   4.  Secrets are generally not copied from one namespace to another when a developer's application definitions are copied
+
+
+### Related design discussion
+
+* Authorization and authentication https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/design/access.md
+* Secret distribution via files https://github.com/GoogleCloudPlatform/kubernetes/pull/2030
+* Docker secrets https://github.com/docker/docker/pull/6697
+* Docker vault https://github.com/docker/docker/issues/10310
 
+## Specific Design Points
 
-## Design Points
+### TODO: authorization, authentication
 
 ### Isolate the data store from the minions and supporting infrastructure