Skip to content

Docker Security Cheat Sheet / Docker安全速查表

Introduction / 介绍

Docker is the most popular containerization technology. When used correctly, it can enhance security compared to running applications directly on the host system. However, certain misconfigurations can reduce security levels or introduce new vulnerabilities.

Docker是最受欢迎的容器化技术。正确使用时，与直接在主机系统上运行应用程序相比，可以提高安全性。然而，某些配置错误可能会降低安全级别或引入新的漏洞。

The aim of this cheat sheet is to provide a straightforward list of common security errors and best practices to assist in securing your Docker containers.

本速查表的目的是提供一个简单明了的常见安全错误和最佳实践列表，以帮助您确保Docker容器的安全性。

Rules / 规则

RULE #0 - Keep Host and Docker up to date / 规则#0 - 保持主机和Docker更新

To protect against known container escape vulnerabilities like Leaky Vessels, which typically result in the attacker gaining root access to the host, it's vital to keep both the host and Docker up to date. This includes regularly updating the host kernel as well as the Docker Engine.

为了防止已知容器逃逸漏洞，如漏桶，这通常会导致攻击者获得对主机的root访问权限，保持主机和Docker更新至关重要。这包括定期更新主机内核以及Docker引擎。

This is due to the fact that containers share the host's kernel. If the host's kernel is vulnerable, the containers are also vulnerable. For example, the kernel privilege escalation exploit, Dirty COW, executed inside a well-insulated container would still result in root access on a vulnerable host.

这是因为容器共享主机的内核。如果主机的内核存在漏洞，容器也会存在漏洞。例如，在良好隔离的容器内执行的内核提权漏洞脏牛，仍然会导致在易受攻击的主机上获得root访问权限。

RULE #1 - Do not expose the Docker daemon socket (even to the containers) / 规则#1 - 不要暴露Docker守护进程套接字（即使是给容器）

Docker socket /var/run/docker.sock is the UNIX socket that Docker is listening to. This is the primary entry point for the Docker API. The owner of this socket is root. Giving someone access to it is equivalent to giving unrestricted root access to your host.

Docker套接字 /var/run/docker.sock 是Docker监听的UNIX套接字。这是Docker API的主要入口点。该套接字的拥有者是root。允许某人访问它等同于给予主机无限制的root访问权限。

Do not enable tcp Docker daemon socket. If you are running docker daemon with -H tcp://0.0.0.0:XXX or similar you are exposing unencrypted and unauthenticated direct access to the Docker daemon, if the host is internet connected this means the docker daemon on your computer can be used by anyone from the public internet. If you really, really have to do this, you should secure it. Check how to do this following Docker official documentation.

不要启用 tcp Docker守护进程套接字。 如果你使用 -H tcp://0.0.0.0:XXX 或类似命令运行docker守护进程，你将暴露未加密且未经身份验证的直接访问Docker守护进程，如果主机连接到互联网，这意味着你的计算机上的Docker守护进程可以被公共互联网上的任何人使用。如果你真的，真的必须这样做，你应该确保其安全性。请参考Docker官方文档了解如何操作。

Do not expose /var/run/docker.sock to other containers. If you are running your docker image with -v /var/run/docker.sock://var/run/docker.sock or similar, you should change it. Mounting the socket read-only does not make the Docker API read-only: a process that can connect to the socket can still send requests that modify containers or the host. Docker grants access to all daemon commands by default; filesystem mount flags do not replace API authorization. Equivalent in the docker compose file is something like this:

不要将 /var/run/docker.sock 暴露给其他容器。如果你使用 -v /var/run/docker.sock://var/run/docker.sock 或类似命令运行你的docker镜像，你应该进行更改。将套接字挂载为只读不会使Docker API只读：能够连接到套接字的过程仍然可以发送修改容器或主机的请求。Docker默认授予对所有守护进程命令的访问权限；文件系统挂载标志不能替代API授权。在docker compose文件中的等效操作如下：

volumes:
  - "/var/run/docker.sock:/var/run/docker.sock"

RULE #2 - Set a user / 规则 #2 - 设置用户

