Docker 教程

Docker 容器安全：用户与组管理

即使在 Docker 容器这样隔离的环境中，以高权限（Elevated Privileges）运行容器进程也是一个巨大的安全风险。就像你通常不会在宿主机系统上直接以 root 用户身份运行生产环境的应用程序一样，在容器内部也绝不能这么做。

在容器内实施恰当的用户和组管理，能够确保你的应用程序遵循最小权限原则，从而在漏洞被利用时，将潜在的“爆炸半径”降至最低。这种做法是构建安全、高弹性容器化应用的基础。通过精心定义和使用非 Root 用户和组，你为防御潜在攻击增加了一层至关重要的防线，让你的 Docker 部署更加无懈可击。本章将带你深入学习这部分核心知识。

1. 容器中的最小权限原则

最小权限原则 (PoLP, Principle of Least Privilege) 规定：任何用户、程序或进程都应该只拥有执行其功能所需的最少权限。在 Docker 容器的语境下，这意味着除非绝对必要，否则在容器内运行的进程不应以 root 用户身份执行。

1.1 为什么要避免以 Root 身份运行？

虽然 Docker 提供了强大的隔离机制，但在容器内以 root 身份运行进程仍然会带来以下安全隐患：

  • 容器逃逸漏洞 (Container Escape Vulnerabilities)： 尽管罕见，但 Docker 守护进程、容器运行时或 Linux 内核本身的漏洞，可能会让容器内以 root 身份运行的进程突破容器边界，并在宿主机系统上获得 root 权限。这通常是最严重的容器漏洞类型。
  • 不必要的权限 (Unnecessary Privileges)： 绝大多数应用程序根本不需要 root 权限即可运行。以 root 身份运行会赋予应用访问系统级操作、敏感文件和网络配置的权限，而这些是应用并不需要的。如果攻击者控制了一个具有 root 权限的进程，他们可以执行的破坏动作将广泛得多。
  • 文件系统权限 (File System Permissions)： 当容器以 root 身份运行时，由容器内应用程序创建或修改的任何文件通常都归 root 所有。如果后来将这些文件复制出容器，或作为数据卷（Volumes）挂载到宿主机上，它们可能会保留 root 所有权，从而在宿主机上引发权限问题或安全隐患。
  • 供应链攻击 (Supply Chain Attacks)： 如果一个恶意的包或依赖项被引入到你的容器中，且你的应用程序以 root 身份运行，那么这段恶意代码就可以利用这些权限造成巨大破坏，例如安装后门或从容器中窃取敏感数据。

1.2 理解 UID 和 GID

用户 ID (UID) 和 组 ID (GID) 是 Linux 系统（包括 Docker 容器）的基础。每个用户账户都有一个唯一的 UID，每个组都有一个唯一的 GID。内核使用这些 ID 来确定文件、目录和进程的访问权限。

  • 容器内部： 当你在 Docker 容器内创建用户或组时，它会在该容器的文件系统内被分配一个 UID 和 GID。例如，root 的 UID 通常是 0，而非 root 用户的 UID 通常从 1000 或 1001 开始（取决于基础镜像）。
  • 宿主机上： 宿主机系统也有自己的一套 UID 和 GID。默认情况下，如果你在宿主机上检查容器的进程（例如使用 ps aux），在容器内以 UID 1000 运行的进程在宿主机上也会显示为 UID 1000。如果容器的 UID 1000 恰好对应宿主机上的一个特权用户，这就会成为一个安全隐患。

进阶概念：用户命名空间重映射 (User Namespace Remapping) 虽然超出了本章的范围，但你需要知道 Docker 可以配置为将容器的 UID/GID 重映射到宿主机上不同的 UID/GID。这意味着容器内的 UID 0 (root) 可以映射到宿主机上一个高编号的、无特权的 UID，从而进一步增强安全性。在本章的容器用户管理中，我们将重点关注如何在容器内部管理 UID/GID。

2. 在 Dockerfile 中创建和管理用户与组

实现用户和组管理最有效的方法是直接在你的 Dockerfile 中定义它们。这可以确保从你镜像构建出的每一个容器，默认都会以指定的非 root 用户运行。

2.1 使用 RUN 指令创建用户和组

你可以在 Dockerfile 的 RUN 指令中使用标准的 Linux 命令（如 groupadd 和 useradd）来创建新的用户和组。具体命令可能因你使用的基础镜像（如 Debian/Ubuntu vs. Alpine）而略有不同。

Debian/Ubuntu 基础镜像示例 (例如 ubuntu, debian, python:3.9-slim-buster)：

# 创建一个名为 'appgroup' 的系统组，无登录权限
RUN groupadd --system appgroup

