Kubernetes 安全：来自行业和社区的 10 个最佳实践

Kubernetes 安全的 10 个最佳实践

1. 不要在环境变量中保守秘密

让您的对象在环境变量中使用秘密是一个很好的做法，因为系统的其他部分可以访问环境变量。这就是为什么最好将机密用作文件或利用 SecretKeyRef 来最大程度地减少潜在攻击。

2. 使用强 Kubernetes 身份验证和授权

将 Kubernetes 与第三方身份验证提供商集成是明智的，因为它提供了额外的安全功能，例如多因素身份验证。避免在 API 服务器级别管理用户，以使对控制平面的访问更加安全。如果您正在运行 EKS、GKE、AKS 或类似服务等托管 Kubernetes 服务，请使用云服务提供商提供的身份和访问管理 (IAM) 解决方案。如果 CSP IAM 不可行，请选择 OpenID Connect (OIDC) 以及您习惯的 SSO 提供商。  

3.禁用NET_RAW功能

如果您的 K8s 容器不放弃 NET_RAW 功能，您将面临在集群内启用各种网络漏洞的风险。最好使用策略执行解决方案，例如开放策略代理、Kyverno 或 Kubernetes Pod 安全准入控制器，以确保您遵循最佳实践。在 pod 的 securityContext 定义中对 ALL 或 NET_RAW 功能使用 drop 以确保禁用 NET_RAW 功能。

4.避免共享主机的IPC或网络命名空间 

检查您的 Pod 是否共享主机的 IPC 或网络命名空间。为 Pod 和主机进程间通信共享命名空间可能会导致开放对共享信息的访问。不应允许 Pod 访问主机命名空间。 

共享 pod 和主机网络命名空间可以从 pod 访问主机网络，从而打破网络隔离。这就是为什么你最好在 PodSecurityPolicy 中将 hostNetwork 参数设置为 false。

5.使用 Kubernetes 基于角色的访问控制（RBAC）

RBAC 有助于定义谁有权访问 Kubernetes API 以及哪些权限。在 Kubernetes 1.6 及更高版本中，RBAC 通常默认启用。由于 Kubernetes 结合了授权控制器，因此请确保在启用 RBAC 时禁用旧版基于属性的访问控制 (ABAC)。

选择命名空间特定的权限而不是集群范围的权限。即使在调试时，也不要授予集群管理员权限。否则，您的容器安全可能会受到损害。

6.避免使用根文件系统来保证容器安全

您的容器是否在没有只读根文件系统的情况下运行？使用只读文件系统可以防止恶意二进制文件写入系统或攻击者接管系统。您可以通过在 Pod securityContext 定义中将 readOnlyRootFilesystem 设置为 true 来确保容器仅使用只读文件系统。 

7. 隔离您的 Kubernetes 节点

Kubernetes 节点永远不应该直接暴露于公共网络。理想情况下，这些节点位于单独的网络上，并且如果可能的话，没有与一般公司网络的任何直接连接。 

您可以通过隔离 Kubernetes 控制和数据流量来实现这一点。否则，它们都流经同一管道。对数据平面的开放访问意味着对控制平面的访问也开放。使用入口控制器配置节点，并将其设置为仅允许通过网络访问控制列表 (ACL) 通过指定端口从主节点进行连接。

8.避免在特权模式下运行容器

您的部署是否有在特权（根）模式下运行的容器？这允许容器访问主机的关键资源。避免在特权模式下运行容器或启用 podSecurityPolicy，并将特权参数设置为 false。这将确保容器无法运行需要主机上 root 权限的进程。

9. 检查不安全/Proc 挂载

使用不安全 /proc 挂载 (procMount=Unmasked) 的部署将允许绕过容器运行时的默认屏蔽行为。设置具有 Unmasked /proc 挂载类型的容器可能会将主机信息暴露给容器，从而导致潜在的信息泄漏或容器逃逸。设置 procMount=Default 以确保容器不会不安全地暴露 /proc 的任何部分。

10.制定滚动更新策略

另一个明智之举是制定滚动更新策略。滚动更新允许部署更新通过使用新的 Pod 实例增量更新来最大限度地减少应用程序停机时间。有关更多详细信息，请参阅Kubernetes 文档中的此页面。

实现 Kubernetes 安全性具有挑战性

Kubernetes 生态系统在不断变化，其安全性和配置部分也在不断变化。跟上这些变化需要时间和精力，这会分散工程师的注意力，让他们无法专注于其他任务。