whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Release 1.9 (#5978)

Browse Source 
* Trivial change to open release branch

* Undo trivial change

* add service ipvs overview

* Add instructions on how to setup kubectl

* Document conntrack dependency for kube-proxy

* Add an a

This is kind of jarring / missing an article. I'm guessing it should either be ' to a rack of bare metal servers.' or '...to racks of bare metal servers.'.

* adding example responses for common issues

 - support request
 - code bug report

* Trivial change to open release branch

* Undo trivial change

* Signed-off-by: Ziqi Zhao <zhaoziqi@qiniu.com> (#5366)

Fix the not-working test case yaml for /doc/concepts/storage/volumes.md

* kubectl-overview

* temp fix for broken pod and deployment links

* Update Table of Solutions for Juju

* Revise certificates documentation (#5965)

* Update review-issues.md

Some edits for clarity and condensed language.

* Update init-containers.md

Fix leading spaces in commands.

* Update kubectl-overview.md

Fix format.

* Update clc.md

Fix format.

* Update openstack-heat.md

The url no need. just  highlight.

* Typo

I believe this should be "users" not "uses"

* making explicit hostname uniq requirement

* Update scheduling-hugepages.md

* Update update-daemon-set.md

* fix redirection of PersistentVolume

* Update hpa.md

* update kubectl instruction

* Use the format of kubeadm init

* fix spelling error

guarnatees  to guarantees

* add matchLabels description (#6020)

* search and replace for k8s.github.io to website (#6019)

* fix scale command of object-management (#6011)

* Update replicaset.md (#6009)

* Update secret.md (#6008)

* specify password for mysql image (#5990)

* specify password for mysql image

* specify password for mysql image

* link error for run-stateless-application-deployment.md (#5985)

* link error for run-stateless-application-deployment.md

* link error for run-stateless-application-deployment.md

* Add performance implications of inter-pod affinity/anti-affinity (#5979)

* 404 monthly maintenance - October 2017 (#5977)

* Updated redirects

* More redirects

* Add conjure-up to Turnkey Cloud Solutions list (#5973)

* Add conjure-up to Turnkey Cloud Solutions list

* Changed wording slightly

* change the StatefulSet to ReplicaSet in reference (#5968)

* Clarification of failureThreshold of probes (#5963)

* Mention usage of block storage version param (#5925)

Mention usage of block storage version (bs-version) parameter to
workaround attachment issues using older K8S versions on an OpenStack
cloud with path-based endpoints.

Resolves: https://github.com/kubernetes/kubernetes.github.io/issues/5924

* Update sysctl-cluster.md (#5894)

Include guide on enabling unsafe sysctls in minikube

* Avoid Latin phrases & format note (#5889)

* Avoid Latin phrases & format note

according the Documentation Style Guide

* Update scratch.md

* Update scratch.md

* resolves jekyll rendering error (#5976)

- chinese isn't understood for keys in YAML frontmatter in jekyll, so
   replaced it with the english equivalent that doesn't throw the
following error on rendering:

Error reading file src/kubernetes.github.io/cn/docs/concepts/cluster-administration/device-plugins.md: (<unknown>): could not find expected ':' while scanning a simple key at line 4 column 1

* Change VM to pod. (#6022)

* Add link to custom metrics. (#6023)

* Rephrase core group. (#6024)

* Added explanation on context to when joining (#6018)

* Update create-cluster-kubeadm.md (#5761)

Update Canal version in pod network apply commands

* Fixes issue #5620 (#5869)

* Fixes issue #5620

Signed-off-by: Brad Topol <btopol@us.ibm.com>

* Restructured so that review process is for both current and upcoming
releases.  Added content describing the use of tech reviewers.

* Removed incorrect Kubernetes reviewer link.

* Fixed tech reviewer URL to now use website

* Update pod-priority-preemption.md

fix-wrong-link-to-pod-preemption

* pod-security-policy.md: add links to the page about admission plugins.

* Adding all files for BlaBlaCar case study (#5857)

* Adding all files for BlaBlaCar case study

* Update blablacar.html

* Fix changed URL for google containers

* Add /docs/reference/auto-generated directory

* correct the downwardapi redirect

* Remove links using "here"

* Rename to /docs/reference/generated directory

* add Concept template

* Change title to just Ingress

* Link mistake (#6038)

* link mistake

* link mistake

* skip title check for skip_title_check.txt

* skip title check for skip_title_check.txt

* remove doesn't exist link.

* Fix podpreset task (#5705)

* Add a simple pod manifest to pod overview (#5986)

* Split PodPreset concept out from task doc (#5984)

* Add selector spec description (#5789)

* Add selector spec description

* Fix selector field explanation

* Put orphaned topics in TOC. (#6051)

* static-pod example bad format in the final page (#6050)

* static-pod example bad format in the final page

* static-pod example bad format in the final page

* static-pod example bad format in the final page

* static-pod example bad format in the final page

* static-pod example bad format in the final page

* Fix `backoffLimit` field misplacement (#6042)

It should be placed in JobSpec according to:
https://github.com/kubernetes/kubernetes/blob/master/api/swagger-spec/batch_v1.json#L1488-L1514

* Update addons.md (#6061)

* add info about VMware NSX-T CNI plugin (#5987)

* add info about VMware NSX-T CNI plugin

Hello,

I'm VMware Networking and Security Architect and would like to include short information about our CNI plugin implementation similar to what other vendors did

Best regards

Emil Gagala

* Update networking.md

* Update networking.md

* Update networking.md

* Update: Using universal zsh configuration (#5669)

* Update install-kubectl.md

Zsh is not only oh-my-zsh, so I added universal configuration for zsh that also can be used in prezto.

* fix merge error after rebase

* Operating etcd cluster for Kubernetes bad format in the final page (#6056)

* Operating etcd cluster for Kubernetes bad format in the final page

* Update configure-upgrade-etcd.md

* Update configure-upgrade-etcd.md

* Usage note and warning tags. (#6053)

* Usage note and warning tags.

* Update configure-upgrade-etcd.md

* Update configure-upgrade-etcd.md

* Document jekyll includes snippets

* Add jekyll includes to docs home toc

- Remove extra kubernetes home in toc

* document docker cgroupdriver req (#5937)

* Update test blacklists (#6063)

* Update toc check blacklist

* Update title check blacklist

* wip

* wip

* Fix typo

* Document unconfined apparmor profile

* Revert "Document the unconfined profile for AppArmor" (#6268)

* CRD Validation: remove alpha warning, change enable instructions to (#6066)

disable

* Documented service annotation for AWS ELB SSL policy

* kubeadm: add a note about the new `--print-join-command` flag.

This is a new flag for the `kubeadm token create` command.

* Add a note to PDB page

* Improve Kubeadm reference doc (#6103)

* automatically-generated kubeadm reference doc

* user-mantained kubeadm reference doc

* Documentation for CSIPersistentVolume

* change replicaset documentation to use apps/v1 APIs

* Update service.md

ipvs alpha version -> beta version

* Updated Deployment concept docs (#6494)

* Updated Deployment concept docs

* Addressed comments

* Documentation for volume scheduling alpha feature

* Update admission control docs for webhooks

* Improve DNS documentation (#6479)

* update ds for 1.9

* Update service.md

* Update service.md

* Revert "begin updating webhook documentation" (#6575)

* Update version numbers to include 1.9 (#6518)

* Update site versions for 1.9

* Removed 1.4 docs

* Update _config.yml

* Update _config.yml

* updates for raw block devices

* rbac: docs for aggregated cluster roles (#6474)

* Added IPv6 information for Kubelet arguments (#6498)

* Added IPv6 info to kube-proxy arguments

* Added IPv6 information for argument for kubelet

* Update PVC resizing documentation (#6487)

* Updates for Windows Server version 1709 with K8s v1.8 (#6180)

* Updated for WSv1709 and K8s v1.8

* Updated picture and CNI config

* Fixed formatting on CNI Config

* Updated docs to reference Microsoft/SDN GitHub docs

* fix typo

* Workaround for Jekyllr frontmatter

* Added section on features and limitations, with example yaml files.

* Update index.md

* Added kubeadm section, few other small fixes

* Few minor grammar fixes

* Update access-cluster.md with a comment that for IPv6
the user should use [::1] for the localhost

* Addressed a number of issues brought up against the base PR

* Fixed windows-host-setup link

* Rewrite PodSecurityPolicy guide

* Update index.md

Signed-off-by: Alin Balutoiu <abalutoiu@cloudbasesolutions.com>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>

* Spelling correction and sentence capitalization.

- Corrected the spelling error for storing, was put in as 'stoing'.
- Capitalized list items.
- Added '.' at end of sentences in the list items.

* Update index.md

* Update index.md

* Addressed comments and rebased

* Fixed formatting

* Fixed formatting

* Updated header link

* Updated hyperlinks

* Updated warning

* formatting

* formatting

* formatting

* Revert "Update access-cluster.md with a comment that for IPv6"

This reverts commit 31e4dbdc25.

* Revert "fix typo"

This reverts commit c05678752d.

* Revert "Workaround for Jekyllr frontmatter"

This reverts commit b84ac59624.

* Fixed grammatical issues and reverted non-related commits

* Revert "Rewrite PodSecurityPolicy guide"

This reverts commit 5d39cfeae4.

* Revert "Spelling correction and sentence capitalization."

This reverts commit 47eed4346e.

* Fixed auto-numbering

* Minor formatting updates

* CoreDNS feature documentation (#6463)

* Initial placeholder PR for CoreDNS feature documentation

* Remove from admin, add content

* Fix missing endcapture

* Add to tasks.yml

* Review feedback

* Postpone Deletion of a Persistent Volume Claim in case It Is Used by a Pod (#6415)

* Postpone Deletion of a Persistent Volume Claim in case It Is Used by a Pod

A new feature PVC Protection was added into K8s 1.9 that's why this documentation change is needed.

* Added tag at the top of each new area.

* Fix typo

* Fix: switched on in (all kubelets) -> (all K8s components).

* Added link to admission controller

* Moved PVC Protection configuration into Before you begin section.

* Added steps how to verify PVC Protection feature.

* Fixes for admission controller plugin description and for PVC Protection description in PVC lifecycle.

* Testing official rendering of enumerations (1., 2., 3., etc.)

* Re-write to address comments from review.

* Fixed definition when a PVC is in active use by a pod.

* Change auditing docs page for 1.9 release (#6427)

* Change auditing docs page for 1.9 release

Signed-off-by: Mik Vyatskov <vmik@google.com>

* Address review comments

Signed-off-by: Mik Vyatskov <vmik@google.com>

* Address review comments

Signed-off-by: Mik Vyatskov <vmik@google.com>

* Address review comments

Signed-off-by: Mik Vyatskov <vmik@google.com>

* Fix broken link

Signed-off-by: Mik Vyatskov <vmik@google.com>

* short circuit deny docs (#6536)

* line wrap

* short circuit deny

* address comments

* Add kubeadm 1.9 upgrade docs (#6485)

* kubeadm: Improve kubeadm documentation for v1.9 (#6645)

* Update admission control docs for webhooks (re-send #6368) (#6650)

* Update admission control docs for webhooks

* update in response to comments

* Revamp rkt and add CRI-O as alternative runtime (#6371)

Signed-off-by: Lorenzo Fontana <lo@linux.com>

* Documented NLB for Kubernetes 1.9 (#6260)

* Added IPV6 information to setup cluster using kubeadm (#6465)

* Added IPV6 information to setup cluster using kubeadm

* Updated kubeadm.md & create-cluster-kubeadm.md with IPv6 related information

* Added IPv6 options for kubeadm --init  & automated address binding for kube-proxy based on version of IP configured for API server)

* Changes to kubeadm.md as per comments

* Modified kubeadm.md and create-cluster-kubeadm.md

* Implemented changes requested by zacharysarah

* Removed autogenerated kubeadm.md changes

* StatefulSet 1.9 updates. (#6550)

* updates sts concept and tutorials to use 1.9 apps/v1

* Update statefulset.md

* clarify pod name label

* Garbage collection updates for 1.9 (#6555)

* 1.9 gc policy update

* carify deletion

* Couple nits for dnsConfig doc (#6652)

* Add doc for AllowedFlexVolume (#6563)

* Update OpenStack Cloud Provider API support for v1.9 (#6638)

* Flex volume is GA. Remove alpha notation. (#6666)

* Update generated ref docs for Kubernetes and Federation components. (#6658)

* Update generated ref docs for Kubernetes and Federation components.

* Rename kubectl-options to kubectl.

* Add title to kubectl.

* Fix double synopsis.

* Update Federation API ref docs for 1.9. (#6636)

* Update federation API ref docs.

* Move and redirect.

* Move generated Federation docs to the generated directory.

* Fix titles.

* Type

* Fix titles

* Update auto-generated Kubernetes APi ref docs. (#6646)

* Update kubectl commands for 1.9 (#6635)

* add ExtendedResourceToleration admission controller (#6618)

* Update API reference paths for v1.9 (#6681)
This commit is contained in:
Zach Corleissen
2017-12-15 17:36:13 -06:00
committed by GitHub
parent 0e628e7895
commit 08af95d42e
893 changed files with 131178 additions and 105058 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/policy/pod-security-policy.md
+221 -380
View File
@@ -1,120 +1,175 @@
---
approvers:
- pweil-
- tallclair
title: Pod Security Policies
---
{% include feature-state-beta.md %}
Objects of type `PodSecurityPolicy` govern the ability
to make requests on a pod that affect the `SecurityContext` that will be
applied to a pod and container.
Pod Security Policies enable fine-grained authorization of pod creation and
updates.
See [PodSecurityPolicy proposal](https://git.k8s.io/community/contributors/design-proposals/auth/pod-security-policy.md) for more information.
* TOC
{:toc}
## What is a Pod Security Policy?
A _Pod Security Policy_ is a cluster-level resource that controls security
sensitive aspects of the pod specification. The `PodSecurityPolicy` objects
define a set of conditions that a pod must run with in order to be accepted into
the system, as well as defaults for the related fields. They allow an
A _Pod Security Policy_ is a cluster-level resource that controls the
actions that a pod can perform and what it has the ability to access. The
`PodSecurityPolicy` objects define a set of conditions that a pod must
run with in order to be accepted into the system. They allow an
administrator to control the following:
| Control Aspect | Field Names |
| ----------------------------------------------------| ------------------------------------------- |
| Running of privileged containers | `privileged` |
| Usage of the root namespaces | [`hostPID`, `hostIPC`](#host-namespaces) |
| Usage of host networking and ports | [`hostNetwork`, `hostPorts`](#host-namespaces) |
| Usage of volume types | [`volumes`](#volumes-and-file-systems) |
| Usage of the host filesystem | [`allowedHostPaths`](#volumes-and-file-systems) |
| Allocating an FSGroup that owns the pod's volumes | [`fsGroup`](#volumes-and-file-systems) |
| Requiring the use of a read only root file system | [`readOnlyRootFilesystem`](#volumes-and-file-systems) |
| The user and group IDs of the container | [`runAsUser`, `supplementalGroups`](#users-and-groups) |
| Restricting escalation to root privileges | [`allowPrivilegeEscalation`, `defaultAllowPrivilegeEscalation`](#privilege-escalation) |
| Linux capabilities | [`defaultAddCapabilities`, `requiredDropCapabilities`, `allowedCapabilities`](#capabilities) |
| The SELinux context of the container | [`seLinux`](#selinux) |
| The AppArmor profile used by containers | [annotations](#apparmor) |
| The seccomp profile used by containers | [annotations](#seccomp) |
| Control Aspect | Field Name |
| ---------------------------------------------------------------------- | ------------------------------------------- |
| Running of privileged containers | `privileged` |
| Default set of capabilities that will be added to a container | `defaultAddCapabilities` |
| Capabilities that will be dropped from a container | `requiredDropCapabilities` |
| Capabilities a container can request to be added | `allowedCapabilities` |
| Controlling the usage of volume types | [`volumes`](#controlling-volumes) |
| The use of host networking | [`hostNetwork`](#host-network) |
| The use of host ports | `hostPorts` |
| The use of host's PID namespace | `hostPID` |
| The use of host's IPC namespace | `hostIPC` |
| The SELinux context of the container | [`seLinux`](#selinux) |
| The user ID | [`runAsUser`](#runasuser) |
| Configuring allowable supplemental groups | [`supplementalGroups`](#supplementalgroups) |
| Allocating an FSGroup that owns the pod's volumes | [`fsGroup`](#fsgroup) |
| Requiring the use of a read only root file system | `readOnlyRootFilesystem` |
| Running of a container that allow privilege escalation from its parent | [`allowPrivilegeEscalation`](#allowprivilegeescalation) |
| Control whether a process can gain more privileges than its parent process | [`defaultAllowPrivilegeEscalation`](#defaultallowprivilegeescalation) |
| Whitelist of allowed host paths | [`allowedHostPaths`](#allowedhostpaths) |
| Whitelist of the flex volume drivers | [`allowedFlexVolumes`](#allowedflexvolumes) |
_Pod Security Policies_ are comprised of settings and strategies that
control the security features a pod has access to. These settings fall
into three categories:
- *Controlled by a Boolean*: Fields of this type default to the most
restrictive value.
- *Controlled by an allowable set*: Fields of this type are checked
against the set to ensure their values are allowed.
- *Controlled by a strategy*: Items that have a strategy to provide
a mechanism to generate the value and a mechanism to ensure that a
specified value falls into the set of allowable values.
## Enabling Pod Security Policies
## Strategies
Pod security policy control is implemented as an optional (but recommended)
[admission
controller](/docs/admin/admission-controllers/#podsecuritypolicy). PodSecurityPolicies
are enforced by [enabling the admission
controller](/docs/admin/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in),
but doing so without authorizing any policies **will prevent any pods from being
created** in the cluster.
### RunAsUser
Since the pod security policy API (`extensions/v1beta1/podsecuritypolicy`) is
enabled independently of the admission controller, for existing clusters it is
recommended that policies are added and authorized before enabling the admission
controller.
- *MustRunAs* - Requires a `range` to be configured. Uses the first value
of the range as the default. Validates against the configured range.
- *MustRunAsNonRoot* - Requires that the pod be submitted with a non-zero
`runAsUser` or have the `USER` directive defined in the image. No default
provided.
- *RunAsAny* - No default provided. Allows any `runAsUser` to be specified.
## Authorizing Policies
### SELinux
When a PodSecurityPolicy resource is created, it does nothing. In order to use
it, the requesting user or target pod's [service
account](/docs/tasks/configure-pod-container/configure-service-account/) must be
authorized to use the policy, by allowing the `use` verb on the policy.
- *MustRunAs* - Requires `seLinuxOptions` to be configured if not using
pre-allocated values. Uses `seLinuxOptions` as the default. Validates against
`seLinuxOptions`.
- *RunAsAny* - No default provided. Allows any `seLinuxOptions` to be
specified.
Most Kubernetes pods are not created directly by users. Instead, they are
typically created indirectly as part of a
[Deployment](/docs/concepts/workloads/controllers/deployment/),
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), or other
templated controller via the controller manager. Granting the controller access
to the policy would grant access for *all* pods created by that the controller,
so the preferred method for authorizing policies is to grant access to the
pod's service account (see [example](#run-another-pod)).
### SupplementalGroups
### Via RBAC
- *MustRunAs* - Requires at least one range to be specified. Uses the
minimum value of the first range as the default. Validates against all ranges.
- *RunAsAny* - No default provided. Allows any `supplementalGroups` to be
specified.
[RBAC](/docs/admin/authorization/rbac/) is a standard Kubernetes authorization
mode, and can easily be used to authorize use of policies.
### FSGroup
First, a `Role` or `ClusterRole` needs to grant access to `use` the desired
policies. The rules to grant access look like this:
- *MustRunAs* - Requires at least one range to be specified. Uses the
minimum value of the first range as the default. Validates against the
first ID in the first range.
- *RunAsAny* - No default provided. Allows any `fsGroup` ID to be specified.
### Controlling Volumes
The usage of specific volume types can be controlled by setting the
volumes field of the PSP. The allowable values of this field correspond
to the volume sources that are defined when creating a volume:
1. azureFile
1. azureDisk
1. flocker
1. flexVolume
1. hostPath
1. emptyDir
1. gcePersistentDisk
1. awsElasticBlockStore
1. gitRepo
1. secret
1. nfs
1. iscsi
1. glusterfs
1. persistentVolumeClaim
1. rbd
1. cinder
1. cephFS
1. downwardAPI
1. fc
1. configMap
1. vsphereVolume
1. quobyte
1. photonPersistentDisk
1. projected
1. portworxVolume
1. scaleIO
1. storageos
1. \* (allow all volumes)
The recommended minimum set of allowed volumes for new PSPs are
configMap, downwardAPI, emptyDir, persistentVolumeClaim, secret, and projected.
### Host Network
- *HostPorts*, default `empty`. List of `HostPortRange`, defined by `min`(inclusive) and `max`(inclusive), which define the allowed host ports.
### AllowPrivilegeEscalation
Gates whether or not a user is allowed to set the security context of a container
to `allowPrivilegeEscalation=true`. This field defaults to `false`.
### DefaultAllowPrivilegeEscalation
Sets the default for the security context `AllowPrivilegeEscalation` of a container.
This bool directly controls whether the `no_new_privs` flag gets set on the
container process. It defaults to `nil`. The default behavior of `nil`
allows privilege escalation so as to not break setuid binaries. Setting it to `false`
ensures that no child process of a container can gain more privileges than
its parent.
### AllowedHostPaths
This specifies a whitelist of host paths that are allowed to be used by Pods.
An empty list means there is no restriction on host paths used.
Each item in the list must specify a string value named `pathPrefix` that
defines a host path to match. The value cannot be "`*`" though.
An example is shown below:
```yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: <role name>
rules:
- apiGroups: ['extensions']
resources: ['podsecuritypolicies']
verbs: ['use']
resourceNames:
- <list of policies to authorize>
name: custom-paths
spec:
allowedHostPaths:
# This allows "/foo", "/foo/", "/foo/bar" etc., but
# disallows "/fool", "/etc/foo" etc.
- pathPrefix: "/foo"
```
Then the `(Cluster)Role` is bound to the authorized user(s):
### AllowedFlexVolumes
```yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: <binding name>
roleRef:
kind: ClusterRole
name: <role name>
apiGroup: rbac.authorization.k8s.io
subjects:
# Authorize specific service accounts:
- kind: ServiceAccount
name: <authorized service account name>
namespace: <authorized pod namespace>
# Authorize specific users (not recommended):
- kind: User
apiGroup: rbac.authorization.k8s.io
name: <authorized user name>
```
This specifies a whitelist of flex volume drivers that are allowed
to be used by flexVolume. An empty list means there is no restriction on the drivers. Please
make sure `volumes` contains the `flexVolume` volume type, no flex volume driver is allowed
otherwise. For example:
If a `RoleBinding` (not a `ClusterRoleBinding`) is used, it will only grant
usage for pods being run in the same namespace as the binding. This can be
paired with system groups to grant access to all pods run in the namespace:
```yaml
# Authorize all service accounts in a namespace:
- kind: Group
@@ -197,327 +252,113 @@ $ kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
name: pause
name: allow-flex-volumes
spec:
containers:
- name: pause
image: gcr.io/google-containers/pause
EOF
Error from server (Forbidden): error when creating "STDIN": pods "pause" is forbidden: unable to validate against any pod security policy: []
volumes:
- flexVolume
allowedFlexVolumes:
- driver: example/lvm
- driver: example/cifs
```
**What happened?** Although the PodSecurityPolicy was created, neither the
pod's service account nor `fake-user` have permission to use the new policy:
## Admission
[_Admission control_ with `PodSecurityPolicy`](/docs/admin/admission-controllers/#podsecuritypolicy)
allows for control over the creation and modification of resources based on the
capabilities allowed in the cluster.
Admission uses the following approach to create the final security context for
the pod:
1. Retrieve all PSPs available for use.
1. Generate field values for security context settings that were not specified
on the request.
1. Validate the final settings against the available policies.
If a matching policy is found, then the pod is accepted. If the
request cannot be matched to a PSP, the pod is rejected.
A pod must validate every field against the PSP.
## Creating a Pod Security Policy
Here is an example Pod Security Policy. It has permissive settings for
all fields
{% include code.html language="yaml" file="psp.yaml" ghlink="/docs/concepts/policy/psp.yaml" %}
Create the policy by downloading the example file and then running this command:
```shell
$ kubectl-user auth can-i use podsecuritypolicy/example
no
$ kubectl create -f ./psp.yaml
podsecuritypolicy "permissive" created
```
Create the rolebinding to grant `fake-user` the `use` verb on the example
policy:
## Getting a list of Pod Security Policies
_Note: This is not the recommended way! See the [next section](#run-another-pod)
for the preferred approach._
To get a list of existing policies, use `kubectl get`:
```shell
$ kubectl-admin create role psp:unprivileged \
--verb=use \
--resource=podsecuritypolicy \
--resource-name=example
role "psp:unprivileged" created
$ kubectl-admin create rolebinding fake-user:psp:unprivileged \
--role=psp:unprivileged \
--serviceaccount=psp-example:fake-user
rolebinding "fake-user:psp:unprivileged" created
$ kubectl-user auth can-i use podsecuritypolicy/example
yes
$ kubectl get psp
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP READONLYROOTFS VOLUMES
permissive false [] RunAsAny RunAsAny RunAsAny RunAsAny false [*]
privileged true [] RunAsAny RunAsAny RunAsAny RunAsAny false [*]
restricted false [] RunAsAny MustRunAsNonRoot RunAsAny RunAsAny false [emptyDir secret downwardAPI configMap persistentVolumeClaim projected]
```
Now retry creating the pod:
## Editing a Pod Security Policy
To modify policy interactively, use `kubectl edit`:
```shell
$ kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
name: pause
spec:
containers:
- name: pause
image: gcr.io/google-containers/pause
EOF
pod "pause" created
$ kubectl edit psp permissive
```
It works as expected! But any attempts to create a privileged pod should still
be denied:
This command will open a default text editor where you will be able to modify policy.
## Deleting a Pod Security Policy
Once you don't need a policy anymore, simply delete it with `kubectl`:
```shell
$ kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
name: privileged
spec:
containers:
- name: pause
image: gcr.io/google-containers/pause
securityContext:
privileged: true
EOF
Error from server (Forbidden): error when creating "STDIN": pods "privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]
$ kubectl delete psp permissive
podsecuritypolicy "permissive" deleted
```
Delete the pod before moving on:
## Enabling Pod Security Policies
```shell
$ kubectl-user delete pause
```
In order to use Pod Security Policies in your cluster you must ensure the
following
### Run another pod
1. You have enabled the API type `extensions/v1beta1/podsecuritypolicy` (only for versions prior 1.6)
1. [You have enabled the admission control plug-in `PodSecurityPolicy`](/docs/admin/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)
1. You have defined your policies
Let's try that again, slightly differently:
## Working With RBAC
```shell
$ kubectl-user run pause --image=gcr.io/google-containers/pause
deployment "pause" created
$ kubectl-user get pods
No resources found.
$ kubectl-user get events | head -n 2
LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE
1m 2m 15 pause-7774d79b5 ReplicaSet Warning FailedCreate replicaset-controller Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request
```
In Kubernetes 1.5 and newer, you can use PodSecurityPolicy to control access to
privileged containers based on user role and groups. Access to different
PodSecurityPolicy objects can be controlled via authorization.
**What happened?** We already bound the `psp:unprivileged` role for our `fake-user`,
why are we getting the error `Error creating: pods "pause-7774d79b5-" is
forbidden: no providers available to validate pod request`? The answer lies in
the source - `replicaset-controller`. Fake-user successfully created the
deployment (which successfully created a replicaset), but when the replicaset
went to create the pod it was not authorized to use the example
podsecuritypolicy.
Note that [Controller Manager](/docs/admin/kube-controller-manager/) must be run
against [the secured API port](/docs/admin/accessing-the-api/), and must not
have superuser permissions. Otherwise requests would bypass authentication and
authorization modules, all PodSecurityPolicy objects would be allowed,
and user will be able to create privileged containers.
In order to fix this, bind the `psp:unprivileged` role to the pod's service
account instead. In this case (since we didn't specify it) the service account
is `default`:
PodSecurityPolicy authorization uses the union of all policies available to the
user creating the pod and
[the service account specified on the pod](/docs/tasks/configure-pod-container/configure-service-account/).
```shell
$ kubectl-admin create rolebinding default:psp:unprivileged \
--role=psp:unprivileged \
--serviceaccount=psp-example:default
rolebinding "default:psp:unprivileged" created
```
Access to given PSP policies for a user will be effective only when creating
Pods directly.
Now if you give it a minute to retry, the replicaset-controller should
eventually succeed in creating the pod:
For pods created on behalf of a user, in most cases by Controller Manager,
access should be given to the service account specified on the pod spec
template. Examples of resources that create pods on behalf of a user are
Deployments, ReplicaSets, etc.
```shell
$ kubectl-user get pods --watch
NAME READY STATUS RESTARTS AGE
pause-7774d79b5-qrgcb 0/1 Pending 0 1s
pause-7774d79b5-qrgcb 0/1 Pending 0 1s
pause-7774d79b5-qrgcb 0/1 ContainerCreating 0 1s
pause-7774d79b5-qrgcb 1/1 Running 0 2s
^C
```
### Clean up
Delete the namespace to clean up most of the example resources:
```shell
$ kubectl-admin delete ns psp-example
namespace "psp-example" deleted
```
Note that `PodSecurityPolicy` resources are not namespaced, and must be cleaned
up separately:
```shell
$ kubectl-admin delete psp example
podsecuritypolicy "example" deleted
```
### Example Policies
This is the least restricted policy you can create, equivalent to not using the
pod security policy admission controller:
{% include code.html language="yaml" file="privileged-psp.yaml" ghlink="/docs/concepts/policy/privileged-psp.yaml" %}
This is an example of a restrictive policy that requires users to run as an
unprivileged user, blocks possible escalations to root, and requires use of
several security mechanisms.
{% include code.html language="yaml" file="restricted-psp.yaml" ghlink="/docs/concepts/policy/restricted-psp.yaml" %}
## Policy Reference
### Host namespaces
**HostPID** - Controls whether the pod containers can share the host process ID
namespace. Note that when paired with ptrace this can be used to escalate
privileges outside of the container (ptrace is forbidden by default).
**HostIPC** - Controls whether the pod containers can share the host IPC
namespace.
**HostNetwork** - Controls whether the pod may use the node network
namespace. Doing so gives the pod access to the loopback device, services
listening on localhost, and could be used to snoop on network activity of other
pods on the same node.
**HostPorts** - Provides a whitelist of ranges of allowable ports in the host
network namespace. Defined as a list of `HostPortRange`, with `min`(inclusive)
and `max`(inclusive). Defaults to no allowed host ports.
**AllowedHostPaths** - See [Volumes and file systems](#volumes-and-file-systems).
### Volumes and file systems
**Volumes** - Provides a whitelist of allowed volume types. The allowable values
correspond to the volume sources that are defined when creating a volume. For
the complete list of volume types, see [Types of
Volumes](/docs/concepts/storage/volumes/#types-of-volumes). Additionally, `*`
may be used to allow all volume types.
The **recommended minimum set** of allowed volumes for new PSPs are:
- configMap
- downwardAPI
- emptyDir
- persistentVolumeClaim
- secret
- projected
**FSGroup** - Controls the supplemental group applied to some volumes.
- *MustRunAs* - Requires at least one `range` to be specified. Uses the
minimum value of the first range as the default. Validates against all ranges.
- *RunAsAny* - No default provided. Allows any `fsGroup` ID to be specified.
**AllowedHostPaths** - This specifies a whitelist of host paths that are allowed
to be used by hostPath volumes. An empty list means there is no restriction on
host paths used. This is defined as a list of objects with a single `pathPrefix`
field, which allows hostPath volumes to mount a path that begins with an
allowed prefix. For example:
```yaml
allowedHostPaths:
# This allows "/foo", "/foo/", "/foo/bar" etc., but
# disallows "/fool", "/etc/foo" etc.
# "/foo/../" is never valid.
- pathPrefix: "/foo"
```
_Note: There are many ways a container with unrestricted access to the host
filesystem can escalate privileges, including reading data from other
containers, and abusing the credentials of system services, such as Kubelet._
**ReadOnlyRootFilesystem** - Requires that containers must run with a read-only
root filesystem (i.e. no writeable layer).
### Users and groups
**RunAsUser** - Controls the what user ID containers run as.
- *MustRunAs* - Requires at least one `range` to be specified. Uses the
minimum value of the first range as the default. Validates against all ranges.
- *MustRunAsNonRoot* - Requires that the pod be submitted with a non-zero
`runAsUser` or have the `USER` directive defined (using a numeric UID) in the
image. No default provided. Setting `allowPrivilegeEscalation=false` is strongly
recommended with this strategy.
- *RunAsAny* - No default provided. Allows any `runAsUser` to be specified.
**SupplementalGroups** - Controls which group IDs containers add.
- *MustRunAs* - Requires at least one `range` to be specified. Uses the
minimum value of the first range as the default. Validates against all ranges.
- *RunAsAny* - No default provided. Allows any `supplementalGroups` to be
specified.
### Privilege Escalation
These options control the `allowPrivilegeEscalation` container option. This bool
directly controls whether the
[`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt)
flag gets set on the container process. This flag will prevent `setuid` binaries
from changing the effective user ID, and prevent files from enabling extra
capabilities (e.g. it will prevent the use of the `ping` tool). This behavior is
required to effectively enforce `MustRunAsNonRoot`.
It defaults to `nil`. The default behavior of `nil` allows privilege escalation
so as to not break setuid binaries. Setting it to `false` ensures that no child
process of a container can gain more privileges than its parent.
**AllowPrivilegeEscalation** - Gates whether or not a user is allowed to set the
security context of a container to `allowPrivilegeEscalation=true`. This
defaults to allowed. When set to false, the container's
`allowPrivilegeEscalation` is defaulted to false.
**DefaultAllowPrivilegeEscalation** - Sets the default for the
`allowPrivilegeEscalation` option. The default behavior without this is to allow
privilege escalation so as to not break setuid binaries. If that behavior is not
desired, this field can be used to default to disallow, while still permitting
pods to request `allowPrivilegeEscalation` explicitly.
### Capabilities
Linux capabilities provide a finer grained breakdown of the privileges
traditionally associated with the superuser. Some of these capabilities can be
used to escalate privileges or for container breakout, and may be restricted by
the PodSecurityPolicy. For more details on Linux capabilities, see
[capabilities(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html).
The following fields take a list of capabilities, specified as the capability
name in ALL_CAPS without the `CAP_` prefix.
**AllowedCapabilities** - Provides a whitelist of capabilities that may be added
to a container. The default set of capabilities are implicitly allowed. The
empty set means that no additional capabilities may be added beyond the default
set. `*` can be used to allow all capabilities.
**RequiredDropCapabilities** - The capabilities which must be dropped from
containers. These capabilities are removed from the default set, and must not be
added. Capabilities listed in `RequiredDropCapabilities` must not be included in
`AllowedCapabilities` or `DefaultAddCapabilities`.
**DefaultAddCapabilities** - The capabilities which are added to containers by
default, in addition to the runtime defaults. See the [Docker
documentation](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)
for the default list of capabilities when using the Docker runtime.
### SELinux
- *MustRunAs* - Requires `seLinuxOptions` to be configured if not using
pre-allocated values. Uses `seLinuxOptions` as the default. Validates against
`seLinuxOptions`.
- *RunAsAny* - No default provided. Allows any `seLinuxOptions` to be
specified.
### AppArmor
Controlled via annotations on the PodSecurityPolicy. Refer to the [AppArmor
documentation](/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations).
### Seccomp
The use of seccomp profiles in pods can be controlled via annotations on the
PodSecurityPolicy. Seccomp is an alpha feature in Kubernetes.
**seccomp.security.alpha.kubernetes.io/defaultProfileName** - Annotation that
specifies the default seccomp profile to apply to containers. Possible values
are:
- `unconfined` - Seccomp is not applied to the container processes (this is the
default in Kubernetes), if no alternative is provided.
- `docker/default` - The Docker default seccomp profile is used.
- `localhost/<path>` - Specify a profile as a file on the node located at
`<seccomp_root>/<path>`, where `<seccomp_root>` is defined via the
`--seccomp-profile-root` flag on the Kubelet.
**seccomp.security.alpha.kubernetes.io/allowedProfileNames** - Annotation that
specifies which values are allowed for the pod seccomp annotations. Specified as
a comma-delimited list of allowed values. Possible values are those listed
above, plus `*` to allow all profiles. Absence of this annotation means that the
default cannot be changed.
For more details, see the
[PodSecurityPolicy RBAC example](https://git.k8s.io/examples/staging/podsecuritypolicy/rbac/README.md)
of applying PodSecurityPolicy to control access to privileged containers based
on role and groups when deploying Pods directly.