Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.6
* 'master' of https://github.com/kubernetes/kubernetes.github.io: networkpolicies.md --> network-policies.md for SEO Added link (#4161) Use "sudo -i" instead of "sudo su -" Create a section for kubeadm topics Consolidate SecurityContext topics. (#4005) Typo fix in "Adding ConfigMap data to a Volume" section (#3966)
This commit is contained in:
Andrew Chen
+1
-3
@@ -60,7 +60,7 @@ toc:
|
||||
- docs/concepts/services-networking/dns-pod-service.md
|
||||
- docs/concepts/services-networking/connect-applications-service.md
|
||||
- docs/concepts/services-networking/ingress.md
|
||||
- docs/concepts/services-networking/networkpolicies.md
|
||||
- docs/concepts/services-networking/network-policies.md
|
||||
|
||||
- title: Storage
|
||||
section:
|
||||
@@ -84,9 +84,7 @@ toc:
|
||||
- docs/concepts/cluster-administration/proxies.md
|
||||
- title: Policies
|
||||
section:
|
||||
- docs/concepts/policy/container-capabilities.md
|
||||
- docs/concepts/policy/resource-quotas.md
|
||||
- docs/concepts/policy/security-context.md
|
||||
- docs/concepts/policy/pod-security-policy.md
|
||||
|
||||
|
||||
|
||||
+6
-2
@@ -7,8 +7,12 @@ toc:
|
||||
- title: Independent Solutions
|
||||
section:
|
||||
- docs/getting-started-guides/minikube.md
|
||||
- docs/setup/independent/install-kubeadm.md
|
||||
- docs/setup/independent/create-cluster-kubeadm.md
|
||||
|
||||
- title: Bootstrapping Clusters with kubeadm
|
||||
section:
|
||||
- docs/setup/independent/install-kubeadm.md
|
||||
- docs/setup/independent/create-cluster-kubeadm.md
|
||||
|
||||
- docs/getting-started-guides/scratch.md
|
||||
- docs/getting-started-guides/alternatives.md
|
||||
|
||||
|
||||
@@ -15,6 +15,9 @@ toc:
|
||||
- docs/tasks/configure-pod-container/configure-volume-storage.md
|
||||
- docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
|
||||
- docs/tasks/configure-pod-container/configure-projected-volume-storage.md
|
||||
- docs/tasks/configure-pod-container/projected-volume.md
|
||||
- docs/tasks/configure-pod-container/security-context.md
|
||||
- docs/tasks/configure-pod-container/environment-variable-expose-pod-information.md
|
||||
- docs/tasks/configure-pod-container/configure-service-account.md
|
||||
- docs/tasks/configure-pod-container/pull-image-private-registry.md
|
||||
- docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md
|
||||
|
||||
@@ -20,7 +20,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
|
||||
* [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported.
|
||||
* [Contiv](http://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](http://github.com/contiv). The [installer](http://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
|
||||
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) is an overlay network provider that can be used with Kubernetes.
|
||||
* [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/networkpolicies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
|
||||
* [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
|
||||
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Flannel, Calico, Canal, Romana, or Weave.
|
||||
|
||||
|
||||
@@ -213,7 +213,7 @@ Calico can also be run in policy enforcement mode in conjunction with other netw
|
||||
|
||||
### Romana
|
||||
|
||||
[Romana](http://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/networkpolicies/) to provide isolation across network namespaces.
|
||||
[Romana](http://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces.
|
||||
|
||||
### Weave Net from Weaveworks
|
||||
|
||||
|
||||
@@ -1,102 +0,0 @@
|
||||
---
|
||||
title: Container Capabilities
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
You can specify Container capabilities by using the `securityContext` field of a
|
||||
Container's configuration.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture body %}
|
||||
|
||||
## Capabilities
|
||||
|
||||
By default, Docker containers are unprivileged. For example, in the default case,
|
||||
you cannot run a Docker daemon inside a Docker container. To give you control
|
||||
over a container's capabilities, Docker supports `cap-add`
|
||||
and `cap-drop`. For more details, see
|
||||
[Runtime privilege and Linux capabilities](https://docs.docker.com/engine/reference/run/#/runtime-privilege-and-linux-capabilities).
|
||||
|
||||
This table shows the relationship between Docker capabilities and
|
||||
[Linux capabilities](http://man7.org/linux/man-pages/man7/capabilities.7.html):
|
||||
|
||||
| Docker's capabilities | Linux capabilities |
|
||||
| ---- | ---- |
|
||||
| SETPCAP | CAP_SETPCAP |
|
||||
| SYS_MODULE | CAP_SYS_MODULE |
|
||||
| SYS_RAWIO | CAP_SYS_RAWIO |
|
||||
| SYS_PACCT | CAP_SYS_PACCT |
|
||||
| SYS_ADMIN | CAP_SYS_ADMIN |
|
||||
| SYS_NICE | CAP_SYS_NICE |
|
||||
| SYS_RESOURCE | CAP_SYS_RESOURCE |
|
||||
| SYS_TIME | CAP_SYS_TIME |
|
||||
| SYS_TTY_CONFIG | CAP_SYS_TTY_CONFIG |
|
||||
| MKNOD | CAP_MKNOD |
|
||||
| AUDIT_WRITE | CAP_AUDIT_WRITE |
|
||||
| AUDIT_CONTROL | CAP_AUDIT_CONTROL |
|
||||
| MAC_OVERRIDE | CAP_MAC_OVERRIDE |
|
||||
| MAC_ADMIN | CAP_MAC_ADMIN |
|
||||
| NET_ADMIN | CAP_NET_ADMIN |
|
||||
| SYSLOG | CAP_SYSLOG |
|
||||
| CHOWN | CAP_CHOWN |
|
||||
| NET_RAW | CAP_NET_RAW |
|
||||
| DAC_OVERRIDE | CAP_DAC_OVERRIDE |
|
||||
| FOWNER | CAP_FOWNER |
|
||||
| DAC_READ_SEARCH | CAP_DAC_READ_SEARCH |
|
||||
| FSETID | CAP_FSETID |
|
||||
| KILL | CAP_KILL |
|
||||
| SETGID | CAP_SETGID |
|
||||
| SETUID | CAP_SETUID |
|
||||
| LINUX_IMMUTABLE | CAP_LINUX_IMMUTABLE |
|
||||
| NET_BIND_SERVICE | CAP_NET_BIND_SERVICE |
|
||||
| NET_BROADCAST | CAP_NET_BROADCAST |
|
||||
| IPC_LOCK | CAP_IPC_LOCK |
|
||||
| IPC_OWNER | CAP_IPC_OWNER |
|
||||
| SYS_CHROOT | CAP_SYS_CHROOT |
|
||||
| SYS_PTRACE | CAP_SYS_PTRACE |
|
||||
| SYS_BOOT | CAP_SYS_BOOT |
|
||||
| LEASE | CAP_LEASE |
|
||||
| SETFCAP | CAP_SETFCAP |
|
||||
| WAKE_ALARM | CAP_WAKE_ALARM |
|
||||
| BLOCK_SUSPEND | CAP_BLOCK_SUSPEND |
|
||||
|
||||
In Kubernetes, you can add or drop capabilities in the
|
||||
[`SecurityContext`](/docs/resources-reference/v1.6/#securitycontext-v1-core)
|
||||
field of a Container:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: hello-world
|
||||
spec:
|
||||
containers:
|
||||
- name: friendly-container
|
||||
image: "alpine:3.4"
|
||||
command: ["/bin/echo", "hello", "world"]
|
||||
securityContext:
|
||||
capabilities:
|
||||
add:
|
||||
- SYS_NICE
|
||||
drop:
|
||||
- KILL
|
||||
```
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
* [Security Context](/docs/concepts/policy/security-context/)
|
||||
|
||||
* [Pod Security Policy](/docs/concepts/policy/pod-security-policy/)
|
||||
|
||||
* [SecurityContext](/docs/resources-reference/v1.6/#securitycontext-v1-core)
|
||||
|
||||
* [Container](/docs/api-reference/v1.6/#container-v1-core)
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/concept.md %}
|
||||
|
||||
@@ -1,90 +0,0 @@
|
||||
---
|
||||
assignees:
|
||||
- erictune
|
||||
- mikedanese
|
||||
- thockin
|
||||
title: Security Context
|
||||
redirect_from:
|
||||
- "/docs/user-guide/security-context/"
|
||||
- "/docs/user-guide/security-context.html"
|
||||
---
|
||||
|
||||
A security context defines the operating system security settings (uid, gid, capabilities, SELinux role, etc..) applied to a container. See [security context design](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/security_context.md) for more details.
|
||||
|
||||
There are two levels of security context: pod level security context, and container level security context.
|
||||
|
||||
## Pod Level Security Context
|
||||
Setting security context at the pod applies those settings to all containers in the pod
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: hello-world
|
||||
spec:
|
||||
containers:
|
||||
# specification of the pod's containers
|
||||
# ...
|
||||
securityContext:
|
||||
fsGroup: 1234
|
||||
supplementalGroups: [5678]
|
||||
seLinuxOptions:
|
||||
level: "s0:c123,c456"
|
||||
```
|
||||
|
||||
Please refer to the [API documentation](https://kubernetes.io/docs/api-reference/v1.6/#podsecuritycontext-v1-core) for a detailed listing and
|
||||
description of all the fields available within the pod security
|
||||
context.
|
||||
|
||||
### Volume Security context
|
||||
|
||||
Another functionality of pod level security context is that it applies
|
||||
those settings to volumes where applicable. Specifically `fsGroup` and
|
||||
`seLinuxOptions` are applied to the volume as follows:
|
||||
|
||||
#### `fsGroup`
|
||||
|
||||
Volumes which support ownership management are modified to be owned
|
||||
and writable by the GID specified in `fsGroup`. See the
|
||||
[Ownership Management design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/volume-ownership-management.md)
|
||||
for more details.
|
||||
|
||||
#### `selinuxOptions`
|
||||
|
||||
Volumes which support SELinux labeling are relabeled to be accessible
|
||||
by the label specified unders `seLinuxOptions`. Usually you will only
|
||||
need to set the `level` section. This sets the SELinux MCS label given
|
||||
to all containers within the pod as well as the volume.
|
||||
|
||||
**Attention**: Once the MCS label is specified in the pod description
|
||||
all pods with the same label will able to access the
|
||||
volume. So if interpod protection is needed you must ensure each pod
|
||||
is assigned a unique MCS label.
|
||||
|
||||
## Container Level Security Context
|
||||
|
||||
Container level security context settings are applied to the specific
|
||||
container and override settings made at the pod level where there is
|
||||
overlap. Container level settings however do not affect the pod's
|
||||
volumes.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: hello-world
|
||||
spec:
|
||||
containers:
|
||||
- name: hello-world-container
|
||||
# The container definition
|
||||
# ...
|
||||
securityContext:
|
||||
privileged: true
|
||||
seLinuxOptions:
|
||||
level: "s0:c123,c456"
|
||||
```
|
||||
|
||||
Please refer to the
|
||||
[API documentation](/docs/api-reference/v1.6/#securitycontext-v1-core)
|
||||
for a detailed listing and description of all the fields available
|
||||
within the container security context.
|
||||
@@ -130,7 +130,7 @@ Also, you need to pick a static IP for master node.
|
||||
|
||||
#### Network Policy
|
||||
|
||||
Kubernetes enables the definition of fine-grained network policy between Pods using the [NetworkPolicy](/docs/concepts/services-networking/networkpolicies/) resource.
|
||||
Kubernetes enables the definition of fine-grained network policy between Pods using the [NetworkPolicy](/docs/concepts/services-networking/network-policies/) resource.
|
||||
|
||||
Not all networking providers support the Kubernetes NetworkPolicy API, see [Using Network Policy](/docs/tasks/configure-pod-container/declare-network-policy/) for more information.
|
||||
|
||||
|
||||
@@ -50,7 +50,7 @@ releases](https://github.com/kubernetes/kubeadm/blob/master/CHANGELOG.md)
|
||||
For each machine:
|
||||
|
||||
* SSH into the machine and become root if you are not already (for example,
|
||||
run `sudo su -`).
|
||||
run `sudo -i`).
|
||||
|
||||
* If the machine is running Ubuntu or HypriotOS, run:
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ redirect_from:
|
||||
- "/docs/tasks/configure-pod-container/declare-network-policy.html"
|
||||
---
|
||||
{% capture overview %}
|
||||
This document helps you get started using using the Kubernetes [NetworkPolicy API](/docs/user-guide/networkpolicies) to declare network policies that govern how pods communicate with each other.
|
||||
This document helps you get started using using the Kubernetes [NetworkPolicy API](/docs/user-guide/network-policies) to declare network policies that govern how pods communicate with each other.
|
||||
{% endcapture %}
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
@@ -202,7 +202,7 @@ data:
|
||||
### Populate a Volume with data stored in a ConfigMap
|
||||
|
||||
Add the ConfigMap name under the `volumes` section of the Pod specification.
|
||||
This adds the ConfigMap data to the directory specified as `volumeMount.mountPath` (in this case, `/etc/config`).
|
||||
This adds the ConfigMap data to the directory specified as `volumeMounts.mountPath` (in this case, `/etc/config`).
|
||||
The `command` section references the `special.level` item stored in the ConfigMap.
|
||||
|
||||
```yaml
|
||||
|
||||
@@ -84,6 +84,7 @@ The output shows that nginx is serving the web page that was written by the init
|
||||
[communicating between Containers running in the same Pod](/docs/tasks/configure-pod-container/communicate-containers-same-pod/).
|
||||
* Learn more about [Init Containers](/docs/concepts/workloads/pods/init-containers/).
|
||||
* Learn more about [Volumes](/docs/concepts/storage/volumes/).
|
||||
* Learn more about [Debugging Init Containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: security-context-demo-2
|
||||
spec:
|
||||
securityContext:
|
||||
runAsUser: 1000
|
||||
containers:
|
||||
- name: sec-ctx-demo-2
|
||||
image: gcr.io/google-samples/node-hello:1.0
|
||||
securityContext:
|
||||
runAsUser: 2000
|
||||
@@ -0,0 +1,11 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: security-context-demo-3
|
||||
spec:
|
||||
containers:
|
||||
- name: sec-ctx-3
|
||||
image: gcr.io/google-samples/node-hello:1.0
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: security-context-demo-4
|
||||
spec:
|
||||
containers:
|
||||
- name: sec-ctx-4
|
||||
image: gcr.io/google-samples/node-hello:1.0
|
||||
securityContext:
|
||||
capabilities:
|
||||
add: ["NET_ADMIN", "SYS_TIME"]
|
||||
@@ -0,0 +1,359 @@
|
||||
---
|
||||
assignees:
|
||||
- erictune
|
||||
- mikedanese
|
||||
- thockin
|
||||
title: Configure a Security Context for a Pod or Container
|
||||
redirect_from:
|
||||
- "/docs/user-guide/security-context/"
|
||||
- "/docs/concepts/policy/container-capabilities/"
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
A security context defines privilege and access control settings for
|
||||
a Pod or Container. Security context settings include:
|
||||
|
||||
* Discretionary Access Control: Permission to access an object, like a file, is based on
|
||||
[user ID (UID) and group ID (GID)](https://wiki.archlinux.org/index.php/users_and_groups).
|
||||
|
||||
* [Security Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux): Objects are assigned security labels.
|
||||
|
||||
* Running as privileged or unprivileged.
|
||||
|
||||
* [Linux Capabilities](https://linux-audit.com/linux-capabilities-hardening-linux-binaries-by-removing-setuid/): Give a process some privileges, but not all the privileges of the root user.
|
||||
|
||||
* [AppArmor](/docs/tutorials/clusters/apparmor/): Use program profiles to restrict the capabilities of individual programs.
|
||||
|
||||
* [Seacomp](https://en.wikipedia.org/wiki/Seccomp): Limit a process's access to open file descriptors.
|
||||
|
||||
For more information about security mechanisms in Linux, see
|
||||
[Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features)
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
{% include task-tutorial-prereqs.md %}
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture steps %}
|
||||
|
||||
## Set the security context for a Pod
|
||||
|
||||
To specify security settings for a Pod, include the `securityContext` field
|
||||
in the Pod specification. The `securityContext` field is a
|
||||
[PodSecurityContext](/docs/api-reference/v1.6/#podsecuritycontext-v1-core) object.
|
||||
The security settings that you specify for a Pod apply to all Containers in the Pod.
|
||||
Here is a configuration file for a Pod that has a `securityContext` and an `emptyDir` volume:
|
||||
|
||||
{% include code.html language="yaml" file="security-context.yaml" ghlink="/docs/tasks/configure-pod-container/security-context.yaml" %}
|
||||
|
||||
In the configuration file, the `runAsUser` field specifies that for any Containers in
|
||||
the Pod, the first process runs with user ID 1000. The `fsGroup` field specifies that
|
||||
group ID 2000 is associated with all Containers in the Pod. Group ID 2000 is also
|
||||
associated with the volume mounted at `/data/demo` and with any files created in that
|
||||
volume.
|
||||
|
||||
Create the Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/security-context.yaml
|
||||
```
|
||||
|
||||
Verify that the Pod's Container is running:
|
||||
|
||||
```shell
|
||||
kubectl get pod security-context-demo
|
||||
```
|
||||
|
||||
Get a shell to the running Container:
|
||||
|
||||
```shell
|
||||
kubectl exec -it security-context-demo -- sh
|
||||
```
|
||||
|
||||
In your shell, list the running processes:
|
||||
|
||||
```shell
|
||||
ps aux
|
||||
```
|
||||
|
||||
The output shows that the processes are running as user 1000, which isithub.io
|
||||
68dc8932..69f5ba31 qos-experiment -> qos-experi
|
||||
the value of `runAsUser`:
|
||||
|
||||
```shell
|
||||
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
|
||||
1000 1 0.0 0.0 4336 724 ? Ss 18:16 0:00 /bin/sh -c node server.js
|
||||
1000 5 0.2 0.6 772124 22768 ? Sl 18:16 0:00 node server.js
|
||||
...
|
||||
```
|
||||
|
||||
In your shell, navigate to `/data`, and list the one directory:
|
||||
|
||||
```shell
|
||||
cd /data
|
||||
ls -l
|
||||
```
|
||||
|
||||
The output shows that the `/data/demo` directory has group ID 2000, which is
|
||||
the value of `fsGroup`.
|
||||
|
||||
```shell
|
||||
drwxrwsrwx 2 root 2000 4096 Jun 6 20:08 demo
|
||||
```
|
||||
|
||||
In your shell, navigate to `/data/demo`, and create a file:
|
||||
|
||||
```shell
|
||||
cd demo
|
||||
echo hello > testfile
|
||||
```
|
||||
|
||||
List the file in the `/data/demo` directory:
|
||||
|
||||
```shell
|
||||
ls -l
|
||||
```
|
||||
|
||||
The output shows that `testfile` has group ID 2000, which is the value of `fsGroup`.
|
||||
|
||||
```shell
|
||||
-rw-r--r-- 1 1000 2000 6 Jun 6 20:08 testfile
|
||||
```
|
||||
|
||||
Exit your shell:
|
||||
|
||||
```shell
|
||||
exit
|
||||
```
|
||||
|
||||
## Set the security context for a Container
|
||||
|
||||
To specify security settings for a Container, include the `securityContext` field
|
||||
in the Container manifest. The `securityContext` field is a
|
||||
[SecurityContext](/docs/api-reference/v1.6/#securitycontext-v1-core) object.
|
||||
Security settings that you specify for a Container apply only to
|
||||
the individual Container, and they override settings made at the Pod level when
|
||||
there is overlap. Container settings do not affect the Pod's Volumes.
|
||||
|
||||
Here is the configuration file for a Pod that has one Container. Both the Pod
|
||||
and the Container have a `securityContext` field:
|
||||
|
||||
{% include code.html language="yaml" file="security-context-2.yaml" ghlink="/docs/tasks/configure-pod-container/security-context-2.yaml" %}
|
||||
|
||||
Create the Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/security-context-2.yaml
|
||||
```
|
||||
|
||||
Verify that the Pod's Container is running:
|
||||
|
||||
```shell
|
||||
kubectl get pod security-context-demo-2
|
||||
```
|
||||
|
||||
Get a shell into the running Container:
|
||||
|
||||
```shell
|
||||
kubectl exec -it security-context-demo-2 -- sh
|
||||
```
|
||||
|
||||
In your shell, list the running processes:
|
||||
|
||||
```
|
||||
ps aux
|
||||
```
|
||||
|
||||
The output shows that the processes are running as user 2000. This is the value
|
||||
of `runAsUser` specified for the Container. It overrides the value 1000 that is
|
||||
specified for the Pod.
|
||||
|
||||
```
|
||||
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
|
||||
2000 1 0.0 0.0 4336 764 ? Ss 20:36 0:00 /bin/sh -c node server.js
|
||||
2000 8 0.1 0.5 772124 22604 ? Sl 20:36 0:00 node server.js
|
||||
...
|
||||
```
|
||||
|
||||
Exit your shell:
|
||||
|
||||
```shell
|
||||
exit
|
||||
```
|
||||
|
||||
## Set capabilities for a Container
|
||||
|
||||
With [Linux capabilities](http://man7.org/linux/man-pages/man7/capabilities.7.html),
|
||||
you can grant certain privileges to a process without granting all the privileges
|
||||
of the root user. To add or remove Linux capabilities for a Container, include the
|
||||
`capabilities` field in the `securityContext` section of the Container manifest.
|
||||
|
||||
First, see what happens when you don't include a `capabilities` field.
|
||||
Here is configuration file that does not add or remove any Container capabilities:
|
||||
|
||||
{% include code.html language="yaml" file="security-context-3.yaml" ghlink="/docs/tasks/configure-pod-container/security-context-3.yaml" %}
|
||||
|
||||
Create the Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/security-context-3.yaml
|
||||
```
|
||||
|
||||
Verify that the Pod's Container is running:
|
||||
|
||||
```shell
|
||||
kubectl get pod security-context-demo-3
|
||||
```
|
||||
|
||||
Get a shell into the running Container:
|
||||
|
||||
```shell
|
||||
kubectl exec -it security-context-demo-3 -- sh
|
||||
```
|
||||
|
||||
In your shell, list the running processes:
|
||||
|
||||
```shell
|
||||
ps aux
|
||||
```
|
||||
|
||||
The output shows the process IDs (PIDs) for the Container:
|
||||
|
||||
```shell
|
||||
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
|
||||
root 1 0.0 0.0 4336 796 ? Ss 18:17 0:00 /bin/sh -c node server.js
|
||||
root 5 0.1 0.5 772124 22700 ? Sl 18:17 0:00 node server.js
|
||||
```
|
||||
|
||||
In your shell, view the status for process 1:
|
||||
|
||||
```shell
|
||||
cd /proc/1
|
||||
cat status
|
||||
```
|
||||
|
||||
The output shows the capabilities bitmap for the process:
|
||||
|
||||
```
|
||||
...
|
||||
CapPrm: 00000000a80425fb
|
||||
CapEff: 00000000a80425fb
|
||||
...
|
||||
```
|
||||
|
||||
Make a note of the capabilities bitmap, and then exit your shell:
|
||||
|
||||
```shell
|
||||
exit
|
||||
```
|
||||
|
||||
Next, run a Container that is the same as the preceding container, except
|
||||
that it has additional capabilities set.
|
||||
|
||||
Here is the configuration file for a Pod that runs one Container. The configuration
|
||||
adds the `CAP_NET_ADMIN` and `CAP_SYS_TIME` capabilities:
|
||||
|
||||
{% include code.html language="yaml" file="security-context-4.yaml" ghlink="/docs/tasks/configure-pod-container/security-context-4.yaml" %}
|
||||
|
||||
Create the Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/security-context-4.yaml
|
||||
```
|
||||
|
||||
Get a shell into the running Container:
|
||||
|
||||
```shell
|
||||
kubectl exec -it security-context-demo-4 -- sh
|
||||
```
|
||||
|
||||
In your shell, view the capabilities for process 1:
|
||||
|
||||
```shell
|
||||
cd /proc/1
|
||||
cat status
|
||||
```
|
||||
|
||||
The output shows capabilities bitmap for the process:
|
||||
|
||||
```shell
|
||||
...
|
||||
CapPrm: 00000000aa0435fb
|
||||
CapEff: 00000000aa0435fb
|
||||
...
|
||||
```
|
||||
|
||||
Compare the capabilities of the two Containers:
|
||||
|
||||
```
|
||||
00000000a80425fb
|
||||
00000000aa0435fb
|
||||
```
|
||||
|
||||
In the capability bitmap of the first container, bits 12 and 25 are clear. In the second container,
|
||||
bits 12 and 25 are set. Bit 12 is `CAP_NET_ADMIN`, and bit 25 is `CAP_SYS_TIME`.
|
||||
See [capability.h](https://github.com/torvalds/linux/blob/master/include/uapi/linux/capability.h)
|
||||
for definitions of the capability constants.
|
||||
|
||||
**Note**: Linux capability constants have the form `CAP_XXX`. But when you list capabilities
|
||||
in your Container manifest, you must omit the `CAP_` portion of the constant. For example,
|
||||
to add `CAP_SYS_TIME`, include `SYS_TIME` in your list of capabilities.
|
||||
|
||||
## Assign SELinux labels to a Container
|
||||
|
||||
To assign SELinux labels to a Container, include the `seLinuxOptions` field in
|
||||
the `securityContext` section of your Pod or Container manifest. The
|
||||
`seLinuxOptions` field is an
|
||||
[SELinuxOptions](/docs/api-reference/v1.6/#selinuxoptions-v1-core)
|
||||
object. Here's an example that applies an SELinux level:
|
||||
|
||||
```yaml
|
||||
...
|
||||
securityContext:
|
||||
seLinuxOptions:
|
||||
level: "s0:c123,c456"
|
||||
```
|
||||
|
||||
**Note**: To assign SELinux labels, the SELinux security module must be loaded
|
||||
on the host operating system.
|
||||
|
||||
## Discussion
|
||||
|
||||
The security context for a Pod applies to the Pod's Containers and also to
|
||||
the Pod's Volumes when applicable. Specifically `fsGroup` and `seLinuxOptions` are
|
||||
applied to Volumes as follows:
|
||||
|
||||
* `fsGroup`: Volumes that support ownership management are modified to be owned
|
||||
and writable by the GID specified in `fsGroup`. See the
|
||||
[Ownership Management design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/volume-ownership-management.md)
|
||||
for more details.
|
||||
|
||||
* `seLinuxOptions`: Volumes that support SELinux labeling are relabeled to be accessible
|
||||
by the label specified under `seLinuxOptions`. Usually you only
|
||||
need to set the `level` section. This sets the
|
||||
[Multi-Category Security (MCS)](https://selinuxproject.org/page/NB_MLS)
|
||||
label given to all Containers in the Pod as well as the Volumes.
|
||||
|
||||
**Warning**: After you specify an MCS label for a Pod, all Pods with the same
|
||||
label will able to access the Volume. So if you need inter-Pod
|
||||
protection, you must ensure each Pod is assigned a unique MCS label.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
* [PodSecurityContext](/docs/api-reference/v1.6/#podsecuritycontext-v1-core)
|
||||
* [SecurityContext](/docs/api-reference/v1.6/#securitycontext-v1-core)
|
||||
* [Tuning Docker with the newest security enhancements](https://opensource.com/business/15/3/docker-security-tuning)
|
||||
* [Security Contexts design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/security_context.md)
|
||||
* [Ownership Management design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/volume-ownership-management.md)
|
||||
* [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)
|
||||
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/task.md %}
|
||||
@@ -0,0 +1,17 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: security-context-demo
|
||||
spec:
|
||||
securityContext:
|
||||
runAsUser: 1000
|
||||
fsGroup: 2000
|
||||
volumes:
|
||||
- name: sec-ctx-vol
|
||||
emptyDir: {}
|
||||
containers:
|
||||
- name: sec-ctx-demo
|
||||
image: gcr.io/google-samples/node-hello:1.0
|
||||
volumeMounts:
|
||||
- name: sec-ctx-vol
|
||||
mountPath: /data/demo
|
||||
@@ -76,6 +76,10 @@ $( document ).ready(function() {
|
||||
{
|
||||
"from": "/docs/troubleshooting/",
|
||||
"to": "/docs/tasks/debug-application-cluster/troubleshooting/"
|
||||
},
|
||||
{
|
||||
"from": "/docs/concepts/services-networking/networkpolicies/",
|
||||
"to": "/docs/concepts/services-networking/network-policies/"
|
||||
}];
|
||||
|
||||
forwardingRules.forEach(function(rule) {
|
||||
|
||||
Reference in New Issue
Block a user