Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.7
* '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
@@ -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.
|
||||
Reference in New Issue
Block a user