Configuring the container to use an unprivileged user is the best way to prevent privilege escalation attacks. This can be accomplished in three different ways as follows:

配置容器使用非特权用户是防止提权攻击的最佳方式。这可以通过以下三种不同的方式实现：

  1. During runtime using -u option of docker run command e.g.:
    中文：在运行时使用 docker run 命令的 -u 选项，例如：
docker run -u 4000 alpine
  1. During build time. Simply add user in Dockerfile and use it. For example:
    中文：在构建时。只需在Dockerfile中添加用户并使用它。例如：
FROM alpine
RUN groupadd -r myuser && useradd -r -g myuser myuser
#    <HERE DO WHAT YOU HAVE TO DO AS A ROOT USER LIKE INSTALLING PACKAGES ETC.>
USER myuser
  1. Enable user namespace support (--userns-remap=default) in Docker daemon
    中文：在Docker 守护进程中启用用户命名空间支持（--userns-remap=default）。

More information about this topic can be found at Docker official documentation. For additional security, you can also run in rootless mode, which is discussed in Rule #11.

更多关于这个主题的信息可以在Docker官方文档中找到。为了额外的安全性，你也可以以无根模式运行，这在规则 #11（#rule-11---run-docker-in-rootless-mode）中进行了讨论。

In Kubernetes, this can be configured in Security Context using the runAsUser field with the user ID e.g:

在 Kubernetes 中，这可以通过在 安全上下文 中使用 runAsUser 字段进行配置，例如使用用户 ID：

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
    - name: example
      image: gcr.io/google-samples/node-hello:1.0
      securityContext:
        runAsUser: 4000 # <-- This is the pod user ID

As a Kubernetes cluster administrator, you can configure a hardened default using the Restricted level with built-in Pod Security admission controller, if greater customization is desired consider using Admission Webhooks or a third party alternative.

作为 Kubernetes 集群管理员，您可以使用 Restricted 级别（受限级别）进行加固默认设置，内置 Pod 安全准入控制器，如果需要更大的定制化，可以考虑使用 准入 Webhook 或第三方替代方案（替代方案）。

RULE #3 - Limit capabilities (Grant only specific capabilities, needed by a container) / 规则 #3 - 限制能力（仅授予容器所需的特定能力）

Linux kernel capabilities) （Linux 内核能力） are a set of privileges that can be used by privileged. Docker, by default, runs with only a subset of capabilities. You can change it and drop some capabilities (using --cap-drop) to harden your docker containers, or add some capabilities (using --cap-add) if needed. Remember not to run containers with the --privileged flag - this will add ALL Linux kernel capabilities to the container.

您可以通过使用 --cap-drop 来更改并删除一些能力（以加固您的 Docker 容器），或者在需要时添加一些能力（使用 --cap-add）。请记住不要使用 --privileged 标志运行容器 - 这会将所有 Linux 内核能力添加到容器中。

The most secure setup is to drop all capabilities --cap-drop all and then add only required ones. For example:

最安全的设置是先删除所有能力 --cap-drop all，然后仅添加所需的那些。例如：

docker run --cap-drop all --cap-add CHOWN alpine

And remember: Do not run containers with the --privileged flag!!!

并且记住：不要使用 --privileged 标志运行容器！！！

In Kubernetes this can be configured in Security Context using capabilities field e.g:

在 Kubernetes 中，这可以通过在 安全上下文 中使用 capabilities 字段进行配置，例如：

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
    - name: example
      image: gcr.io/google-samples/node-hello:1.0
      securityContext:
        capabilities:
          drop:
            - ALL
          add: ["CHOWN"]

As a Kubernetes cluster administrator, you can configure a hardened default using the Restricted level with built-in Pod Security admission controller, if greater customization is desired consider using Admission Webhooks or a third party alternative.

作为 Kubernetes 集群管理员，您可以使用 Restricted 级别（受限级别）进行加固默认设置，内置 Pod 安全准入控制器，如果需要更大的定制化，可以考虑使用 准入 Webhook 或第三方替代方案（替代方案）。