# 创建一个名为 'appuser' 的系统用户
# -r, --system: 创建系统账户（无主目录，无 shell 等）
# -s, --shell: 设置用户的登录 shell（例如 /sbin/nologin 表示无 shell）
# -g, --gid: 设置用户的主组
RUN useradd --system --uid 1001 --gid appgroup appuser
  • groupadd --system appgroup：创建一个名为 appgroup 的系统组。系统组的 GID 通常低于 1000。为容器用户/组使用 --system 是一个好习惯，因为它们通常不需要完整的交互式登录功能。
  • useradd --system --uid 1001 --gid appgroup appuser：创建一个名为 appuser 的系统用户。
    • --uid 1001：显式将用户 ID 设置为 1001。在不同镜像间保持一致的 UID 通常很有好处，特别是当你打算与宿主机系统使用绑定挂载（bind mounts）时。
    • --gid appgroup：将 appgroup 分配为 appuser 的主组。

Alpine 基础镜像示例 (例如 alpine, node:alpine)：

Alpine Linux 使用 addgroup 和 adduser，语法略有不同。

# 创建一个名为 'appgroup' 的组
RUN addgroup -S appgroup

# 创建一个名为 'appuser' 的用户，并将其分配给 'appgroup'
# -S: 创建系统用户
# -G: 指定用户所属的附加组
# -u: 显式设置用户 ID
RUN adduser -S -u 1001 -G appgroup appuser

2.2 USER 指令

创建非 root 用户后，你需要使用 Dockerfile 中的 USER 指令来指定：接下来由哪个用户执行后续命令（如 RUN, CMD, 和 ENTRYPOINT），以及容器的主进程默认由哪个用户运行。

# ... (前面的指令，包括创建用户) ...

# 切换到非 root 用户
USER appuser

# 任何后续的 RUN, CMD, 或 ENTRYPOINT 命令都将作为 'appuser' 执行

如果不指定 USER，Docker 默认使用 root 用户。USER 指令可以接受：用户名、UID、用户名:组名 组合，或 UID:GID 组合。

2.3 设置文件和目录权限

创建非 root 用户后，至关重要的一步是确保你的应用程序文件和目录归该用户所有。这能防止非 root 用户因为需要读写自己的应用数据而被迫需要 root 权限。

你通常会使用 chown (更改所有者) 来修改文件和目录的所有权。这个命令必须在你在 Dockerfile 中切换 USER 之前运行，因为它需要 root 权限。

# ... (创建用户和组) ...

# 复制应用程序文件（如果 WORKDIR 归 root 所有，则需要 root 权限才能写入）
WORKDIR /app
COPY app.py requirements.txt ./

# 将应用程序目录的所有权更改为非 root 用户和组
# 这确保了 'appuser' 对 '/app' 拥有完全控制权
RUN chown -R appuser:appgroup /app

# 现在切换到非 root 用户
USER appuser

# ... (Dockerfile 的其余部分) ...

       关于 WORKDIR 的重要注意事项： > 如果你的 WORKDIR 是在 USER 指令之前定义的，它很可能归 root 所有。当你随后切换到非 root 用户时，该用户可能没有对 WORKDIR 的写入权限，除非你使用 chown 显式更改其所有权。一个好的做法是，始终对应用程序的 WORKDIR 以及应用程序需要写入数据的任何目录执行 chown 操作。

3. 实战演示与案例

让我们用一个简单的 Python Flask 应用程序来说明这些概念。

3.1 场景一：以 Root 身份运行 Python Flask 应用（反面教材）

首先，我们来看看不该怎么做。

app.py:

from flask import Flask
import os

app = Flask(__name__)

@app.route('/')
def hello():
    # 尝试写入文件到一个公共位置，演示当前用户权限
    try:
        with open("/tmp/container_user.txt", "w") as f:
            f.write(f"Hello from user: {os.getuid()} (root)" )
        file_status = "文件已写入 /tmp/container_user.txt"
    except Exception as e:
        file_status = f"无法写入 /tmp: {e}"

    return f"Hello from Flask! 运行 UID: {os.getuid()}。{file_status}"

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

requirements.txt:

Flask

Dockerfile.root:

# 从 Python 基础镜像开始
FROM python:3.9-slim-buster

# 设置容器内的工作目录
WORKDIR /app

# 复制 requirements 并安装它们
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 复制应用程序文件
COPY app.py .

# 暴露应用运行的端口
EXPOSE 5000

# 运行应用程序 (默认将以 root 身份运行)
CMD ["python", "app.py"]

构建并运行（作为 root）：

