应用程序安全清单

此清单旨在从开发者的角度，提供在 Kubernetes 中保护运行应用程序的基本指南。此清单并非详尽无遗，旨在随着时间推移不断演进。

如何阅读和使用本文档

• 主题的顺序不代表优先级的顺序。
• 某些清单项在每个部分的列表下方段落中进行了详细说明。
• 此清单假设 `developer` 是与命名空间范围对象交互的 Kubernetes 集群用户。

基本安全强化

以下清单提供了适用于大多数部署到 Kubernetes 的应用程序的基本安全强化建议。

应用程序设计

• 在设计应用程序时，遵循正确的安全原则。
• 应用程序通过资源请求和限制配置了适当的QoS 类。
  • 为工作负载设置了内存限制，且限制等于或大于请求。
  • 敏感工作负载可能会设置 CPU 限制。

服务账号

• 避免使用 `default` ServiceAccount。相反，为每个工作负载或微服务创建 ServiceAccount。
• 除非 Pod 明确需要访问 Kubernetes API 才能运行，否则 `automountServiceAccountToken` 应设置为 `false`。

Pod 级别 `securityContext` 建议

• 设置 `runAsNonRoot: true`。
• 配置容器以非特权用户身份执行（例如，使用 `runAsUser` 和 `runAsGroup`），并配置容器镜像内文件或目录的适当权限。
• 可选地，使用 `fsGroup` 添加一个补充组以访问持久卷。
• 应用程序部署到强制执行适当Pod 安全标准的命名空间。如果无法控制应用程序部署的集群的此强制执行，则应通过文档或额外的深度防御来考虑这一点。

容器级别 `securityContext` 建议

• 使用 `allowPrivilegeEscalation: false` 禁用特权升级。
• 使用 `readOnlyRootFilesystem: true` 将根文件系统配置为只读。
• 避免运行特权容器（设置 `privileged: false`）。
• 从容器中删除所有能力，只添加容器操作所需的特定能力。

基于角色的访问控制 (RBAC)

• 只有在必要时才授予**创建**、**修补**、**更新**和**删除**等权限。
• 避免创建可导致特权升级的创建或更新角色的 RBAC 权限。
• 审查 `system:unauthenticated` 组的绑定，并在可能的情况下将其删除，因为这会允许任何能够在网络层面联系 API 服务器的人进行访问。

**创建**、**更新**和**删除**动词应谨慎允许。如果允许在命名空间上使用 **修补** 动词，可能会允许用户更新命名空间或部署上的标签，这会增加攻击面。

对于敏感工作负载，考虑提供一个推荐的 ValidatingAdmissionPolicy，以进一步限制允许的写入操作。

镜像安全

• 在 Kubernetes 集群中部署容器之前，使用镜像扫描工具扫描镜像。
• 在部署到 Kubernetes 集群之前，使用容器签名来验证容器镜像签名。

网络策略

• 配置NetworkPolicies以仅允许来自 Pod 的预期入站和出站流量。

确保你的集群提供并强制执行 NetworkPolicy。如果你正在编写一个用户将部署到不同集群的应用程序，请考虑是否可以假定 NetworkPolicy 可用并被强制执行。

高级安全强化

本指南的这一部分涵盖了一些高级安全强化点，这些点可能根据不同的 Kubernetes 环境设置而有价值。

Linux 容器安全

为 Pod 容器配置安全上下文。

• 为容器设置 Seccomp 配置文件.
• 使用 AppArmor 限制容器对资源的访问.
• 为容器分配 SELinux 标签.

运行时类

• 为容器配置适当的运行时类。

某些容器可能需要与集群默认运行时提供的隔离级别不同的隔离级别。`runtimeClassName` 可用于 Pod 规约中，以定义不同的运行时类。

对于敏感工作负载，考虑使用内核仿真工具，如 gVisor，或使用 kata-containers 等机制进行虚拟化隔离。

在高信任环境中，考虑使用机密虚拟机以进一步提高集群安全性。