RULE #4 - Prevent in-container privilege escalation / 规则#4 - 防止容器内权限提升

Always run your docker images with --security-opt=no-new-privileges in order to prevent privilege escalation. This will prevent the container from gaining new privileges via setuid or setgid binaries.

始终使用 --security-opt=no-new-privileges 运行您的Docker镜像，以防止权限提升。这将防止容器通过 setuid 或 setgid 二进制文件获得新的权限。

In Kubernetes, this can be configured in Security Context using allowPrivilegeEscalation field e.g.:

在Kubernetes中，这可以通过在安全上下文中使用 allowPrivilegeEscalation 字段进行配置，例如：

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
    - name: example
      image: gcr.io/google-samples/node-hello:1.0
      securityContext:
        allowPrivilegeEscalation: false

As a Kubernetes cluster administrator, you can configure a hardened default using the Restricted level with built-in Pod Security admission controller, if greater customization is desired consider using Admission Webhooks or a third party alternative.

作为 Kubernetes 集群管理员，您可以使用 Restricted 级别（受限级别）进行加固默认设置，内置 Pod 安全准入控制器，如果需要更大的定制化，可以考虑使用 准入 Webhook 或第三方替代方案（替代方案）。

RULE #5 - Be mindful of Inter-Container Connectivity / 规则#5 - 注意容器间的连接性

Inter-Container Connectivity (icc) is enabled by default, allowing all containers to communicate with each other through the docker0 bridged network. Instead of using the --icc=false flag with the Docker daemon, which completely disables inter-container communication, consider defining specific network configurations. This can be achieved by creating custom Docker networks and specifying which containers should be attached to them. This method provides more granular control over container communication.

容器间连接性（icc）默认启用，允许所有容器通过 docker0 网桥网络（https://docs.docker.com/network/drivers/bridge/）相互通信。与其使用Docker守护进程的 --icc=false 标志完全禁用容器间通信，不如考虑定义特定的网络配置。这可以通过创建自定义Docker网络并指定哪些容器应连接到它们来实现。这种方法提供了对容器通信的更细粒度控制。

For detailed guidance on configuring Docker networks for container communication, refer to the Docker Documentation.

有关配置Docker网络以实现容器通信的详细指南，请参阅Docker文档。

In Kubernetes environments, Network Policies can be used to define rules that regulate pod interactions within the cluster. These policies provide a robust framework to control how pods communicate with each other and with other network endpoints. Additionally, Network Policy Editor simplifies the creation and management of network policies, making it more accessible to define complex networking rules through a user-friendly interface.

在Kubernetes环境中，可以使用网络策略来定义规则，以规范集群内Pod之间的交互。这些策略提供了一个强大的框架，用于控制Pod如何相互通信以及如何与其他网络端点通信。此外，网络策略编辑器简化了网络策略的创建和管理，使得通过用户友好的界面定义复杂的网络规则变得更加容易。

RULE #5a - Be careful when mapping container ports to the host with firewalls like UFW / 规则#5a - 在使用UFW等防火墙映射容器端口到主机时请小心

UFW (Uncomplicated Firewall)) （UFW（简单防火墙）） is a popular host-based firewall for Linux. A common misconception is that firewall rules protect all inbound traffic — including traffic destined for Docker containers. However, Docker manages its own iptables and nftables rules directly and bypasses UFW entirely. Note that other tools that use iptables or nftables can also have conflicts similar to UFW. If you are using other firewall tools, you should check if they are working correctly.

When you publish a port with -p 8000:8000, Docker inserts iptables rules that open that port to all interfaces and all source addresses, and these rules are typically accepted before explicit firewall DENY rules are applied. As a result, traffic may be allowed through regardless of any DENY rules you have set, which can unintentionally expose container services to the public internet.

当您使用-p 8000:8000发布端口时，Docker会插入iptables规则，该规则将端口对所有接口和所有源地址开放，并且这些规则通常在应用显式的防火墙DENY规则之前被接受。因此，即使设置了DENY规则，也可能允许流量通过，这可能会无意中将容器服务暴露给公共互联网。