docker build -t flask-root-app -f Dockerfile.root .
docker run -d -p 5000:5000 --name my-root-app flask-root-app

现在，在浏览器中访问 http://localhost:5000。你会看到 "运行 UID: 0"，表明应用程序正以 root 身份运行。你也可以检查进程：

docker exec my-root-app ps aux
# 找到 'python app.py' 并观察 'USER' 列。它将会是 'root'。

3.2 场景二：使用专属的非 Root 用户运行应用（推荐做法）

现在，让我们通过以非 root 用户运行应用程序来保障它的安全。

Dockerfile.nonroot:

# 从 Python 基础镜像开始
FROM python:3.9-slim-buster

# 设置容器内的工作目录。最初它归 root 所有。
WORKDIR /app

# 复制 requirements 并安装（这些构建步骤仍以 root 身份进行）
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 复制应用程序文件
COPY app.py .

# --- 开始：用户和组管理 ---

# 1. 创建一个名为 'appgroup' 的系统组
RUN groupadd --system appgroup

# 2. 创建一个名为 'appuser' 的系统用户，指定 UID 为 1001，主组为 'appgroup'
#    使用特定的 UID 有助于以后与宿主机权限（如数据卷）保持一致
RUN useradd --system --uid 1001 --gid appgroup appuser

# 3. 将应用程序目录的所有权更改为新的非 root 用户和组
#    这极其关键，这样 'appuser' 才能读写它自己的应用程序文件。
#    此步骤 *必须* 在切换 USER 之前完成，因为 'chown' 需要 root 权限。
RUN chown -R appuser:appgroup /app

# 4. 切换到非 root 用户。后续所有命令都将作为 'appuser' 运行。
USER appuser

# --- 结束：用户和组管理 ---

# 暴露应用运行的端口
EXPOSE 5000

# 以 'appuser' 身份运行应用程序
CMD ["python", "app.py"]

构建并运行（作为非 root）：

docker build -t flask-nonroot-app -f Dockerfile.nonroot .
docker run -d -p 5001:5000 --name my-nonroot-app flask-nonroot-app

访问 http://localhost:5001。你现在会看到 "运行 UID: 1001"。这证实了应用程序正以我们专属的 appuser 运行。检查进程：

docker exec my-nonroot-app ps aux
# 找到 'python app.py'。'USER' 列将会是 'appuser'。

这演示了如何在 Dockerfile 中有效地创建专属用户并切换到该用户，从而提升应用程序的安全防护。

3.3 场景三：在运行时使用 docker run -u 覆盖用户

有时候，你可能需要以一个 Dockerfile 中没有显式设置的特定用户来运行容器，或者你想临时覆盖 USER 指令。docker run -u (或 --user) 标志允许你这样做。

你可以指定：

  • --user <用户名>: 用户必须存在于容器镜像内。
  • --user <uid>: 容器将尝试以该 UID 运行。如果该 UID 在容器内没有对应的命名用户，它将作为一个具有该 UID 的未命名用户运行。
  • --user <用户名>:<组名>
  • --user <uid>:<gid>

让我们使用场景一中默认以 root 运行的 flask-root-app 镜像。我们尝试在运行时以自定义的 UID/GID 运行它。

# 运行基于 root 的 Flask 应用，但在运行时指定 UID 和 GID
docker run -d -p 5002:5000 --name my-runtime-user-app --user 1002:1002 flask-root-app

现在，访问 http://localhost:5002。你会看到 "运行 UID: 1002"。

docker run -u 的局限性：

  1. 用户是否存在： 如果你指定了一个容器镜像中不存在的用户名（例如 docker run --user nonexistantuser），容器很可能会启动失败或遇到权限错误，因为系统找不到必要的用户配置。
  2. 权限问题： 指定的 UID/GID 必须对容器内部的应用程序文件和目录具有适当的权限。如果镜像是在假设拥有 root 权限的前提下构建的（就像 flask-root-app），仅仅在运行时通过 -u 更改用户可能会导致关键文件出现“权限被拒绝 (permission denied)”的错误，因为新指定的用户并不拥有这些文件。例如，如果 flask-root-app 试图写入 /var/log（归 root 所有），UID 1002 将会被拒绝。
  3. 复杂性： 虽然这对测试或特定场景很有用，但与将用户管理直接嵌入 Dockerfile 相比，一直依赖 docker run -u 会让你的部署变得不那么可预测，且难以管理。

最佳实践总结： 在 Dockerfile 中使用 RUN groupadd、RUN useradd、RUN chown 和 USER 定义你期望的用户和组。尽量少用 docker run -u，主要将其用于调试或需要临时覆盖特定用户的高级场景。