Docker security baselines you must know

This article brings you knowledge about the security baseline in docker, including service configuration and file permissions as well as security audit related issues. I hope it will be helpful to everyone.

Docker Security Baseline

Service Configuration

1. High Risk-Restrict network traffic between containers

Description:

By default, all network communication is allowed between containers on the same host. If not required, restrict all inter-container communication. Chain together specific containers that need to communicate with each other. By default, unrestricted network traffic is enabled between all containers on the same host. Therefore, each container has the potential to read all packets on the entire network of containers on the same host. This can lead to unexpected and unnecessary information leakage to other containers. Therefore, limit inter-container communication.

Reinforcement recommendations:

Run docker in daemon mode and pass **–icc=false** as argument. For example,

/usr/bin/dockerd --icc=false

If you use systemctl to manage the docker service, you need to edit

/ Add the –icc=false

item to the ExecStart parameter in the usr/lib/systemd/system/docker.service

file and then restart the docker service

systemctl daemon-reload
systemctl restart docker

2. High risk - Use of privileged containers is prohibited

Description:

Use the –privileged flag to give all Linux kernel capabilities to the container, thus overriding the –cap-add and –cap-drop flags . Make sure not to use it. The --privileged flag provides all capabilities to the container and also lifts all restrictions enforced by the device's cgroup controller. In other words, containers can do almost everything a host can do. This flag exists to allow special use cases, such as running Docker inside Docker

Hardening recommendations:

Do not run containers with the --privileged flag

3. High risk - Limit the memory usage of containers

Description:

By default, all containers on the Docker host share resources equally. By using the Docker host's resource management features, such as memory limits, you can control the amount of memory a container may consume. By default, containers can use all memory on the host machine. You can use a memory throttling mechanism to prevent denial of service due to one container consuming all of the host's resources, preventing other containers on the same host from performing their intended functions. Having no limit on memory can lead to a problem where one container can easily make the entire system unstable and therefore unusable.

Hardening Recommendations

Use only the required memory to run the container. Always run the container with the --memory parameter. You should start the container as follows: docker run --interactive --tty --memory 256m <Container Image Name or ID>

4. High risk - change the container's The root file system is mounted read-only

Description:

The container's root file system should be considered a "golden image" and any writes to the root file system should be avoided . You should explicitly define the container volume for writing. You should not write data in the container. The amount of data belonging to a container should be clearly defined and managed. This is useful in many situations where administrators control where they want developers to write files and errors.

Hardening recommendations:

Add the "--read-only" flag to allow the container's root file system to be mounted as read-only. This can be used in conjunction with volumes to force a container's processes to only write to locations that are intended to be preserved. You should run the container as follows:

docker run --interactive --tty --read-only --volume <writable-volume> <Container Image Name or ID> <Command>

If you are a container orchestrated by k8s or other container orchestration software, please configure or ignore it according to the corresponding security policy.

5. High Risk - Set Logging Level

Description:

Set the appropriate log level and configure the Docker daemon to log Events you want to view later. Basic log levels of "info" and above will capture all logs except debug logs. You should not run the Docker daemon at the "debug" log level until and unless necessary

Hardening recommendations:

Run the Docker daemon as follows:

dockerd --log-level=info

If you use systemctl to manage the docker service, you need to edit the ExecStart parameter of /usr/lib/systemd/system/docker.service and add --log-level="info", and restart docker

systemctl stop docker
systemctl start docker

6. High risk - Allow Docker to make changes to iptables

Description:

iptables is used to set up, maintain and inspect in the Linux kernel IP packet filter rule table. Allow the Docker daemon to make changes to iptables. If you choose to do this, Docker will never make changes to your system iptables rules. If allowed, the Docker server will automatically make the required changes to iptables based on how you select network options for the container. It is recommended to let the Docker server automatically make changes to iptables to avoid network misconfigurations, which may hinder communication between containers and with the outside world. Additionally, it avoids the hassle of updating iptables every time you choose to run a container or modify network options.

Reinforcement suggestions:

不使用’–iptables = false’参数运行Docker守护程序。 若以systemctl管理docker服务则需要编辑/usr/lib/systemd/system/docker.service的ExecStart参数删除--iptables = false， 重启docker服务

systemctl daemon-reload
systemctl restart docker

7.高危-禁止使用aufs存储驱动程序

描述：

“aufs”存储驱动程序是最早的存储驱动程序。 它基于Linux内核补丁集，该补丁集不太可能合并到主要Linux内核中。 并且已知“ aufs”驱动程序会导致一些严重的内核崩溃。 'aufs’刚刚获得了Docker的支持。 最重要的是，许多使用最新Linux内核的Linux发行版都不支持’aufs’驱动程序。

