原文作者：Leonid Sandler

原文译自：CNCF（云原生基金会）

对于在共享基础架构上运行的容器化应用程序，安全性至关重要。随着越来越多的组织将其容器工作负载转移到 Kubernetes，K8s 已成为容器编排的首选平台。随着这一趋势的出现，越来越多的威胁和新的攻击方式需要加强所有安全层。

在 Kubernetes 中，安全性有两个方面：集群安全性和应用程序安全性。这篇文章，我们主要将探讨如何保护 ‌Kubernetes 部署和应用程序的安全。

复习基础知识

在这里快速回顾一下基础知识：Pod 是在集群中运行一个或多个容器的逻辑原子单元；它由其他资源包装，例如 ReplicaSet、Deployment、StatefulSets 等。有多种方法可以改善在 Kubernetes 中运行的应用程序的安全状况。

在 Kubernetes 部署中， 模板部分包含 pod 规范，这些规范定义了此部署必须运行的工作负载。在下面的模板中，几个与安全相关的部分以粗体突出显示：

现在，让我们仔细看看pod 规范中的这些内容。

服务帐号

当容器内的进程与 API 服务器通信时，您应该使用服务帐户进行身份验证。如果您没有为 pod 定义服务帐户，则将使用默认帐户。建议使用执行该功能所需的最低权限创建一个特定于应用程序的服务帐户。如果您选择将角色授予默认服务帐户，则这些权限将可用于未在规范中定义服务帐户的每个 pod。这可能会无意中允许对其他应用程序的过度许可，因此不建议这样做。在 Kubernetes 1.6 及更高版本中，您可以通过设置来选择不为容器中的服务帐户自动挂载 API 令牌。

虚拟防火墙

虚拟防火墙定义 pod 和容器中的权限和访问控制设置。以下是一些重要的列表：

• · seLinuxOptions (Security-Enhanced Linux)： 应用提供更精细访问和控制策略的机制
• · runAsUser和runAsGroup： 特定的UserID或GroupID（UID和GID）运行容器进程的入口点；如果未指定，则默认为用户在图像元数据中指定的（在 Windows 容器中均无效）。
• · privileged：以特权模式运行容器，默认为 false；与主机上的 root（具有所有功能）相同
• · runAsNonRoot： 容器必须以非 root 用户身份运行（如果 Kubelet 在运行时验证时 UID 为 0，则容器将无法启动）。
• · 能力： 在运行容器时添加或删除能力；容器运行时授予功能，这是默认设置。
• · procMount：指定容器的 proc 挂载类型，默认为 DefaultProcMount；这将容器运行时默认值用于只读和掩码路径。
• · AppArmor： 与 SELinux 类似，可以通过配置文件限制单个程序的功能。
• · seccompProfile： 容器使用的 secomp 选项；过滤进程的系统调用
• · readOnlyRootFilesystem： 将容器中的根文件系统挂载为只读；默认为假
• · AllowPrivilegeEscalation： 决定一个进程是否可以获得比其父进程更多的权限；如果容器以 Privileged 或具有 CAP_SYS_ADMIN 功能运行，则始终为 true。该字段必须显式设置为 false，因为它的默认行为可能会在 PSP 中更改。

Images

源Images通常取自各种公共存储库；开发人员将他们的应用程序代码放在这些基础镜像之上。您还可以直接从流行的公共注册中心部署 OOTB 应用程序。

关于Images，需要牢记三件事，下面我们一起讨论一下。

Image来源

确保是从受信任的注册表中获取Image。攻击者可以将恶意Image放置在公共注册表中，这反过来又会导致数据泄露或攻击者获得对集群的访问权等问题。许多公共Image也被发现被加密矿工感染。

作为一个组织，您可以创建基本映像的 golden images 并与开发人员共享它们，然后开发人员可以从他们的内部存储库中安全地使用它们。

Distroless 和容器优化镜像

这些Images安全且经过优化，可在容器中运行，从而减少了潜在攻击的表面积。它们仅包含应用程序和依赖库，而 Linux 操作系统上通常可用的包管理器、shell 和程序已被删除。

持续漏洞扫描

强烈建议实施持续的映像扫描，以检测容器映像中的漏洞、恶意软件和其他安全威胁（例如，未经授权连接到不受信任的网络）。有许多可用的安全解决方案，包括 Kubescape。

Pod安全许可

你可能听说过 Pod Security Policies，但是它现在已被弃用，将在 Kubernetes 1.25 中删除。 PodS 安全准入 (PSA) 将取代它来处理安全和其他与安全相关的要求。它为 pod 定义了不同的隔离级别，例如 privileged、baseline和 restricted。截至 Kubernetes 1.23，PSA 目前处于测试阶段。

这些级别在 Kubernetes 的 Pod 安全标准中有详细描述，但下面是 Kubernetes 自己的文档的摘要：

Pod Security 准入与内置的 Pod Security 准入控制器配合使用；您需要在集群中使用 –feature-gates=”...,PodSecurity=true” 或使用 pod admission webhook启用此功能。它应用于 命名空间级别，带有以下标签：

在命名空间中，使用以下注解启用 Pod 安全准入：

使用秘密

如果在应用程序中有可用的敏感信息（如凭证、令牌、加密密钥和证书），请使用 Kubernetes Secrets。可以使用文字值或文件创建 Secret，然后将它们挂载到 pod 中。不要将此类信息存储在容器映像和 Git 存储库中。

使用 Secrets 时，最好不要使用环境变量将凭据投影到容器中，而是使用文件。

请记住，Secrets 是 base64 编码的值。它们未加密，因此必须限制对安全对象的访问，并且应该在 API 服务器的写入时启用加密。

结论

Kubernetes 提供了多种方法来改善集群的安全状况。开发人员需要考虑如何利用这些结构来使应用程序更安全。

回顾一下：

• 1. 每个应用程序使用服务帐户，并将服务帐户与最低角色和权限要求绑定，以实现目标。
• 2. 如果应用程序不需要服务帐户令牌，请不要自动挂载它。
• 3. 使用虚拟防火墙来实现各种技术，例如防止容器在特权模式下以 root 用户身份运行，使用 SELinux 或 AppArmor 配置文件等等。
• 4. 确保容器镜像的来源是可信的，如果可以的话，将它们存储在私有注册表中。
• 5. 尝试使用容器优化的图像来减少表面积以最大程度地减少威胁。
• 6. 部署持续的漏洞扫描解决方案，不仅在 CI/CD 中，而且在集群中，可以实时监控和采取行动。
• 7. 使用 Pod 安全准入配置文件和模型为工作负载提供不同的隔离级别。
• 8. 使用 Secrets 存储敏感信息，并应用最低权限 RBAC 来限制用户/SA 秘密访问。

希望本文对您有所帮助……