应用程序安全检查清单

此清单旨在从开发人员的角度提供有关保护在 Kubernetes 中运行的应用程序的基本指南。此列表并非详尽无遗，并且旨在随着时间的推移而发展。

关于如何阅读和使用本文档

• 主题的顺序并不反映优先级的顺序。
• 某些检查表项在每个部分列表下面的段落中详细说明。
• 此清单假定开发者是与命名空间范围对象交互的 Kubernetes 集群用户。

基本安全加固

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

应用程序设计

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

服务账户

• 避免使用default服务帐户。而是为每个工作负载或微服务创建服务帐户。
• automountServiceAccountToken 应该设置为 false，除非 Pod 特别需要访问 Kubernetes API 才能运行。

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 容器配置安全上下文。

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

运行时类

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

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

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

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