v1.9 patch (#6690)
* Merge branch 'master' of https://github.com/kubernetes/website into release-1.9 * 'master' of https://github.com/kubernetes/website: [maintenance] December link fixes (#6680) Update audit.md (#6381) Fixed typo concepts/policy/pod-security-policy.md: fix broken links. Fixed a typo `illgal` Add glossory entry for ReplicaSet # Conflicts: # docs/concepts/policy/pod-security-policy.md # docs/tasks/debug-application-cluster/audit.md * 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. * Workaround for Jekyllr frontmatter * fix typo * Update access-cluster.md with a comment that for IPv6 the user should use [::1] for the localhostpull/6624/merge
Andrew Chen
Zach Corleissen
parent
d97f7ab9da
commit
2caaa89a94
|
|
@ -1,4 +1,3 @@
|
||||||
---
|
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
kind: Service
|
kind: Service
|
||||||
metadata:
|
metadata:
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,3 @@
|
||||||
---
|
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
kind: Service
|
kind: Service
|
||||||
metadata:
|
metadata:
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,3 @@
|
||||||
---
|
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
kind: Pod
|
kind: Pod
|
||||||
metadata:
|
metadata:
|
||||||
|
|
|
||||||
|
|
@ -48,24 +48,24 @@ When creating a new API, consider whether to [aggregate your API with the Kubern
|
||||||
#### Declarative APIs
|
#### Declarative APIs
|
||||||
|
|
||||||
In a Declarative API, typically:
|
In a Declarative API, typically:
|
||||||
- your API consists of a relatively small number of relatively small objects (resources).
|
- Your API consists of a relatively small number of relatively small objects (resources).
|
||||||
- the objects define configuration of applications or infrastructure
|
- The objects define configuration of applications or infrastructure.
|
||||||
- the objects are updated relatively infrequently
|
- The objects are updated relatively infrequently.
|
||||||
- humans often need to read and write the objects
|
- Humans often need to read and write the objects.
|
||||||
- the main operations on the objects are CRUD-y (creating, reading, updating and deleting)
|
- The main operations on the objects are CRUD-y (creating, reading, updating and deleting).
|
||||||
- transactions across objects are not required: the API represents a desired state, not an exact state.
|
- Transactions across objects are not required: the API represents a desired state, not an exact state.
|
||||||
|
|
||||||
Imperative APIs are not declarative.
|
Imperative APIs are not declarative.
|
||||||
Signs that your API might not be declarative include:
|
Signs that your API might not be declarative include:
|
||||||
- the client says "do this", and then gets a synchornous response back when it is done.
|
- The client says "do this", and then gets a synchornous response back when it is done.
|
||||||
- the client says "do this", and then gets an operation ID back, and has to check a separate Operation objects to determine completion of the request.
|
- The client says "do this", and then gets an operation ID back, and has to check a separate Operation objects to determine completion of the request.
|
||||||
- you talk about Remote Procedure Calls (RPCs)
|
- You talk about Remote Procedure Calls (RPCs).
|
||||||
- directly stoing large amounts of data (e.g. > a few kB per object, or >1000s of objects)
|
- Directly storing large amounts of data (e.g. > a few kB per object, or >1000s of objects).
|
||||||
- high bandwidth access (10s of requests per second sustained) needed
|
- High bandwidth access (10s of requests per second sustained) needed.
|
||||||
- store end-user data (such as images, PII, etc) or other large-scale data processed by applications
|
- Store end-user data (such as images, PII, etc) or other large-scale data processed by applications.
|
||||||
- the natural operations on the objects are not CRUD-y.
|
- The natural operations on the objects are not CRUD-y.
|
||||||
- the API is not easily modeled as objects.
|
- The API is not easily modeled as objects.
|
||||||
- you chose to represent pending operations with an operation ID or operation object.
|
- You chose to represent pending operations with an operation ID or operation object.
|
||||||
|
|
||||||
### Should I use a configMap or a custom resource?
|
### Should I use a configMap or a custom resource?
|
||||||
|
|
||||||
|
|
@ -102,7 +102,7 @@ Aggregated APIs are subordinate APIServers that sit behind the primary API serve
|
||||||
|
|
||||||
Custom Resource Definitions (CRDS) allow users to create new types of resources without adding another APIserver. You do not need to understand API Aggregation to use CRDs.
|
Custom Resource Definitions (CRDS) allow users to create new types of resources without adding another APIserver. You do not need to understand API Aggregation to use CRDs.
|
||||||
|
|
||||||
Regardless of whether they are installed via CRDs or AA, the new resources are called Custom Resources to distinguish them from built-in Kubernetes resources (like pods)
|
Regardless of whether they are installed via CRDs or AA, the new resources are called Custom Resources to distinguish them from built-in Kubernetes resources (like pods).
|
||||||
|
|
||||||
## CustomResourceDefinitions
|
## CustomResourceDefinitions
|
||||||
|
|
||||||
|
|
@ -215,9 +215,9 @@ Kubernetes [client libraries](/docs/reference/client-libraries/) can be used to
|
||||||
|
|
||||||
When you add a custom resource, you can access it using:
|
When you add a custom resource, you can access it using:
|
||||||
- kubectl
|
- kubectl
|
||||||
- the kubernetes dynamic client
|
- The kubernetes dynamic client.
|
||||||
- a REST client that you write
|
- A REST client that you write.
|
||||||
- a client generated using Kubernetes client generation tools (generating one is an advanced undertaking, but some projects may provide a client along with the CRD or AA).
|
- A client generated using Kubernetes client generation tools (generating one is an advanced undertaking, but some projects may provide a client along with the CRD or AA).
|
||||||
|
|
||||||
{% endcapture %}
|
{% endcapture %}
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,8 +1,10 @@
|
||||||
apiVersion: extensions/v1beta1
|
apiVersion: extensions/v1beta1
|
||||||
kind: PodSecurityPolicy
|
kind: PodSecurityPolicy
|
||||||
metadata:
|
metadata:
|
||||||
name: permissive
|
name: example
|
||||||
spec:
|
spec:
|
||||||
|
privileged: false # Don't allow privileged pods!
|
||||||
|
# The rest fills in some required fields.
|
||||||
seLinux:
|
seLinux:
|
||||||
rule: RunAsAny
|
rule: RunAsAny
|
||||||
supplementalGroups:
|
supplementalGroups:
|
||||||
|
|
@ -11,10 +13,5 @@ spec:
|
||||||
rule: RunAsAny
|
rule: RunAsAny
|
||||||
fsGroup:
|
fsGroup:
|
||||||
rule: RunAsAny
|
rule: RunAsAny
|
||||||
hostPorts:
|
|
||||||
- min: 8000
|
|
||||||
max: 8080
|
|
||||||
volumes:
|
volumes:
|
||||||
- '*'
|
- '*'
|
||||||
allowedCapabilities:
|
|
||||||
- '*'
|
|
||||||
|
|
@ -1,71 +1,492 @@
|
||||||
---
|
---
|
||||||
approvers:
|
approvers:
|
||||||
- pweil-
|
- pweil-
|
||||||
|
- tallclair
|
||||||
title: Pod Security Policies
|
title: Pod Security Policies
|
||||||
---
|
---
|
||||||
|
|
||||||
Objects of type `PodSecurityPolicy` govern the ability
|
{% include feature-state-beta.md %}
|
||||||
to make requests on a pod that affect the `SecurityContext` that will be
|
|
||||||
applied to a pod and container.
|
|
||||||
|
|
||||||
See [PodSecurityPolicy proposal](https://git.k8s.io/community/contributors/design-proposals/auth/pod-security-policy.md) for more information.
|
Pod Security Policies enable fine-grained authorization of pod creation and
|
||||||
|
updates.
|
||||||
|
|
||||||
* TOC
|
* TOC
|
||||||
{:toc}
|
{:toc}
|
||||||
|
|
||||||
## What is a Pod Security Policy?
|
## What is a Pod Security Policy?
|
||||||
|
|
||||||
A _Pod Security Policy_ is a cluster-level resource that controls the
|
A _Pod Security Policy_ is a cluster-level resource that controls security
|
||||||
actions that a pod can perform and what it has the ability to access. The
|
sensitive aspects of the pod specification. The `PodSecurityPolicy` objects
|
||||||
`PodSecurityPolicy` objects define a set of conditions that a pod must
|
define a set of conditions that a pod must run with in order to be accepted into
|
||||||
run with in order to be accepted into the system. They allow an
|
the system, as well as defaults for the related fields. They allow an
|
||||||
administrator to control the following:
|
administrator to control the following:
|
||||||
|
|
||||||
| Control Aspect | Field Name |
|
| Control Aspect | Field Names |
|
||||||
| ---------------------------------------------------------------------- | ------------------------------------------- |
|
| ----------------------------------------------------| ------------------------------------------- |
|
||||||
| Running of privileged containers | `privileged` |
|
| Running of privileged containers | `privileged` |
|
||||||
| Default set of capabilities that will be added to a container | `defaultAddCapabilities` |
|
| Usage of the root namespaces | [`hostPID`, `hostIPC`](#host-namespaces) |
|
||||||
| Capabilities that will be dropped from a container | `requiredDropCapabilities` |
|
| Usage of host networking and ports | [`hostNetwork`, `hostPorts`](#host-namespaces) |
|
||||||
| Capabilities a container can request to be added | `allowedCapabilities` |
|
| Usage of volume types | [`volumes`](#volumes-and-file-systems) |
|
||||||
| Controlling the usage of volume types | [`volumes`](#controlling-volumes) |
|
| Usage of the host filesystem | [`allowedHostPaths`](#volumes-and-file-systems) |
|
||||||
| The use of host networking | [`hostNetwork`](#host-network) |
|
| Allocating an FSGroup that owns the pod's volumes | [`fsGroup`](#volumes-and-file-systems) |
|
||||||
| The use of host ports | `hostPorts` |
|
| Requiring the use of a read only root file system | [`readOnlyRootFilesystem`](#volumes-and-file-systems) |
|
||||||
| The use of host's PID namespace | `hostPID` |
|
| The user and group IDs of the container | [`runAsUser`, `supplementalGroups`](#users-and-groups) |
|
||||||
| The use of host's IPC namespace | `hostIPC` |
|
| Restricting escalation to root privileges | [`allowPrivilegeEscalation`, `defaultAllowPrivilegeEscalation`](#privilege-escalation) |
|
||||||
| The SELinux context of the container | [`seLinux`](#selinux) |
|
| Linux capabilities | [`defaultAddCapabilities`, `requiredDropCapabilities`, `allowedCapabilities`](#capabilities) |
|
||||||
| The user ID | [`runAsUser`](#runasuser) |
|
| The SELinux context of the container | [`seLinux`](#selinux) |
|
||||||
| Configuring allowable supplemental groups | [`supplementalGroups`](#supplementalgroups) |
|
| The AppArmor profile used by containers | [annotations](#apparmor) |
|
||||||
| Allocating an FSGroup that owns the pod's volumes | [`fsGroup`](#fsgroup) |
|
| The seccomp profile used by containers | [annotations](#seccomp) |
|
||||||
| 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.
|
|
||||||
|
|
||||||
|
|
||||||
## Strategies
|
## Enabling Pod Security Policies
|
||||||
|
|
||||||
### RunAsUser
|
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.
|
||||||
|
|
||||||
- *MustRunAs* - Requires a `range` to be configured. Uses the first value
|
Since the pod security policy API (`extensions/v1beta1/podsecuritypolicy`) is
|
||||||
of the range as the default. Validates against the configured range.
|
enabled independently of the admission controller, for existing clusters it is
|
||||||
|
recommended that policies are added and authorized before enabling the admission
|
||||||
|
controller.
|
||||||
|
|
||||||
|
## Authorizing Policies
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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)).
|
||||||
|
|
||||||
|
### Via RBAC
|
||||||
|
|
||||||
|
[RBAC](/docs/admin/authorization/rbac/) is a standard Kubernetes authorization
|
||||||
|
mode, and can easily be used to authorize use of policies.
|
||||||
|
|
||||||
|
First, a `Role` or `ClusterRole` needs to grant access to `use` the desired
|
||||||
|
policies. The rules to grant access look like this:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
kind: ClusterRole
|
||||||
|
apiVersion: rbac.authorization.k8s.io/v1
|
||||||
|
metadata:
|
||||||
|
name: <role name>
|
||||||
|
rules:
|
||||||
|
- apiGroups: ['extensions']
|
||||||
|
resources: ['podsecuritypolicies']
|
||||||
|
verbs: ['use']
|
||||||
|
resourceNames:
|
||||||
|
- <list of policies to authorize>
|
||||||
|
```
|
||||||
|
|
||||||
|
Then the `(Cluster)Role` is bound to the authorized user(s):
|
||||||
|
|
||||||
|
```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>
|
||||||
|
```
|
||||||
|
|
||||||
|
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
|
||||||
|
apiGroup: rbac.authorization.k8s.io
|
||||||
|
name: system:serviceaccounts
|
||||||
|
# Or equivalently, all authenticated users in a namespace:
|
||||||
|
- kind: Group
|
||||||
|
apiGroup: rbac.authorization.k8s.io
|
||||||
|
name: system:authenticated
|
||||||
|
```
|
||||||
|
|
||||||
|
For more examples of RBAC bindings, see [Role Binding
|
||||||
|
Examples](docs/admin/authorization/rbac/#role-binding-examples). For a complete
|
||||||
|
example of authorizing a PodSecurityPolicy, see
|
||||||
|
[below](#example).
|
||||||
|
|
||||||
|
|
||||||
|
### Troubleshooting
|
||||||
|
|
||||||
|
- The [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 users
|
||||||
|
would be able to create privileged containers. For more details on configuring
|
||||||
|
Controller Manager authorization, see [Controller
|
||||||
|
Roles](docs/admin/authorization/rbac/#controller-roles).
|
||||||
|
|
||||||
|
## Policy Order
|
||||||
|
|
||||||
|
In addition to restricting pod creation and update, pod security policies can
|
||||||
|
also be used to provide default values for many of the fields that it
|
||||||
|
controls. When multiple policies are available, the pod security policy
|
||||||
|
controller selects policies in the following order:
|
||||||
|
|
||||||
|
1. If any policies successfully validate the pod without altering it, they are
|
||||||
|
used.
|
||||||
|
2. Otherwise, the first valid policy in alphabetical order is used.
|
||||||
|
|
||||||
|
## Example
|
||||||
|
|
||||||
|
_This example assumes you have a running cluster with the PodSecurityPolicy
|
||||||
|
admission controller enabled and you have cluster admin privileges._
|
||||||
|
|
||||||
|
### Set up
|
||||||
|
|
||||||
|
Set up a namespace and a service account to act as for this example. We'll use
|
||||||
|
this service account to mock a non-admin user.
|
||||||
|
|
||||||
|
```shell
|
||||||
|
$ kubectl create namespace psp-example
|
||||||
|
$ kubectl create serviceaccount -n psp-example fake-user
|
||||||
|
$ kubectl create rolebinding -n psp-example fake-editor --clusterrole=edit --serviceaccount=psp-example:fake-user
|
||||||
|
```
|
||||||
|
|
||||||
|
To make it clear which user we're acting as and save some typing, create 2
|
||||||
|
aliases:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
$ alias kubectl-admin='kubectl -n psp-example'
|
||||||
|
$ alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n psp-example'
|
||||||
|
```
|
||||||
|
|
||||||
|
### Create a policy and a pod
|
||||||
|
|
||||||
|
Define the example PodSecurityPolicy object in a file. This is a policy that
|
||||||
|
simply prevents the creation of privileged pods.
|
||||||
|
|
||||||
|
{% include code.html language="yaml" file="example-psp.yaml" ghlink="/docs/concepts/policy/example-psp.yaml" %}
|
||||||
|
|
||||||
|
And create it with kubectl:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
$ kubectl-admin create -f example-psp.yaml
|
||||||
|
```
|
||||||
|
|
||||||
|
Now, as the unprivileged user, try to create a simple pod:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
$ kubectl-user create -f- <<EOF
|
||||||
|
apiVersion: v1
|
||||||
|
kind: Pod
|
||||||
|
metadata:
|
||||||
|
name: pause
|
||||||
|
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: []
|
||||||
|
```
|
||||||
|
|
||||||
|
**What happened?** Although the PodSecurityPolicy was created, neither the
|
||||||
|
pod's service account nor `fake-user` have permission to use the new policy:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
$ kubectl-user auth can-i use podsecuritypolicy/example
|
||||||
|
no
|
||||||
|
```
|
||||||
|
|
||||||
|
Create the rolebinding to grant `fake-user` the `use` verb on the example
|
||||||
|
policy:
|
||||||
|
|
||||||
|
_Note: This is not the recommended way! See the [next section](#run-another-pod)
|
||||||
|
for the preferred approach._
|
||||||
|
|
||||||
|
```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
|
||||||
|
```
|
||||||
|
|
||||||
|
Now retry creating the pod:
|
||||||
|
|
||||||
|
```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
|
||||||
|
```
|
||||||
|
|
||||||
|
It works as expected! But any attempts to create a privileged pod should still
|
||||||
|
be denied:
|
||||||
|
|
||||||
|
```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]
|
||||||
|
```
|
||||||
|
|
||||||
|
Delete the pod before moving on:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
$ kubectl-user delete pause
|
||||||
|
```
|
||||||
|
|
||||||
|
### Run another pod
|
||||||
|
|
||||||
|
Let's try that again, slightly differently:
|
||||||
|
|
||||||
|
```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
|
||||||
|
```
|
||||||
|
|
||||||
|
**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.
|
||||||
|
|
||||||
|
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`:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
$ kubectl-admin create rolebinding default:psp:unprivileged \
|
||||||
|
--role=psp:unprivileged \
|
||||||
|
--serviceaccount=psp-example:default
|
||||||
|
rolebinding "default:psp:unprivileged" created
|
||||||
|
```
|
||||||
|
|
||||||
|
Now if you give it a minute to retry, the replicaset-controller should
|
||||||
|
eventually succeed in creating the pod:
|
||||||
|
|
||||||
|
```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
|
- *MustRunAsNonRoot* - Requires that the pod be submitted with a non-zero
|
||||||
`runAsUser` or have the `USER` directive defined in the image. No default
|
`runAsUser` or have the `USER` directive defined (using a numeric UID) in the
|
||||||
provided.
|
image. No default provided. Setting `allowPrivilegeEscalation=false` is strongly
|
||||||
|
recommended with this strategy.
|
||||||
- *RunAsAny* - No default provided. Allows any `runAsUser` to be specified.
|
- *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
|
### SELinux
|
||||||
|
|
||||||
- *MustRunAs* - Requires `seLinuxOptions` to be configured if not using
|
- *MustRunAs* - Requires `seLinuxOptions` to be configured if not using
|
||||||
|
|
@ -74,213 +495,29 @@ pre-allocated values. Uses `seLinuxOptions` as the default. Validates against
|
||||||
- *RunAsAny* - No default provided. Allows any `seLinuxOptions` to be
|
- *RunAsAny* - No default provided. Allows any `seLinuxOptions` to be
|
||||||
specified.
|
specified.
|
||||||
|
|
||||||
### SupplementalGroups
|
### AppArmor
|
||||||
|
|
||||||
- *MustRunAs* - Requires at least one range to be specified. Uses the
|
Controlled via annotations on the PodSecurityPolicy. Refer to the [AppArmor
|
||||||
minimum value of the first range as the default. Validates against all ranges.
|
documentation](/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations).
|
||||||
- *RunAsAny* - No default provided. Allows any `supplementalGroups` to be
|
|
||||||
specified.
|
|
||||||
|
|
||||||
### FSGroup
|
### Seccomp
|
||||||
|
|
||||||
- *MustRunAs* - Requires at least one range to be specified. Uses the
|
The use of seccomp profiles in pods can be controlled via annotations on the
|
||||||
minimum value of the first range as the default. Validates against the
|
PodSecurityPolicy. Seccomp is an alpha feature in Kubernetes.
|
||||||
first ID in the first range.
|
|
||||||
- *RunAsAny* - No default provided. Allows any `fsGroup` ID to be specified.
|
|
||||||
|
|
||||||
### Controlling Volumes
|
**seccomp.security.alpha.kubernetes.io/defaultProfileName** - Annotation that
|
||||||
|
specifies the default seccomp profile to apply to containers. Possible values
|
||||||
|
are:
|
||||||
|
|
||||||
The usage of specific volume types can be controlled by setting the
|
- `unconfined` - Seccomp is not applied to the container processes (this is the
|
||||||
volumes field of the PSP. The allowable values of this field correspond
|
default in Kubernetes), if no alternative is provided.
|
||||||
to the volume sources that are defined when creating a volume:
|
- `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.
|
||||||
|
|
||||||
1. azureFile
|
**seccomp.security.alpha.kubernetes.io/allowedProfileNames** - Annotation that
|
||||||
1. azureDisk
|
specifies which values are allowed for the pod seccomp annotations. Specified as
|
||||||
1. flocker
|
a comma-delimited list of allowed values. Possible values are those listed
|
||||||
1. flexVolume
|
above, plus `*` to allow all profiles. Absence of this annotation means that the
|
||||||
1. hostPath
|
default cannot be changed.
|
||||||
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
|
|
||||||
apiVersion: extensions/v1beta1
|
|
||||||
kind: PodSecurityPolicy
|
|
||||||
metadata:
|
|
||||||
name: custom-paths
|
|
||||||
spec:
|
|
||||||
allowedHostPaths:
|
|
||||||
# This allows "/foo", "/foo/", "/foo/bar" etc., but
|
|
||||||
# disallows "/fool", "/etc/foo" etc.
|
|
||||||
- pathPrefix: "/foo"
|
|
||||||
```
|
|
||||||
|
|
||||||
### AllowedFlexVolumes
|
|
||||||
|
|
||||||
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:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
apiVersion: extensions/v1beta1
|
|
||||||
kind: PodSecurityPolicy
|
|
||||||
metadata:
|
|
||||||
name: allow-flex-volumes
|
|
||||||
spec:
|
|
||||||
volumes:
|
|
||||||
- flexVolume
|
|
||||||
allowedFlexVolumes:
|
|
||||||
- driver: example/lvm
|
|
||||||
- driver: example/cifs
|
|
||||||
```
|
|
||||||
|
|
||||||
## 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 create -f ./psp.yaml
|
|
||||||
podsecuritypolicy "permissive" created
|
|
||||||
```
|
|
||||||
|
|
||||||
## Getting a list of Pod Security Policies
|
|
||||||
|
|
||||||
To get a list of existing policies, use `kubectl get`:
|
|
||||||
|
|
||||||
```shell
|
|
||||||
$ 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]
|
|
||||||
```
|
|
||||||
|
|
||||||
## Editing a Pod Security Policy
|
|
||||||
|
|
||||||
To modify policy interactively, use `kubectl edit`:
|
|
||||||
|
|
||||||
```shell
|
|
||||||
$ kubectl edit psp permissive
|
|
||||||
```
|
|
||||||
|
|
||||||
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 delete psp permissive
|
|
||||||
podsecuritypolicy "permissive" deleted
|
|
||||||
```
|
|
||||||
|
|
||||||
## Enabling Pod Security Policies
|
|
||||||
|
|
||||||
In order to use Pod Security Policies in your cluster you must ensure the
|
|
||||||
following
|
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
## Working With RBAC
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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/).
|
|
||||||
|
|
||||||
Access to given PSP policies for a user will be effective only when creating
|
|
||||||
Pods directly.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,27 @@
|
||||||
|
apiVersion: extensions/v1beta1
|
||||||
|
kind: PodSecurityPolicy
|
||||||
|
metadata:
|
||||||
|
name: privileged
|
||||||
|
annotations:
|
||||||
|
seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
|
||||||
|
spec:
|
||||||
|
privileged: true
|
||||||
|
allowPrivilegeEscalation: true
|
||||||
|
allowedCapabilities:
|
||||||
|
- '*'
|
||||||
|
volumes:
|
||||||
|
- '*'
|
||||||
|
hostNetwork: true
|
||||||
|
hostPorts:
|
||||||
|
- min: 0
|
||||||
|
max: 65535
|
||||||
|
hostIPC: true
|
||||||
|
hostPID: true
|
||||||
|
runAsUser:
|
||||||
|
rule: 'RunAsAny'
|
||||||
|
seLinux:
|
||||||
|
rule: 'RunAsAny'
|
||||||
|
supplementalGroups:
|
||||||
|
rule: 'RunAsAny'
|
||||||
|
fsGroup:
|
||||||
|
rule: 'RunAsAny'
|
||||||
|
|
@ -0,0 +1,48 @@
|
||||||
|
apiVersion: extensions/v1beta1
|
||||||
|
kind: PodSecurityPolicy
|
||||||
|
metadata:
|
||||||
|
name: restricted
|
||||||
|
annotations:
|
||||||
|
seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default'
|
||||||
|
apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
|
||||||
|
seccomp.security.alpha.kubernetes.io/defaultProfileName: 'docker/default'
|
||||||
|
apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default'
|
||||||
|
spec:
|
||||||
|
privileged: false
|
||||||
|
# Required to prevent escalations to root.
|
||||||
|
allowPrivilegeEscalation: false
|
||||||
|
# This is redundant with non-root + disallow privilege escalation,
|
||||||
|
# but we can provide it for defense in depth.
|
||||||
|
requiredDropCapabilities:
|
||||||
|
- ALL
|
||||||
|
# Allow core volume types.
|
||||||
|
volumes:
|
||||||
|
- 'configMap'
|
||||||
|
- 'emptyDir'
|
||||||
|
- 'projected'
|
||||||
|
- 'secret'
|
||||||
|
- 'downwardAPI'
|
||||||
|
# Assume that persistentVolumes set up by the cluster admin are safe to use.
|
||||||
|
- 'persistentVolumeClaim'
|
||||||
|
hostNetwork: false
|
||||||
|
hostIPC: false
|
||||||
|
hostPID: false
|
||||||
|
runAsUser:
|
||||||
|
# Require the container to run without root privileges.
|
||||||
|
rule: 'MustRunAsNonRoot'
|
||||||
|
seLinux:
|
||||||
|
# This policy assumes the nodes are using AppArmor rather than SELinux.
|
||||||
|
rule: 'RunAsAny'
|
||||||
|
supplementalGroups:
|
||||||
|
rule: 'MustRunAs'
|
||||||
|
ranges:
|
||||||
|
# Forbid adding the root group.
|
||||||
|
- min: 1
|
||||||
|
max: 65535
|
||||||
|
fsGroup:
|
||||||
|
rule: 'MustRunAs'
|
||||||
|
ranges:
|
||||||
|
# Forbid adding the root group.
|
||||||
|
- min: 1
|
||||||
|
max: 65535
|
||||||
|
readOnlyRootFilesystem: false
|
||||||
|
|
@ -705,7 +705,7 @@ Complete this template for the scheduler pod:
|
||||||
"containers": [
|
"containers": [
|
||||||
{
|
{
|
||||||
"name": "kube-scheduler",
|
"name": "kube-scheduler",
|
||||||
"image": "$HYBERKUBE_IMAGE",
|
"image": "$HYPERKUBE_IMAGE",
|
||||||
"command": [
|
"command": [
|
||||||
"/hyperkube",
|
"/hyperkube",
|
||||||
"scheduler",
|
"scheduler",
|
||||||
|
|
|
||||||
|
|
@ -55,7 +55,8 @@ $ kubectl proxy --port=8080 &
|
||||||
|
|
||||||
See [kubectl proxy](/docs/user-guide/kubectl/{{page.version}}/#proxy) for more details.
|
See [kubectl proxy](/docs/user-guide/kubectl/{{page.version}}/#proxy) for more details.
|
||||||
|
|
||||||
Then you can explore the API with curl, wget, or a browser, like so:
|
Then you can explore the API with curl, wget, or a browser, replacing localhost
|
||||||
|
with [::1] for IPv6, like so:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
$ curl http://localhost:8080/api/
|
$ curl http://localhost:8080/api/
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
kind: Service
|
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
|
kind: Service
|
||||||
metadata:
|
metadata:
|
||||||
name: frontend
|
name: frontend
|
||||||
spec:
|
spec:
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,3 @@
|
||||||
---
|
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
kind: Service
|
kind: Service
|
||||||
metadata:
|
metadata:
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,3 @@
|
||||||
---
|
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
kind: Service
|
kind: Service
|
||||||
metadata:
|
metadata:
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,3 @@
|
||||||
---
|
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
kind: Service
|
kind: Service
|
||||||
metadata:
|
metadata:
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,3 @@
|
||||||
---
|
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
kind: ReplicationController
|
kind: ReplicationController
|
||||||
metadata:
|
metadata:
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,3 @@
|
||||||
---
|
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
kind: Service
|
kind: Service
|
||||||
metadata:
|
metadata:
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,3 @@
|
||||||
---
|
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
kind: ReplicationController
|
kind: ReplicationController
|
||||||
metadata:
|
metadata:
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,3 @@
|
||||||
---
|
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
kind: Service
|
kind: Service
|
||||||
metadata:
|
metadata:
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,3 @@
|
||||||
---
|
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
kind: Pod
|
kind: Pod
|
||||||
metadata:
|
metadata:
|
||||||
|
|
|
||||||
|
|
@ -202,6 +202,10 @@ func walkConfigFiles(inDir string, fn func(name, path string, data [][]byte)) er
|
||||||
if err != nil {
|
if err != nil {
|
||||||
return err
|
return err
|
||||||
}
|
}
|
||||||
|
// workaround for Jekyllr limit
|
||||||
|
if bytes.HasPrefix(data, []byte("---\n")) {
|
||||||
|
return fmt.Errorf("YAML file cannot start with \"---\", please remove the first line")
|
||||||
|
}
|
||||||
name := strings.TrimSuffix(file, ext)
|
name := strings.TrimSuffix(file, ext)
|
||||||
|
|
||||||
var docs [][]byte
|
var docs [][]byte
|
||||||
|
|
@ -220,7 +224,10 @@ func walkConfigFiles(inDir string, fn func(name, path string, data [][]byte)) er
|
||||||
if err != nil {
|
if err != nil {
|
||||||
return fmt.Errorf("%s: %v", path, err)
|
return fmt.Errorf("%s: %v", path, err)
|
||||||
}
|
}
|
||||||
docs = append(docs, out)
|
// deal with "empty" document (e.g. pure comments)
|
||||||
|
if string(out) != "null" {
|
||||||
|
docs = append(docs, out)
|
||||||
|
}
|
||||||
}
|
}
|
||||||
} else {
|
} else {
|
||||||
docs = append(docs, data)
|
docs = append(docs, data)
|
||||||
|
|
@ -284,7 +291,9 @@ func TestExampleObjectSchemas(t *testing.T) {
|
||||||
"nginx-deployment": {&extensions.Deployment{}},
|
"nginx-deployment": {&extensions.Deployment{}},
|
||||||
},
|
},
|
||||||
"../docs/concepts/policy": {
|
"../docs/concepts/policy": {
|
||||||
"psp": {&extensions.PodSecurityPolicy{}},
|
"privileged-psp": {&extensions.PodSecurityPolicy{}},
|
||||||
|
"restricted-psp": {&extensions.PodSecurityPolicy{}},
|
||||||
|
"example-psp": {&extensions.PodSecurityPolicy{}},
|
||||||
},
|
},
|
||||||
"../docs/concepts/services-networking": {
|
"../docs/concepts/services-networking": {
|
||||||
"curlpod": {&extensions.Deployment{}},
|
"curlpod": {&extensions.Deployment{}},
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue