容器安全实践（一）：概念篇 - 从“想当然”到“真相”

在容器化技术日益普及的今天，许多开发者和运维人员都将应用部署在 Docker 或 Kubernetes 中。然而，一个普遍存在的误解是：“容器是完全隔离的，所以它是安全的。”

如果你也有同样的想法，那么你需要重新审视容器安全了。

本文将从一个简单的命令切入，深入探讨容器安全的核心机制，并为你提供 Kubernetes 中最实用的安全实践。

一、你的 `root`，到底是谁的 `root`？

当你敲下 docker run my-image 这条命令时，如果没有特别指定，你的容器会以 root 用户身份运行。一个很自然的问题是：这个 root，是宿主机的 root 吗？

答案是：不完全是，但存在危险的关联。

容器利用 Linux 内核的 Namespace（命名空间）技术来创建隔离。其中，User Namespace 提供了用户身份的隔离。理论上，容器内的 root 用户（UID 0）可以被映射到宿主机上的一个普通用户（例如 UID 1001）。在这种情况下，容器内的 root 进程在宿主机上实际上是受限的。

然而，默认的 Docker 配置并没有启用这种隔离。这意味着，容器内的 root 用户就是宿主机上的 root 用户。如果你的容器被攻破，攻击者将直接拥有宿主机的最高权限，这就像为恶意软件打开了所有大门。

一个危险的例子：假设你通过 hostPath 将宿主机的 /etc 目录挂载到容器中。由于容器内的 root 等同于宿主机的 root，攻击者可以轻易地访问 /host/etc/shadow 文件，从而获取所有用户的加密密码。

因此，我们的首要任务是打破这种危险的关联，让容器以非特权用户身份运行。

二、核心原理：共享内核机制的“双刃剑”

要理解容器安全的本质，我们必须回到它的底层：共享内核机制。

与虚拟机（VM）不同，容器没有自己的独立内核。所有容器都共享宿主机的操作系统内核。正是这种设计，让容器变得轻量、高效。

但与此同时，共享内核也带来了安全风险。容器的隔离是软件层面的，而不是硬件层面的。 容器通过 Namespace（实现视图隔离）和 Cgroups（实现资源限制）来获得安全保障。

你可以将共享内核比喻为一栋公寓楼的核心结构，而 Namespace 和 Cgroups 则是隔离每个单元的墙壁和门。如果墙壁出现漏洞（即内核漏洞），或者房门没有上锁（即配置不当），那么一个单元内的恶意行为就可能蔓延到整个公寓楼。

这也是为什么我们不能盲目信任容器的默认设置，而必须主动加固其安全配置。

三、特权容器：比 `root` 用户更危险的存在

除了默认的 root 用户权限，容器中还有一个更具破坏力的概念：特权容器（Privileged Container）。

特权容器是指突破了所有命名空间隔离，拥有几乎所有宿主机权限的容器。它可以通过以下配置开启：

securityContext:privileged: true

当一个容器被赋予 privileged: true 时，它：

可以访问所有设备：能够直接访问宿主机的硬件设备，比如 /dev/sda1。
可以加载内核模块：能够为宿主机加载新的内核模块。
几乎没有限制：可以执行任何系统调用，如同在宿主机上直接使用 root 权限。

为什么特权容器如此危险？

特权容器本质上等同于直接在宿主机上以 root 用户运行进程。如果你的应用需要访问底层硬件或执行复杂的系统管理任务，通常会选择特权容器。然而，一旦特权容器被攻破，攻击者就能完全控制宿主机，甚至影响到宿主机上的其他容器。这是一种极其严重的安全风险，在生产环境中应极力避免。

四、Kubernetes 的解决方案：内置的 Pod 安全策略

Kubernetes 不仅仅提供了 安全上下文（Security Context） 这个配置项，它还内置了一套强大的安全策略机制来强制执行这些配置，这套机制就是 PodSecurity Admission (PSA)。

你可以将 安全上下文 看作是 Pod 的安全配置清单，而 PSA 则是 Kubernetes 集群的“安全警卫”。PSA 会在 Pod 创建时进行检查，确保其安全上下文符合预设的安全标准。

这套机制将 Kubernetes 的安全能力分为三个等级，方便你根据应用场景选择不同的安全级别：

特权（privileged）：最宽松的策略，几乎不作任何限制。这个级别应只用于需要直接操作宿主机的特殊应用，如监控工具或网络插件。
基线（baseline）：一个适度宽松的策略，旨在防止已知的特权提升。它会强制应用非特权用户运行、限制特权能力，但允许一些默认的非敏感配置。这是大多数生产应用的推荐起点。
受限（restricted）：最严格的策略，遵循最新的容器安全最佳实践。它会强制所有 Pod 以非特权用户运行、使用只读文件系统、并移除所有不必要的特权。此级别适用于对安全性要求极高的多租户环境。

如何应用 PSA？
你可以在命名空间（Namespace）层面，通过一个简单的标签来强制应用这些策略：