Option 1 — Bind published ports to localhost only:

选项1 — 仅将发布端口绑定到localhost：

Bind the host side of the port mapping to 127.0.0.1 so the service is only reachable locally, not from external networks:

将端口映射的主机端绑定到127.0.0.1，以便服务只能从本地访问，而不能从外部网络访问：

# Vulnerable: exposes port on all interfaces
docker run -p 8000:8000 myimage

# Safe: binds only to localhost
docker run -p 127.0.0.1:8000:8000 myimage

In a Docker Compose file:

在Docker Compose文件中：

services:
  web:
    image: myimage
    ports:
      - "127.0.0.1:8000:8000"  # safe — localhost only

Option 2 — Use ufw-docker (or equivalent) to enforce firewall rules over Docker networks:

选项2 — 使用ufw-docker（或等效工具）在Docker网络上强制执行防火墙规则：

For UFW specifically, the ufw-docker project provides a script and supplemental iptables rules that patch Docker's networking to respect UFW policies, allowing you to use standard UFW commands to control traffic to containers:

对于UFW而言，ufw-docker项目提供了一个脚本和补充的iptables规则，这些规则修补了Docker的网络，使其遵守UFW策略，允许您使用标准的UFW命令来控制对容器的流量：

# Install ufw-docker integration rules
sudo ufw-docker install

# Allow external access to a specific container port
sudo ufw-docker allow mycontainer 8000/tcp

Refer to the Docker and iptables documentation for a deeper explanation of how Docker interacts with the host firewall.

参考Docker和iptables文档以深入了解Docker如何与主机防火墙交互。

RULE #6 - Use Linux Security Module (seccomp, AppArmor, or SELinux) for Runtime Security / 规则#6 - 使用Linux安全模块（seccomp、AppArmor或SELinux）进行运行时安全

First of all, do not disable default security profile! Always start with Docker’s or your host’s default profile as a baseline.

首先，不要禁用默认安全配置文件！始终以Docker或主机默认配置文件作为基准开始。

Security Profile Recommendations:

安全配置文件推荐：

  • Seccomp: Restrict syscalls to the minimum required for your container. Use Docker’s default seccomp profile as a starting point and customize per workload. Docker Seccomp
    中文：Seccomp：限制 syscall 到您容器所需的最小范围。以 Docker 的默认 seccomp 配置为起点，并根据工作负载进行自定义。Docker Seccomp

  • AppArmor: Apply per-container AppArmor profiles to enforce mandatory access controls. Docker AppArmor
    中文：AppArmor：为每个容器应用 AppArmor 配置文件以强制执行强制访问控制。Docker AppArmor

  • SELinux: Enable SELinux on the host and ensure containers are labeled properly. Enforce SELinux policies to prevent unauthorized access to host resources. SELinux Guide for Docker
    中文：SELinux：在主机上启用 SELinux 并确保容器被正确标记。强制执行 SELinux 策略以防止对主机资源的未经授权访问。SELinux Docker 指南

Runtime Security Improvements:

运行时安全改进：

  • Behavioral Monitoring: Use tools like Falco, Tetragon, or Cilium eBPF to detect unexpected or malicious container activity. Examples: Unexpected exec calls, privilege escalation attempts, unusual network connections.

    中文：行为监控: 使用 Falco、Tetragon 或 Cilium eBPF 等工具来检测意外的或恶意的容器活动。例如：意外的执行调用、提权尝试、不寻常的网络连接。

  • Anomaly Detection: Continuously monitor container processes, filesystem changes, and network activity to identify abnormal patterns in real time.

    中文：异常检测：持续监控容器进程、文件系统更改和网络活动，以实时识别异常模式。

  • Kubernetes Security Context: Configure pods or containers with seccomp and AppArmor profiles in Kubernetes. Configure a Security Context for a Pod or Container
    中文：Kubernetes 安全上下文: 在 Kubernetes 中配置具有 seccomp 和 AppArmor 配置文件的 pod 或容器。配置 Pod 或容器的安全上下文

