应用安全清单

本清单旨在从开发者的角度，提供关于保护运行在 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)

• 仅在必要时才应授予诸如 create、patch、update 和 delete 之类的权限。
• 避免创建 RBAC 权限来创建或更新可能导致特权提升的角色。
• 审查 system:unauthenticated 组的绑定并尽可能移除它们，因为这会授予在网络层面可以访问 API 服务器的任何人访问权限。

应谨慎地允许 create、update 和 delete 动词。如果允许在命名空间上使用 patch 动词，则可能允许用户更新命名空间或部署上的标签，这会增加攻击面。

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

镜像安全

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

网络策略

• 配置网络策略，只允许 Pod 预期的入站和出站流量。

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

高级安全加固

本指南的此部分涵盖了一些可能对不同的 Kubernetes 环境设置有价值的高级安全加固点。

Linux 容器安全

配置 Pod-容器的Security Context。

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

运行时类

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

某些容器可能需要与集群默认运行时提供的隔离级别不同的隔离级别。可以在 podspec 中使用 runtimeClassName 来定义不同的运行时类。

对于敏感的工作负载，考虑使用内核模拟工具，例如 gVisor，或者使用诸如 kata-containers 之类的机制进行虚拟化隔离。

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