apiVersion: v1
kind: Namespace
metadata:name: my-secure-namespacelabels:pod-security.kubernetes.io/enforce: restricted

通过这个标签，my-secure-namespace 中的任何 Pod，如果其安全配置不符合 restricted 策略，都会被 Kubernetes 拒绝创建。

为什么要同时使用安全上下文和 PSA？
这是一种深度防御的策略：

PSA 守住底线：它作为集群层面的“门禁”，确保没有 Pod 能够以极不安全的方式运行。
安全上下文进行精细化配置：它允许你为每个 Pod 定义更具体、更适合应用的权限，即使在 restricted 策略下，你仍然可以使用 runAsUser 和 fsGroup 等配置来优化应用的权限。

这种结合使用的方式，既能保证集群整体的安全性，又能为每个应用提供量身定做的安全配置。

五、落地实践：分层推进的安全最佳实践

在实际项目中，我们应该遵循分层推进的原则来配置 Pod 安全。这就像学习开车，首先要掌握的是踩油门、刹车和打方向盘。至于如何使用高级辅助驾驶系统，那是更高级的技能。

1. 基础最佳实践 (所有应用)

这三条配置是所有容器安全实践的基础。如果说容器安全是一栋大楼，那么这三条就是地基和核心框架。有了它们，你的 Pod 就已经具备了抵御绝大多数攻击的能力。

实践一：坚持最小权限原则，以非 root 用户运行

这是最重要的实践。通过在 Pod 级别设置 runAsUser，你可以强制所有容器都以一个权限受限的非 root 用户身份运行。

YAML 配置示例：

spec:securityContext:runAsUser: 1001runAsGroup: 1001fsGroup: 1001

一个常见的疑问：UID 1001 需要在宿主机上提前创建吗？

不需要。 这是容器和 Kubernetes 运行的一个巧妙之处。当你使用 runAsUser: 1001 时，Kubernetes 不会去检查宿主机上是否存在 UID 为 1001 的用户。它只会确保容器内部的进程以 UID 1001 的身份运行。在 Linux 中，UID 和 GID 只是一个数字，内核只关心这个数字，而不关心它是否对应一个实际的用户名。

一个重要的例外：文件权限

虽然你不需要提前创建用户，但如果你的容器应用需要访问宿主机上的文件，那么容器内的进程必须拥有对这个目录的访问权限。在这种情况下，你需要确保容器内的 UID 1001 拥有对宿主机上该目录的读写权限。这通常通过在宿主机上设置权限或在 Pod 中使用 fsGroup 来实现。

实践二：容器级别的补充配置

Pod 级别的配置提供了整体安全，但一些细节需要针对性地处理。以下是一个遵循最佳实践的 Pod YAML 模板，你可以直接拿来使用：

apiVersion: v1
kind: Pod
metadata:name: my-secure-pod
spec:# Pod 级别的安全上下文：为整个 Pod 设定基线安全策略securityContext:# 1. 坚持最小权限原则：以非 root 用户运行#    这个用户 ID 应该在你的容器镜像中定义，或者是一个在宿主机上#    权限受限的用户 ID。通常选择一个大于 1000 的 ID。runAsUser: 1001# 2. 限制文件系统权限：确保 Pod 访问的数据卷权限受限#    当 Pod 挂载数据卷时，该卷的所有权会变为指定的组 ID，#    确保只有 Pod 内的进程可以读写。runAsGroup: 1001fsGroup: 1001containers:- name: my-app-containerimage: my-app-image:v1.0# 容器级别的安全上下文：针对特定容器进行调整securityContext:# 3. 限制特权：丢弃所有不必要的特权，只添加确实需要的#    drop: [ALL] 是一个很好的起点，表示丢弃所有默认特权。capabilities:drop:- ALL# 4. 禁止权限提升：防止攻击者从非特权提升到 root 权限allowPrivilegeEscalation: false# 5. 只读文件系统：防止恶意篡改#    如果容器不需要向根文件系统写入数据，将其设置为只读。readOnlyRootFilesystem: truevolumeMounts:# 6. 挂载数据卷：为需要写入数据的容器提供可写空间#    与 readOnlyRootFilesystem 结合使用，确保只有特定目录可写。- name: data-volumemountPath: /datavolumes:- name: data-volumeemptyDir: {}

2. 高级安全实践 (特定应用)

除了上述三条，Pod 级别的 securityContext 还有其他一些配置，但它们通常被认为是高级安全实践，而不是基础最佳实践。

seLinuxOptions / windowsOptions：这些配置是特定于操作系统的，不具备普适性。
seccompProfile / sysctls：这些配置非常精细，需要你对 Linux 内核、系统调用和应用程序行为有深入的了解。错误的配置可能会导致 Pod 无法启动或应用崩溃。对于大多数应用来说，默认的配置已经足够安全。

因此，最佳实践是分层推进。首先，确保你理解并应用了这三条核心配置。当你的项目需要更高的安全级别或面临特定安全挑战时，再根据具体情况去探索和应用其他高级配置。