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

Consolidate SecurityContext topics. (#4005)

Browse Source
This commit is contained in:
Steve Perry
2017-06-21 18:12:44 -07:00
committed by GitHub
parent 0c6b381b7c
commit 9da5890274
9 changed files with 413 additions and 194 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/policy/container-capabilities.md
-102
View File
@@ -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 %}
docs/concepts/policy/security-context.md
-90
View File
@@ -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.