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

Merge remote-tracking branch 'upstream/master' into dev-1.19

Browse Source
This commit is contained in:
Savitha Raghunathan
2020-05-26 18:03:50 -04:00
parent 32d7f11a95 685e54df99
commit 6311db5da4
97 changed files with 3552 additions and 867 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/architecture/nodes.md
+1 -1
View File
@@ -308,7 +308,7 @@ Node objects track information about the Node's resource capacity (for example:
of memory available, and the number of CPUs).
Nodes that [self register](#self-registration-of-nodes) report their capacity during
registration. If you [manually](#manual-node-administration) add a Node, then
you need to set the node's capacity informaton when you add it.
you need to set the node's capacity information when you add it.
The Kubernetes {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} ensures that
there are enough resources for all the Pods on a Node. The scheduler checks that the sum
content/en/docs/concepts/configuration/overview.md
+1 -1
View File
@@ -77,7 +77,7 @@ The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the
- `imagePullPolicy: IfNotPresent`: the image is pulled only if it is not already present locally.
- `imagePullPolicy: Always`: the image is pulled every time the pod is started.
- `imagePullPolicy: Always`: every time the kubelet launches a container, the kubelet queries the container image registry to resolve the name to an image digest. If the kubelet has a container image with that exact digest cached locally, the kubelet uses its cached image; otherwise, the kubelet downloads (pulls) the image with the resolved digest, and uses that image to launch the container.
- `imagePullPolicy` is omitted and either the image tag is `:latest` or it is omitted: `Always` is applied.
content/en/docs/concepts/configuration/secret.md
+36 -4
View File
@@ -580,7 +580,7 @@ spec:
- name: foo
secret:
secretName: mysecret
defaultMode: 256
defaultMode: 0400
```
Then, the secret will be mounted on `/etc/foo` and all the files created by the
@@ -590,6 +590,38 @@ Note that the JSON spec doesn't support octal notation, so use the value 256 for
0400 permissions. If you use YAML instead of JSON for the Pod, you can use octal
notation to specify permissions in a more natural way.
Note if you `kubectl exec` into the Pod, you need to follow the symlink to find
the expected file mode. For example,
Check the secrets file mode on the pod.
```
kubectl exec mypod -it sh
cd /etc/foo
ls -l
```
The output is similar to this:
```
total 0
lrwxrwxrwx 1 root root 15 May 18 00:18 password -> ..data/password
lrwxrwxrwx 1 root root 15 May 18 00:18 username -> ..data/username
```
Follow the symlink to find the correct file mode.
```
cd /etc/foo/..data
ls -l
```
The output is similar to this:
```
total 8
-r-------- 1 root root 12 May 18 00:18 password
-r-------- 1 root root 5 May 18 00:18 username
```
You can also use mapping, as in the previous example, and specify different
permissions for different files like this:
@@ -612,12 +644,12 @@ spec:
items:
- key: username
path: my-group/my-username
mode: 511
mode: 0777
```
In this case, the file resulting in `/etc/foo/my-group/my-username` will have
permission value of `0777`. Owing to JSON limitations, you must specify the mode
in decimal notation.
permission value of `0777`. If you use JSON, owing to JSON limitations, you
must specify the mode in decimal notation, `511`.
Note that this permission value might be displayed in decimal notation if you
read it later.
content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
+4 -2
View File
@@ -83,11 +83,13 @@ For example:
#### Support traffic shaping
**Experimental Feature**
The CNI networking plugin also supports pod ingress and egress traffic shaping. You can use the official [bandwidth](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth)
plugin offered by the CNI plugin team or use your own plugin with bandwidth control functionality.
If you want to enable traffic shaping support, you must add a `bandwidth` plugin to your CNI configuration file
(default `/etc/cni/net.d`).
If you want to enable traffic shaping support, you must add the `bandwidth` plugin to your CNI configuration file
(default `/etc/cni/net.d`) and ensure that the binary is included in your CNI bin dir (default `/opt/cni/bin`).
```json
{
content/en/docs/concepts/overview/working-with-objects/namespaces.md
+5 -5
View File
@@ -51,11 +51,11 @@ You can list the current namespaces in a cluster using:
kubectl get namespace
```
```
NAME STATUS AGE
default Active 1d
kube-system Active 1d
kube-public Active 1d
kube-node-lease Active 1d
NAME STATUS AGE
default Active 1d
kube-node-lease Active 1d
kube-public Active 1d
kube-system Active 1d
```
Kubernetes starts with three initial namespaces:
content/en/docs/concepts/policy/pod-security-policy.md
+4
View File
@@ -374,6 +374,8 @@ several security mechanisms.
{{< codenew file="policy/restricted-psp.yaml" >}}
See [Pod Security Standards](/docs/concepts/security/pod-security-standards/#policy-instantiation) for more examples.
## Policy Reference
### Privileged
@@ -633,6 +635,8 @@ Refer to the [Sysctl documentation](
{{% capture whatsnext %}}
See [Pod Security Standards](/docs/concepts/security/pod-security-standards/) for policy recommendations.
Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details.
{{% /capture %}}
content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md
+2 -13
View File
@@ -77,21 +77,10 @@ A toleration "matches" a taint if the keys are the same and the effects are the
There are two special cases:
* An empty `key` with operator `Exists` matches all keys, values and effects which means this
An empty `key` with operator `Exists` matches all keys, values and effects which means this
will tolerate everything.
```yaml
tolerations:
- operator: "Exists"
```
* An empty `effect` matches all effects with key `key`.
```yaml
tolerations:
- key: "key"
operator: "Exists"
```
An empty `effect` matches all effects with key `key`.
{{< /note >}}
content/en/docs/concepts/security/pod-security-standards.md
+300
View File
@@ -0,0 +1,300 @@
---
reviewers:
- tallclair
title: Pod Security Standards
content_template: templates/concept
weight: 10
---
{{% capture overview %}}
Security settings for Pods are typically applied by using [security
contexts](/docs/tasks/configure-pod-container/security-context/). Security Contexts allow for the
definition of privilege and access controls on a per-Pod basis.
The enforcement and policy-based definition of cluster requirements of security contexts has
previously been achieved using [Pod Security Policy](/docs/concepts/policy/pod-security-policy/). A
_Pod Security Policy_ is a cluster-level resource that controls security sensitive aspects of the
Pod specification.
However, numerous means of policy enforcement have arisen that augment or replace the use of
PodSecurityPolicy. The intent of this page is to detail recommended Pod security profiles, decoupled
from any specific instantiation.
{{% /capture %}}
{{% capture body %}}
## Policy Types
There is an immediate need for base policy definitions to broadly cover the security spectrum. These
should range from highly restricted to highly flexible:
- **_Privileged_** - Unrestricted policy, providing the widest possible level of permissions. This
policy allows for known privilege escalations.
- **_Baseline/Default_** - Minimally restrictive policy while preventing known privilege
escalations. Allows the default (minimally specified) Pod configuration.
- **_Restricted_** - Heavily restricted policy, following current Pod hardening best practices.
## Policies
### Privileged
The Privileged policy is purposely-open, and entirely unrestricted. This type of policy is typically
aimed at system- and infrastructure-level workloads managed by privileged, trusted users.
The privileged policy is defined by an absence of restrictions. For blacklist-oriented enforcement
mechanisms (such as gatekeeper), the privileged profile may be an absence of applied constraints
rather than an instantiated policy. In contrast, for a whitelist oriented mechanism (such as Pod
Security Policy) the privileged policy should enable all controls (disable all restrictions).
### Baseline/Default
The Baseline/Default policy is aimed at ease of adoption for common containerized workloads while
preventing known privilege escalations. This policy is targeted at application operators and
developers of non-critical applications. The following listed controls should be
enforced/disallowed:
<table>
<caption style="display:none">Baseline policy specification</caption>
<tbody>
<tr>
<td><strong>Control</strong></td>
<td><strong>Policy</strong></td>
</tr>
<tr>
<td>Host Namespaces</td>
<td>
Sharing the host namespaces must be disallowed.<br>
<br><b>Restricted Fields:</b><br>
spec.hostNetwork<br>
spec.hostPID<br>
spec.hostIPC<br>
<br><b>Allowed Values:</b> false<br>
</td>
</tr>
<tr>
<td>Privileged Containers</td>
<td>
Privileged Pods disable most security mechanisms and must be disallowed.<br>
<br><b>Restricted Fields:</b><br>
spec.containers[*].securityContext.privileged<br>
spec.initContainers[*].securityContext.privileged<br>
<br><b>Allowed Values:</b> false, undefined/nil<br>
</td>
</tr>
<tr>
<td>Capabilities</td>
<td>
Adding additional capabilities beyond the <a href="https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities">default set</a> must be disallowed.<br>
<br><b>Restricted Fields:</b><br>
spec.containers[*].securityContext.capabilities.add<br>
spec.initContainers[*].securityContext.capabilities.add<br>
<br><b>Allowed Values:</b> empty (optionally whitelisted defaults)<br>
</td>
</tr>
<tr>
<td>HostPath Volumes</td>
<td>
HostPath volumes must be forbidden.<br>
<br><b>Restricted Fields:</b><br>
spec.volumes[*].hostPath<br>
<br><b>Allowed Values:</b> undefined/nil<br>
</td>
</tr>
<tr>
<td>Host Ports</td>
<td>
HostPorts should be disallowed, or at minimum restricted to a whitelist.<br>
<br><b>Restricted Fields:</b><br>
spec.containers[*].ports[*].hostPort<br>
spec.initContainers[*].ports[*].hostPort<br>
<br><b>Allowed Values:</b> 0, undefined, (whitelisted)<br>
</td>
</tr>
<tr>
<td>AppArmor <em>(optional)</em></td>
<td>
On supported hosts, the `runtime/default` AppArmor profile is applied by default. The default policy should prevent overriding or disabling the policy, or restrict overrides to a whitelisted set of profiles.<br>
<br><b>Restricted Fields:</b><br>
metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']<br>
<br><b>Allowed Values:</b> runtime/default, undefined<br>
</td>
</tr>
<tr>
<td>SELinux <em>(optional)</em></td>
<td>
Setting custom SELinux options should be disallowed.<br>
<br><b>Restricted Fields:</b><br>
spec.securityContext.seLinuxOptions<br>
spec.containers[*].securityContext.seLinuxOptions<br>
spec.initContainers[*].securityContext.seLinuxOptions<br>
<br><b>Allowed Values:</b> undefined/nil<br>
</td>
</tr>
</tbody>
</table>
### Restricted
The Restricted policy is aimed at enforcing current Pod hardening best practices, at the expense of
some compatibility. It is targeted at operators and developers of security-critical applications, as
well as lower-trust users.The following listed controls should be enforced/disallowed:
<table>
<caption style="display:none">Restricted policy specification</caption>
<tbody>
<tr>
<td><strong>Control</strong></td>
<td><strong>Policy</strong></td>
</tr>
<tr>
<td colspan="2"><em>Everything from the default profile.</em></td>
</tr>
<tr>
<td>Volume Types</td>
<td>
In addition to restricting HostPath volumes, the restricted profile limits usage of non-core volume types to those defined through PersistentVolumes.<br>
<br><b>Restricted Fields:</b><br>
spec.volumes[*].hostPath<br>
spec.volumes[*].gcePersistentDisk<br>
spec.volumes[*].awsElasticBlockStore<br>
spec.volumes[*].gitRepo<br>
spec.volumes[*].nfs<br>
spec.volumes[*].iscsi<br>
spec.volumes[*].glusterfs<br>
spec.volumes[*].rbd<br>
spec.volumes[*].flexVolume<br>
spec.volumes[*].cinder<br>
spec.volumes[*].cephFS<br>
spec.volumes[*].flocker<br>
spec.volumes[*].fc<br>
spec.volumes[*].azureFile<br>
spec.volumes[*].vsphereVolume<br>
spec.volumes[*].quobyte<br>
spec.volumes[*].azureDisk<br>
spec.volumes[*].portworxVolume<br>
spec.volumes[*].scaleIO<br>
spec.volumes[*].storageos<br>
spec.volumes[*].csi<br>
<br><b>Allowed Values:</b> undefined/nil<br>
</td>
</tr>
<tr>
<td>Privilege Escalation</td>
<td>
Privilege escalation to root should not be allowed.<br>
<br><b>Restricted Fields:</b><br>
spec.containers[*].securityContext.privileged<br>
spec.initContainers[*].securityContext.privileged<br>
<br><b>Allowed Values:</b> false, undefined/nil<br>
</td>
</tr>
<tr>
<td>Running as Non-root</td>
<td>
Containers must be required to run as non-root users.<br>
<br><b>Restricted Fields:</b><br>
spec.securityContext.runAsNonRoot<br>
spec.containers[*].securityContext.runAsNonRoot<br>
spec.initContainers[*].securityContext.runAsNonRoot<br>
<br><b>Allowed Values:</b> true<br>
</td>
</tr>
<tr>
<td>Non-root groups <em>(optional)</em></td>
<td>
Containers should be forbidden from running with a root primary or supplementary GID.<br>
<br><b>Restricted Fields:</b><br>
spec.securityContext.runAsGroup<br>
spec.securityContext.supplementalGroups[*]<br>
spec.securityContext.fsGroup<br>
spec.containers[*].securityContext.runAsGroup<br>
spec.containers[*].securityContext.supplementalGroups[*]<br>
spec.containers[*].securityContext.fsGroup<br>
spec.initContainers[*].securityContext.runAsGroup<br>
spec.initContainers[*].securityContext.supplementalGroups[*]<br>
spec.initContainers[*].securityContext.fsGroup<br>
<br><b>Allowed Values:</b><br>
non-zero<br>
undefined / nil (except for `*.runAsGroup`)<br>
</td>
</tr>
<tr>
<td>Seccomp</td>
<td>
The runtime/default seccomp profile must be required, or allow additional whitelisted values.<br>
<br><b>Restricted Fields:</b><br>
metadata.annotations['seccomp.security.alpha.kubernetes.io/pod']<br>
metadata.annotations['container.seccomp.security.alpha.kubernetes.io/*']<br>
<br><b>Allowed Values:</b><br>
runtime/default<br>
undefined (container annotation)<br>
</td>
</tr>
</tbody>
</table>
## Policy Instantiation
Decoupling policy definition from policy instantiation allows for a common understanding and
consistent language of policies across clusters, independent of the underlying enforcement
mechanism.
As mechanisms mature, they will be defined below on a per-policy basis. The methods of enforcement
of individual policies are not defined here.
[**PodSecurityPolicy**](/docs/concepts/policy/pod-security-policy/)
- [Privileged](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/privileged-psp.yaml)
- [Baseline](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/baseline-psp.yaml)
- [Restricted](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/restricted-psp.yaml)
## FAQ
### Why isn't there a profile between privileged and default?
The three profiles defined here have a clear linear progression from most secure (restricted) to least
secure (privileged), and cover a broad set of workloads. Privileges required above the baseline
policy are typically very application specific, so we do not offer a standard profile in this
niche. This is not to say that the privileged profile should always be used in this case, but that
policies in this space need to be defined on a case-by-case basis.
SIG Auth may reconsider this position in the future, should a clear need for other profiles arise.
### What's the difference between a security policy and a security context?
[Security Contexts](/docs/tasks/configure-pod-container/security-context/) configure Pods and
Containers at runtime. Security contexts are defined as part of the Pod and container specifications
in the Pod manifest, and represent parameters to the container runtime.
Security policies are control plane mechanisms to enforce specific settings in the Security Context,
as well as other parameters outside the Security Contex. As of February 2020, the current native
solution for enforcing these security policies is [Pod Security
Policy](/docs/concepts/policy/pod-security-policy/) - a mechanism for centrally enforcing security
policy on Pods across a cluster. Other alternatives for enforcing security policy are being
developed in the Kubernetes ecosystem, such as [OPA
Gatekeeper](https://github.com/open-policy-agent/gatekeeper).
### What profiles should I apply to my Windows Pods?
Windows in Kubernetes has some limitations and differentiators from standard Linux-based
workloads. Specifically, the Pod SecurityContext fields [have no effect on
Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext). As
such, no standardized Pod Security profiles currently exists.
### What about sandboxed Pods?
There is not currently an API standard that controls whether a Pod is considered sandboxed or
not. Sandbox Pods may be identified by the use of a sandboxed runtime (such as gVisor or Kata
Containers), but there is no standard definition of what a sandboxed runtime is.
The protections necessary for sandboxed workloads can differ from others. For example, the need to
restrict privileged permissions is lessened when the workload is isolated from the underlying
kernel. This allows for workloads requiring heightened permissions to still be isolated.
Additionally, the protection of sandboxed workloads is highly dependent on the method of
sandboxing. As such, no single ‘recommended’ policy is recommended for all sandboxed workloads.
{{% /capture %}}
content/en/docs/concepts/services-networking/connect-applications-service.md
+1 -1
View File
@@ -19,7 +19,7 @@ By default, Docker uses host-private networking, so containers can talk to other
Coordinating port allocations across multiple developers or teams that provide containers is very difficult to do at scale, and exposes users to cluster-level issues outside of their control. Kubernetes assumes that pods can communicate with other pods, regardless of which host they land on. Kubernetes gives every pod its own cluster-private IP address, so you do not need to explicitly create links between pods or map container ports to host ports. This means that containers within a Pod can all reach each other's ports on localhost, and all pods in a cluster can see each other without NAT. The rest of this document elaborates on how you can run reliable services on such a networking model.
This guide uses a simple nginx server to demonstrate proof of concept. The same principles are embodied in a more complete [Jenkins CI application](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes).
This guide uses a simple nginx server to demonstrate proof of concept.
{{% /capture %}}
content/en/docs/concepts/services-networking/dns-pod-service.md
+1 -1
View File
@@ -254,7 +254,7 @@ options ndots:5
### Feature availability
The availability of Pod DNS Config and DNS Policy "`None`"" is shown as below.
The availability of Pod DNS Config and DNS Policy "`None`" is shown as below.
| k8s version | Feature support |
| :---------: |:-----------:|
content/en/docs/concepts/workloads/controllers/daemonset.md
+1 -1
View File
@@ -125,7 +125,7 @@ That introduces the following issues:
scheduler instead of the DaemonSet controller, by adding the `NodeAffinity` term
to the DaemonSet pods, instead of the `.spec.nodeName` term. The default
scheduler is then used to bind the pod to the target host. If node affinity of
the DaemonSet pod already exists, it is replaced. The DaemonSet controller only
the DaemonSet pod already exists, it is replaced (the original node affinity was taken into account before selecting the target host). The DaemonSet controller only
performs these operations when creating or modifying DaemonSet pods, and no
changes are made to the `spec.template` of the DaemonSet.
content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md
+1 -1
View File
@@ -472,7 +472,7 @@ starts a Spark master controller (see [spark example](https://github.com/kuberne
driver, and then cleans up.
An advantage of this approach is that the overall process gets the completion guarantee of a Job
object, but complete control over what Pods are created and how work is assigned to them.
object, but maintains complete control over what Pods are created and how work is assigned to them.
## Cron Jobs {#cron-jobs}
content/en/docs/reference/access-authn-authz/rbac.md
+25 -25
View File
@@ -1079,37 +1079,37 @@ In order from most secure to least secure, the approaches are:
2. Grant a role to the "default" service account in a namespace
If an application does not specify a `serviceAccountName`, it uses the "default" service account.
If an application does not specify a `serviceAccountName`, it uses the "default" service account.
{{< note >}}
Permissions given to the "default" service account are available to any pod
in the namespace that does not specify a `serviceAccountName`.
{{< /note >}}
{{< note >}}
Permissions given to the "default" service account are available to any pod
in the namespace that does not specify a `serviceAccountName`.
{{< /note >}}
For example, grant read-only permission within "my-namespace" to the "default" service account:
For example, grant read-only permission within "my-namespace" to the "default" service account:
```shell
kubectl create rolebinding default-view \
--clusterrole=view \
--serviceaccount=my-namespace:default \
--namespace=my-namespace
```
```shell
kubectl create rolebinding default-view \
--clusterrole=view \
--serviceaccount=my-namespace:default \
--namespace=my-namespace
```
Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the
"default" service account in the `kube-system` namespace.
To allow those add-ons to run with super-user access, grant cluster-admin
permissions to the "default" service account in the `kube-system` namespace.
Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the
"default" service account in the `kube-system` namespace.
To allow those add-ons to run with super-user access, grant cluster-admin
permissions to the "default" service account in the `kube-system` namespace.
{{< caution >}}
Enabling this means the `kube-system` namespace contains Secrets
that grant super-user access to your cluster's API.
{{< /caution >}}
{{< caution >}}
Enabling this means the `kube-system` namespace contains Secrets
that grant super-user access to your cluster's API.
{{< /caution >}}
```shell
kubectl create clusterrolebinding add-on-cluster-admin \
--clusterrole=cluster-admin \
--serviceaccount=kube-system:default
```
```shell
kubectl create clusterrolebinding add-on-cluster-admin \
--clusterrole=cluster-admin \
--serviceaccount=kube-system:default
```
3. Grant a role to all service accounts in a namespace
content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
+1 -1
View File
@@ -119,7 +119,7 @@ track=stable
- **CPU requirement (cores)** and **Memory requirement (MiB)**: You can specify the minimum [resource limits](/docs/tasks/configure-pod-container/limit-range/) for the container. By default, Pods run with unbounded CPU and memory limits.
- **Run command** and **Run command arguments**: By default, your containers run the specified Docker image's default [entrypoint command](/docs/user-guide/containers/#containers-and-commands). You can use the command options and arguments to override the default.
- **Run command** and **Run command arguments**: By default, your containers run the specified Docker image's default [entrypoint command](/docs/tasks/inject-data-application/define-command-argument-container/). You can use the command options and arguments to override the default.
- **Run as privileged**: This setting determines whether processes in [privileged containers](/docs/user-guide/pods/#privileged-mode-for-pod-containers) are equivalent to processes running as root on the host. Privileged containers can make use of capabilities like manipulating the network stack and accessing devices.
content/en/docs/tutorials/hello-minikube.md
+6 -2
View File
@@ -47,7 +47,9 @@ This tutorial provides a container image that uses NGINX to echo back all the re
{{< kat-button >}}
{{< note >}}If you installed Minikube locally, run `minikube start`.{{< /note >}}
{{< note >}}
If you installed Minikube locally, run `minikube start`.
{{< /note >}}
2. Open the Kubernetes dashboard in a browser:
@@ -113,7 +115,9 @@ Pod runs a Container based on the provided Docker image.
kubectl config view
```
{{< note >}}For more information about `kubectl`commands, see the [kubectl overview](/docs/user-guide/kubectl-overview/).{{< /note >}}
{{< note >}}
For more information about `kubectl`commands, see the [kubectl overview](/docs/user-guide/kubectl-overview/).
{{< /note >}}
## Create a Service