Security contexts control and manage permissions on processes in containers. Security contexts can restrict the behaviors of processes in containers and ensure that processes in containers can only run within the given permissions and resource limits. This topic describes how to configure a security context and define permissions and access control settings for a pod or container.
Background information
Security contexts define permissions and access control settings for pods or containers. Examples of security context settings include Discretionary Access Control, Security Enhanced Linux (SELinux), and Linux Capabilities. For more information, see Configure a Security Context for a Pod or Container.
Kubernetes provides two methods to configure security contexts:
Pod Security Context
Configure a security context for a pod. The configured security context applies to all the containers and volumes in the pod.
Elastic Container Instance allows you to modify the sysctl and runAsUser parameters by configuring a security context for a pod.
Container Security Context
Configure a security context for a container. The configured security context applies to the container.
Elastic Container Instance allows you to modify the sysctl and runAsUser parameters by configuring a security context for a container.
Kubernetes uses pod security policies to verify and restrict the security contexts of pods. If the security context of a pod to be created does not meet the constraints of the specified pod security policy, the pod cannot be created. For more information, see Pod Security Policies.
If you use Container Service for Kubernetes (ACK), a pod security policy named ack.privileged is used by default. For more information, see Use pod security policies.
Configure a security context for a pod
Configuration description
In a Linux system, you can modify runtime kernel parameters by using the sysctl interface. You can view the kernel parameters of an elastic container instance by running the following command. For more information, see sysctl.sh.
sysctl -aYou can modify the sysctl and runAsUser parameters by configuring a security context for a pod.
To avoid instability in the operating system, you must fully understand the impacts of sysctl parameter modifications before you proceed. For more information, see sysctl.
The following sysctl parameters can be modified in Elastic Container Instance:
kernel.shm * (except kernel.shm_rmid_forced)
kernel.msg*
kernel.sem
fs.mqueue.*
net.* (except net.ipv4.tcp_syncookies)
vm.min_free_kbytes
We recommend that you specify a value for vm.min_free_kbytes that is not greater than 20% of the total memory size.
Configuration example
The following sample YAML file provides how to modify the net.core.somaxconn and kernel.msgmax sysctl parameters by configuring a security context.
apiVersion: v1
kind: Pod
metadata:
name: sysctl-example
labels:
alibabacloud.com/eci: "true"
spec:
securityContext:
sysctls:
- name: net.core.somaxconn
value: "1024"
- name: kernel.msgmax
value: "65536"
containers:
- name: busybox
image: registry.cn-shanghai.aliyuncs.com/eci_open/busybox:1.30
command: [ "sh", "-c", "sleep 12000" ]Configure a security context for a container
Configuration description
You can configure a security context for a specified container.
For common parameters such as runAsUser that you set when you configure a security context for a pod and a security context for a container, the settings in the security context of the container override the settings in the security context of the pod.
The following table describes the parameters supported by Elastic Container Instance.
Parameter | Description |
runAsUser | The ID of the user who runs the container. The parameter settings override the USER command in the Dockerfile. |
runAsGroup | The user group that runs the container. |
runAsNonRoot | Specifies whether the user runs the container as a non-root user. |
capabilities | The permissions that are granted to the processes in the container. For more information, see Linux capabilities. You can configure the following permissions:
Note You cannot grant the SYS_RAWIO permission to processes. To use SYS_RAWIO, submit a ticket. |
The following table describes parameters that are not supported and the default values of the parameters.
Unsupported parameters | Description |
privileged | Specifies whether to run the container in privileged mode. Default value: false. |
AllowedProcMountTypes | The allowed proc mount types for the container. Default value: DefaultProcMount. |
readOnlyRootFilesystem | Species whether the root file system that the container runs is read-only. Default value: true. |
Configuration example
By default, containers do not have the NET_ADMIN permission. If network-related operations are performed in a container, an error message is returned. 
You can configure the security context for the container and specify the capabilities parameter to add the NET_ADMIN permission. The following sample YAML file provides an example on how to add the NET_ADMIN permission by setting the capabilities parameter.
apiVersion: v1
kind: Pod
metadata:
name: sysctl-example
labels:
alibabacloud.com/eci: "true"
spec:
containers:
- name: busybox
image: registry.cn-shanghai.aliyuncs.com/eci_open/busybox:1.30
command: ["sh", "-c", "sleep 12000"]
securityContext:
capabilities:
add: ["NET_ADMIN"] After you re-create a pod, you can perform network-related operations in the container.
