foreword
k8s itself is not responsible for the definition and implementation of containers. Kubernetes implements container management by using container runtime interfaces, and container implementation is achieved through container runtimes (such as Docker, CRI-O, etc.).
Difference between non-root container and default container
The default inside the container is to execute instructions as the root user, which means that the application has the highest execution authority inside the container where it is located. The program can modify the system files inside the container, access confidential information, and install the system at runtime. Package, you can also bind any port below 1024.
The emergence of non-root containers is to prevent these unsafe behaviors. After the non-root container is started, it can no longer be transformed into a root container. The application can only run in a specific user role, which can prevent malicious code from obtaining the highest execution authority.
Pros/Cons of non-root containers
Advantages: 1. Security, some k8s distributions such as Openshift require the use of non-root containers.
Disadvantage: The application may not be able to access or create certain files and directories due to insufficient permissions. Such as mysql, git and other applications.
How to work around the limitations of non-root containers
If the application must use root privileges to do something, but wants to use a non-root container to run, then the following options can be considered:
- Use initContainers. initContainers are special containers that can be run before other containers in a Pod are started to initialize the environment required by the container.
- Modify the Dockerfile, and switch back to the specified user after completing the work as the root user in the Dockerfile.
- Modify the file permissions that need to be accessed at runtime in the Dockerfile (not recommended)
- When using a mounted volume, modify parameters such as UID to set the owner of the mounted volume to the user or group used by the non-root container. This way non-root containers can access the mounted volume as their own user.
How to create a non-root container
The creation of a non-root container needs to be broken into two parts:
Dockerfile
In the Dockerfile, the default root user can be switched to a specified user by command USER <UID> .
As shown below, the commands after USER 1001 will be executed with the user authority of UID 1001. If the user does not exist, docker will try to create a user with the UID.
It should be noted that Openshift, the Pass platform launched by Red Hat, ignores the user specified in the dockerfile, but uses a random UID, which also means that all containers on Openshift run in non-root mode by default.
FROM bitnami/minideb-extras:jessie-r22
LABEL maintainer "Bitnami <[email protected]>"
ENV BITNAMI_PKG_CHMOD="-R g+rwX"
...
RUN bitnami-pkg unpack nginx-1.12.2-0 --checksum cb54ea083954cddbd3d9a93eeae0b81247176235c966a7b5e70abc3c944d4339
...
USER 1001
ENTRYPOINT ["/app-entrypoint.sh"]
CMD ["nginx","-g","daemon off;"]Kubernetes
In Kubernetes, creating a non-root container requires setting the securityContext in the Pod's container definition. That is, by setting the runAsUser and runAsGroup fields to specify the user and group of the process in the container, a non-root container is created.
At the same time, you also need to use the USER directive in the Dockerfile to set the permissions of files and directories to non-root users and groups, otherwise permission problems may occur when running containers as non-root users.
apiVersion: v1
kind: Pod
metadata:
name: non-root-container-pod
spec:
containers:
- name: non-root-container
image: my-non-root-image
securityContext:
runAsUser: 1000 # 指定非root用户
runAsGroup: 3000 # 指定非root组
reference
Why non-root containers are important for security (bitnami.com)