RULE #7 - Limit resources (memory, CPU, file descriptors, processes, restarts) / 规则#7 - 限制资源（内存、CPU、文件描述符、进程、重启）

The best way to avoid DoS attacks is by limiting resources. You can limit memory, CPU, maximum number of restarts (--restart=on-failure:<number_of_restarts>), maximum number of file descriptors (--ulimit nofile=<number>) and maximum number of processes (--ulimit nproc=<number>).

避免DoS攻击的最佳方法是限制资源。您可以限制内存、CPU、最大重启次数（--restart=on-failure:<重启次数>）、最大文件描述符数（--ulimit nofile=<数量>）和最大进程数（--ulimit nproc=<数量>）。

Check documentation for more details about ulimits) （检查文档以获取有关 ulimits 的更多详细信息）

You can also do this for Kubernetes: Assign Memory Resources to Containers and Pods, Assign CPU Resources to Containers and Pods and Assign Extended Resources to a Container

您也可以为 Kubernetes 执行此操作：为容器和 Pod 分配内存资源，为容器和 Pod 分配 CPU 资源 和 为容器分配扩展资源

RULE #8 - Set filesystem and volumes to read-only / 规则 #8 - 将文件系统和卷设置为只读

Run containers with a read-only filesystem using --read-only flag. For example:

使用 --read-only 标志以只读文件系统运行容器。例如：

docker run --read-only alpine sh -c 'echo "whatever" > /tmp'

If an application inside a container has to save something temporarily, combine --read-only flag with --tmpfs like this:

如果容器中的应用程序需要临时保存某些内容，可以将 --read-only 标志与 --tmpfs 结合使用，如下所示：

docker run --read-only --tmpfs /tmp alpine sh -c 'echo "whatever" > /tmp/file'

The Docker Compose compose.yml equivalent would be:

Docker Compose 的 compose.yml 等价配置为：

version: "3"
services:
  alpine:
    image: alpine
    read_only: true

Equivalent in Kubernetes in Security Context:

在 Kubernetes 中的等价配置在 安全上下文 中：

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
    - name: example
      image: gcr.io/google-samples/node-hello:1.0
      securityContext:
        readOnlyRootFilesystem: true

In addition, if the volume is mounted only for reading mount them as a read-only It can be done by appending :ro to the -v like this:

此外，如果卷仅用于读取，将其挂载为只读。可以通过将 :ro 添加到 -v 后面来实现，如下所示：

docker run -v volume-name:/path/in/container:ro alpine

Or by using --mount option:

通过使用 --mount 选项：

docker run --mount source=volume-name,destination=/path/in/container,readonly alpine

RULE #9 - Integrate container scanning tools into your CI/CD pipeline

CI/CD pipelines are a crucial part of the software development lifecycle and should include various security checks such as lint checks, static code analysis, and container scanning.

Many issues can be prevented by following some best practices when writing the Dockerfile. However, adding a security linter as a step in the build pipeline can go a long way in avoiding further headaches. Some issues that are commonly checked are:

在编写 Dockerfile 时遵循一些最佳实践可以预防许多问题。然而，在构建管道中添加一个安全检查器作为步骤可以在很大程度上避免进一步的麻烦。一些常见的检查问题包括：

  • Ensure a USER directive is specified
    中文：确保指定了 USER 指令
  • Ensure the base image version is pinned
    中文：确保基础镜像版本被固定
  • Ensure the OS packages versions are pinned
    中文：确保操作系统包版本被固定
  • Avoid the use of ADD in favor of COPY
    中文：避免使用 ADD 而选择 COPY
  • Avoid curl bashing in RUN directives
    中文：避免在 RUN 指令中使用 curl 打包

References:

参考资料：

Container scanning tools are especially important as part of a successful security strategy. They can detect known vulnerabilities, secrets and misconfigurations in container images and provide a report of the findings with recommendations on how to fix them. Some examples of popular container scanning tools are:

容器扫描工具作为成功安全策略的一部分尤为重要。它们可以检测已知漏洞、机密和配置错误，并提供一份发现报告，其中包含如何修复它们的建议。以下是一些流行的容器扫描工具的示例：