加固建议：

不要明确使用“ aufs”作为存储驱动程序。 例如，请勿按以下方式启动Docker守护程序： 若以systemctl管理docker服务则需要编辑/usr/lib/systemd/system/docker.service的ExecStart参数删除--storage-driver aufs重启docker服务

systemctl daemon-reload
systemctl restart docker

8.高危-禁止在容器上挂载敏感的主机系统目录

描述：

不允许将以下敏感的主机系统目录作为容器卷挂载，尤其是在读写模式下。

/boot /dev /etc /lib /proc /sys /usr

如果敏感目录以读写模式挂载，则可以对那些敏感目录中的文件进行更改。 这些更改可能会降低安全隐患或不必要的更改，这些更改可能会使Docker主机处于受损状态

如果您是k8s或其他容器编排软件编排的容器，请依照相应的安全策略配置或忽略。

加固建议：

不要在容器上挂载主机敏感目录，尤其是在读写模式下

9.高危-禁止共享主机的进程名称空间

描述

进程ID（PID）命名空间隔离了进程ID号空间，这意味着不同PID命名空间中的进程可以具有相同的PID。 这是容器和主机之间的进程级别隔离。

PID名称空间提供了流程分离。 PID命名空间删除了系统进程的视图，并允许进程ID重复使用，包括PID1。如果主机的PID命名空间与容器共享，则它将基本上允许容器内的进程查看主机上的所有进程。 系统。 这破坏了主机和容器之间的进程级别隔离的好处。 有权访问容器的人最终可以知道主机系统上正在运行的所有进程，甚至可以从容器内部杀死主机系统进程。 这可能是灾难性的。 因此，请勿与容器共享主机的进程名称空间。

加固建议：

不要使用--pid = host参数启动容器。

10.中危-为Docker启动内容信任

描述：

默认情况下禁用内容信任。 您应该启用它。 内容信任提供了将数字签名用于发送到远程Docker注册表和从远程Docker注册表接收的数据的功能。 这些签名允许客户端验证特定图像标签的完整性和发布者。 这确保了容器图像的出处

加固建议：

要在bash shell中启用内容信任，请输入以下命令：export DOCKER_CONTENT_TRUST=1 或者，在您的配置文件中设置此环境变量，以便在每次登录时启用内容信任。 内容信任目前仅适用于公共Docker Hub的用户。 当前不适用于Docker Trusted Registry或私有注册表。

文件权限

11.高危-确认docker相关文件权限适合

描述：

确保可能包含敏感参数的文件和目录的安全对确保Docker守护程序的正确和安全运行至关重要

加固建议：

执行以下命令为docker相关文件配置权限：

chown root:root /usr/lib/systemd/system/docker.service
chmod 644 /usr/lib/systemd/system/docker.service
chown root:root /usr/lib/systemd/system/docker.socket
chmod 644 /usr/lib/systemd/system/docker.socket
chown root:root /etc/docker
chmod 755 /etc/docker

若文件路径与实际系统中不同可以使用以下命令获取文件路径：

systemctl show -p FragmentPath docker.socket
systemctl show -p FragmentPath docker.service

12.高危-确保docker.sock不被挂载

描述：
docker.sock挂载的容器容易被获取特殊权限，一旦危险进入到docker中，严重影响了宿主机的安全.

加固建议：

按照提示<image name> <container name>查找启动的docker容器 ， 以非docker挂载docker.sock的形式重新启动容器

docker stop <container name>

docker run [OPTIONS] <image name>或docker run [OPTIONS]

安全审计

13.高危-审核Docker文件和目录

描述：

除了审核常规的Linux文件系统和系统调用之外，还审核所有与Docker相关的文件和目录。 Docker守护程序以“ root”特权运行。 其行为取决于某些关键文件和目录。如 /var/lib/docker、/etc/docker、docker.service、 docker.socket、/usr/bin/docker-containerd、/usr/bin/docker-runc等文件和目录

加固建议：

在/etc/audit/audit.rules与/etc/audit/rules.d/audit.rules文件中添加以下行：

-w /var/lib/docker -k docker
-w /etc/docker -k docker
-w /usr/lib/systemd/system/docker.service -k docker
-w /usr/lib/systemd/system/docker.socket -k docker
-w /usr/bin/docker-containerd -k docker
-w /usr/bin/docker-runc -k docker

然后，重新启动audit程序 service auditd restart.

推荐学习：《docker视频教程》

The above is the detailed content of Docker security baselines you must know. For more information, please follow other related articles on the PHP Chinese website!