To detect secrets in images:

在图像中检测机密信息：

To detect misconfigurations in Kubernetes:

在 Kubernetes 中检测配置错误：

To detect misconfigurations in Docker:

检测 Docker 中的配置错误：

To detect misconfigurations in Docker Compose files before deployment:

在部署前检测 Docker Compose 文件中的配置错误：

RULE #10 - Keep the Docker daemon logging level at info / 规则 #10 - 保持 Docker 守护进程的日志级别为 info

By default, the Docker daemon is configured to have a base logging level of info. This can be verified by checking the daemon configuration file /etc/docker/daemon.json for thelog-level key. If the key is not present, the default logging level is info. Additionally, if the docker daemon is started with the --log-level option, the value of the log-level key in the configuration file will be overridden. To check if the Docker daemon is running with a different log level, you can use the following command:

默认情况下，Docker守护进程配置为基本日志级别为info。可以通过检查守护进程配置文件/etc/docker/daemon.json中的log-level键来验证。如果该键不存在，则默认日志级别为info。此外，如果使用--log-level选项启动Docker守护进程，配置文件中log-level键的值将被覆盖。要检查Docker守护进程是否以不同的日志级别运行，可以使用以下命令：

ps aux | grep '[d]ockerd.*--log-level' | awk '{for(i=1;i<=NF;i++) if ($i ~ /--log-level/) print $i}'

Setting an appropriate log level, configures the Docker daemon to log events that you would want to review later. A base log level of 'info' and above would capture all logs except the debug logs. Until and unless required, you should not run docker daemon at the 'debug' log level.

设置适当的日志级别，配置Docker守护进程记录您希望稍后审查的事件。基本日志级别为'info'及以上将捕获所有日志，除了调试日志。除非需要，否则不应以'debug'日志级别运行docker守护进程。

Rule #11 - Run Docker in rootless mode / 规则#11 - 以rootless模式运行Docker

Rootless mode) （rootless模式） runs the Docker daemon and containers without host-root privileges, reducing the impact of daemon or runtime compromise. It does not guarantee protection against host privilege escalation through kernel vulnerabilities; the shared kernel remains part of the security boundary. Unlike rootless mode, userns-remap leaves the daemon running with root privileges.

Evaluate the specific requirements and security posture of your environment to determine if rootless mode is the best choice for you. For environments where security is a paramount concern and the limitations of rootless mode do not interfere with operational requirements, it is a strongly recommended configuration. Alternatively consider using Podman as an alternative to Docker.

评估具体要求和安全态势，以确定rootless模式是否最适合您。对于安全至关重要且rootless模式的限制不会干扰操作要求的环境，这是一个强烈推荐的配置。或者考虑使用Podman作为Docker的替代方案。

Rootless mode allows running the Docker daemon and containers as a non-root user to mitigate potential vulnerabilities in the daemon and the container runtime.

中文：无根模式允许以非 root 用户运行 Docker 守护进程和容器，以减轻守护进程和容器运行时潜在的安全漏洞。 Rootless mode does not require root privileges even during the installation of the Docker daemon, as long as the prerequisites are met.

中文：无根模式即使在安装 Docker 守护进程期间也不需要 root 权限，只要满足先决条件。

Read more about rootless mode and its limitations, installation and usage instructions on Docker documentation page.

在Docker文档页面阅读有关rootless模式及其限制、安装和用法说明的更多信息。

RULE #12 - Utilize Docker Secrets for Sensitive Data Management / 规则#12 - 利用Docker Secrets进行敏感数据管理

Docker Secrets provide a secure way to store and manage sensitive data such as passwords, tokens, and SSH keys. Using Docker Secrets helps in avoiding the exposure of sensitive data in container images or in runtime commands.

Docker机密提供了一种安全的方式来存储和管理敏感数据，如密码、令牌和SSH密钥。使用Docker机密有助于避免在容器镜像或运行时命令中暴露敏感数据。

docker secret create my_secret /path/to/super-secret-data.txt
docker service create --name web --secret my_secret nginx:latest

For local Docker Compose, file-backed secrets are bind mounts. Protect the source files on the host with appropriate access permissions and storage encryption; declaring a Compose secret does not encrypt these files. This differs from Swarm-managed secrets, which are distributed over mutual TLS and stored in an encrypted Raft log:

对于本地Docker Compose，文件支持的机密是绑定挂载。使用适当的访问权限和存储加密保护主机上的源文件；声明Compose机密不会加密这些文件。这与Swarm管理的机密不同，Swarm管理的机密通过相互TLS分发并存储在加密的Raft日志中：

version: "3.8"
secrets:
  my_secret:
    file: ./super-secret-data.txt
services:
  web:
    image: nginx:latest
    secrets:
      - my_secret

While Docker Secrets generally provide a secure way to manage sensitive data in Docker environments, this approach is not recommended for Kubernetes, where secrets are stored in plaintext by default. In Kubernetes, consider using additional security measures such as etcd encryption, or third-party tools. Refer to the Secrets Management Cheat Sheet and Kubernetes Security Cheat Sheet for more information.

虽然Docker机密通常为Docker环境中的敏感数据管理提供了一种安全方式，但这种方法不建议用于Kubernetes，在Kubernetes中，机密默认以明文形式存储。在Kubernetes中，请考虑使用额外的安全措施，如etcd加密或第三方工具。有关更多信息，请参阅机密管理速查表和Kubernetes安全速查表。

RULE #13 - Enhance Supply Chain Security / 规则#13 - 加强供应链安全

Building on the principles in Rule #9, enhancing supply chain security involves implementing additional measures to secure the entire lifecycle of container images from creation to deployment. Some of the key practices include:

在规则#9的原则基础上，加强供应链安全涉及实施额外措施来保护容器镜像从创建到部署的整个生命周期。一些关键实践包括：

  • Image Provenance) （镜像来源）: Document the origin and history of container images to ensure traceability and integrity.
  • SBOM Generation) （SBOM生成）: Create a Software Bill of Materials (SBOM) for each image, detailing all components, libraries, and dependencies for transparency and vulnerability management.
  • Image Signing) （镜像签名）: Digitally sign images to verify their integrity and authenticity, establishing trust in their security.
  • Trusted Registry) （可信注册表）: Store the documented, signed images with their SBOMs in a secure registry that enforces strict access controls and supports metadata management.
  • Secure Deployment) （安全部署）: Implement secure deployment polices, such as image validation, runtime security, and continuous monitoring, to ensure the security of the deployed images.

Podman as an alternative to Docker / Podman 作为 Docker 的替代方案

Podman is an OCI-compliant, open-source container management tool developed by Red Hat that provides a Docker-compatible command-line interface and a desktop application for managing containers. It is designed to be a more secure and lightweight alternative to Docker, especially for environments where secure defaults are preferred. Some of the security benefits of Podman include:

  1. Daemonless Architecture: Unlike Docker, which requires a central daemon (dockerd) to create, run, and manage containers, Podman directly employs the fork-exec model. When a user requests to start a container, Podman forks from the current process, then the child process execs into the container's runtime.
    中文：无守护进程架构：与需要中央守护进程（dockerd）来创建、运行和管理容器的 Docker 不同，Podman 直接采用 fork-exec 模型。当用户请求启动容器时，Podman 从当前进程派生出来，然后子进程在容器的运行时中 exec 进去。
  2. Rootless Containers: The fork-exec model facilitates Podman's ability to run containers without requiring root privileges. When a non-root user initiates a container start, Podman forks and execs under the user's permissions.
    中文：无根容器：fork-exec 模型使得 Podman 能够在不需要 root 权限的情况下运行容器。当非 root 用户启动容器时，Podman 在用户的权限下派生和 exec。
  3. SELinux Integration: Podman is built to work with SELinux, which provides an additional layer of security by enforcing mandatory access controls on containers and their interactions with the host system.
    中文：SELinux 集成：Podman 设计为与 SELinux 一起工作，它通过在容器及其与宿主系统的交互上强制执行强制访问控制，提供额外的安全层。

References / 参考