【容器安全】Kubernetes 安全检查列表

该清单旨在提供一份基本的指导清单，并链接到每个主题的更全面的文档。它并不声称是详尽无遗的，而是要不断发展。

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

• 专题的顺序并不反映优先次序。
• 一些检查表项目在每一节列表下面的段落中有详细说明。

小心
检查清单本身不足以达到良好的安全态势。一个良好的安全态势需要不断的关注和改进，但检查表可以成为安全准备
无休止旅程的第一步。对于您的特定安全需求，本清单中的一些建议可能过于严格或过于宽松。由于Kubernetes的
安全性不是“一刀切”的，因此应该根据其优点来评估每一类检查表项目。
 

身份验证和授权

• 系统：引导后，master组不用于用户或组件身份验证。
• kube控制器管理器在启用了--use服务帐户凭据的情况下运行。
• 根证书受到保护（脱机CA或具有有效访问控制的托管联机CA）。
• 中间证书和叶子证书的有效期在未来不超过3年。
• 存在定期访问审查的流程，审查间隔不超过24个月。
• 遵循“基于角色的访问控制良好实践”以获得与身份验证和授权相关的指导。
   

在引导之后，用户和组件都不应该作为system:masters向Kubernetes API进行身份验证。类似地，应避免将所有kube控制器管理器作为系统：主机运行。事实上，system:masters应该只作为一个打破玻璃的机制使用，而不是管理员用户。

网络安全

• 使用中的CNI插件支持网络策略。
• 入口和出口网络策略应用于集群中的所有工作负载。
• 每个命名空间中的默认网络策略，选择所有pod，拒绝一切，都已就位。
• 如果合适，将使用服务网格对集群内的所有通信进行加密。
• Kubernetes API、kubelet API和etcd未在互联网上公开发布。
• 过滤工作负载对云元数据API的访问。
• LoadBalancer和ExternalIP的使用受到限制。

许多容器网络接口（CNI）插件插件提供了限制pod可以通信的网络资源的功能。这通常是通过网络策略来完成的，网络策略提供了一个名称空间的资源来定义规则。默认网络策略阻止所有出口和入口，在每个命名空间中，选择所有pod，这对于采用允许列表方法非常有用，可以确保不会遗漏任何工作负载。

并非所有CNI插件都在传输过程中提供加密。如果所选的插件缺少此功能，则可以使用服务网格来提供该功能。

控制平面的etcd数据存储应该具有限制访问的控制，并且不在互联网上公开。此外，应使用双向TLS（mTLS）与其进行安全通信。此证书颁发机构应是etcd唯一的。

应限制对Kubernetes API服务器的外部互联网访问，以避免公开API。注意，许多托管Kubernetes发行版默认公开API服务器。然后，您可以使用堡垒主机访问服务器。

kubelet API访问应该受到限制，并且不公开，当没有使用--config标志指定配置文件时，默认的身份验证和授权设置过于宽松。

如果云提供商用于托管Kubernetes，则如果不需要，也应限制或阻止pods对云元数据API 169.254.169.254的访问，因为这可能会泄露信息。

有关限制使用LoadBalancer和ExternalIP的信息，请参阅CVE-2020-8554：使用LoadBalancir或ExternalIP的中间人和DenyServiceExternalIP准入控制器以了解更多信息。

Pod安全

• 只有在必要时才授予RBAC创建、更新、修补和删除工作负载的权限。
• 适当的Pod安全标准策略适用于所有命名空间并强制执行。
• 内存限制是为限制等于或低于请求的工作负载设置的。
• 可能会在敏感工作负载上设置CPU限制。
• 对于支持Seccomp的节点，会为程序启用适当的系统调用配置文件。
• 对于支持它的节点，AppArmor或SELinux会为程序启用适当的配置文件。

RBAC授权是至关重要的，但其粒度不足以对Pods的资源（或管理Pods的任何资源）进行授权。唯一的粒度是资源本身上的API谓词，例如在Pods上创建。在没有额外许可的情况下，创建这些资源的授权允许直接无限制地访问集群的可调度节点。

Pod安全标准定义了三种不同的策略，特权、基线和限制，这些策略限制了如何在PodSpec中设置有关安全的字段。这些标准可以通过默认启用的新Pod Security准入或第三方准入webhook在命名空间级别强制执行。请注意，与它所取代的已删除的PodSecurityPolicy准入相反，PodSecurity准入可以很容易地与准入Webhook和外部服务相结合。

Pod安全准入限制策略是Pod安全标准集中限制性最强的策略，可以在多种模式下运行，警告、审计或强制执行，以根据安全最佳实践逐步应用最合适的安全上下文。然而，对于特定的用例，应该单独调查pod的安全上下文，以限制pod在预定义的安全标准之上可能具有的权限和访问权限。

有关Pod Security的实践教程，请参阅博客文章Kubernetes 1.23:Pod Security Graduates to Beta。

应设置内存和CPU限制，以限制pod在节点上可能消耗的内存和CPU资源，从而防止恶意或破坏的工作负载可能引发的DoS攻击。这样的策略可以由准入控制器强制执行。请注意，CPU限制会限制使用量，因此可能会对自动缩放功能或效率产生意想不到的影响，即使用可用的CPU资源尽最大努力运行进程。

小心
高于请求的内存限制可能会使整个节点暴露在OOM问题中。

启用Seccomp

Seccomp代表安全计算模式，自2.6.12版本以来一直是Linux内核的一个功能。它可以用来对进程的权限进行沙盒处理，限制它从用户空间到内核的调用。Kubernetes允许您将加载到节点上的seccomp配置文件自动应用到Pods和容器。

Seccomp可以通过减少容器内可用的Linux内核系统调用攻击面来提高工作负载的安全性。seccomp过滤器模式利用BPF创建一个允许或拒绝特定系统调用的列表，命名为概要文件。

自Kubernetes 1.27以来，您可以启用RuntimeDefault作为所有工作负载的默认seccomp配置文件。本主题提供了安全教程。此外，Kubernetes Security Profiles Operator是一个促进集群中seccomp管理和使用的项目。

笔记
Seccomp仅在Linux节点上可用。

启用AppArmor或SELinux

AppArmor

AppArmor是一个Linux内核安全模块，它可以提供一种简单的方法来实现强制访问控制（MAC），并通过系统日志进行更好的审计。默认的AppArmor配置文件在支持它的节点上强制执行，或者可以配置自定义配置文件。与seccomp一样，AppArmor也通过配置文件进行配置，其中每个配置文件要么以强制模式运行，这会阻止对不允许的资源的访问，要么以投诉模式运行，只报告违规行为。AppArmor配置文件是在每个容器的基础上强制执行的，带有注释，允许进程获得正确的权限。

笔记
AppArmor仅在Linux节点上可用，并在某些Linux发行版中启用。

SELinux

SELinux也是一个Linux内核安全模块，它可以提供一种机制来支持访问控制安全策略，包括强制访问控制（MAC）。SELinux标签可以通过容器或pod的securityContext部分分配给它们。

笔记
SELinux仅在Linux节点上可用，并在某些Linux发行版中启用。

日志和审核

审核日志（如果启用）受到保护，不受一般访问。
 

吊舱放置

• 播客的放置是根据应用程序的敏感度级别进行的。
• 敏感应用程序在节点上独立运行，或者使用特定的沙盒运行时运行。

位于不同敏感层的pod，例如应用程序pod和Kubernetes API服务器，应该部署到单独的节点上。节点隔离的目的是防止应用程序容器突破，以直接提供对具有更高敏感度的应用程序的访问，从而在集群内轻松进行数据透视。应该强制执行这种分离，以防止pod意外部署到同一节点上。这可以通过以下功能来实现：

节点选择器

键值对，作为pod规范的一部分，用于指定要部署到的节点。这些可以通过PodNodeSelector准入控制器在命名空间和集群级别强制执行。

吊舱容限

允许管理员限制命名空间内允许的容忍度的准入控制器。命名空间内的Pod只能使用在命名空间对象注释键上指定的容忍度，这些注释键提供了一组默认和允许的容忍度。
 

运行时类

RuntimeClass是一个用于选择容器运行时配置的功能。容器运行时配置用于运行Pod的容器，并且可以以性能开销为代价提供或多或少与主机的隔离。
 

秘密

• ConfigMaps不用于保存机密数据。
• 已为机密API配置静止加密。
• 如果适当，将部署并提供一种机制来注入存储在第三方存储中的机密。
• 服务帐户令牌不会安装在不需要它们的pod中。
• 绑定服务帐户令牌卷正在使用，而不是未过期的令牌。

pod所需的秘密应该存储在Kubernetes Secrets中，而不是像ConfigMap这样的替代方案。存储在etcd中的秘密资源应在静止时加密。

需要秘密的播客应该通过卷自动安装这些秘密，最好像emptyDir.medium选项一样存储在内存中。该机制还可以用于将机密作为卷从第三方存储注入，如机密存储CSI驱动程序。与提供pods服务帐户RBAC对机密的访问相比，这应该优先进行。这将允许将机密作为环境变量或文件添加到pod中。请注意，与文件的权限机制相比，由于日志中的崩溃转储和Linux中环境变量的非机密性，环境变量方法可能更容易发生泄漏。

服务帐户令牌不应安装到不需要它们的pod中。这可以通过在服务帐户内将automountServiceAccountToken设置为false来配置，以应用于整个命名空间或专门用于pod。对于Kubernetes v1.22及更高版本，请使用绑定服务帐户作为有时限的服务帐户凭据。

镜像

• 尽量减少容器图像中不必要的内容。
• 容器映像配置为以无特权用户身份运行。
• 通过sha256摘要（而不是标签）引用容器图像，或者通过准入控制在部署时验证图像的数字签名来验证图像的来源。
• 在创建和部署过程中定期扫描容器映像，并修补已知的易受攻击的软件。

容器映像应该包含运行它们打包的程序的最低限度。优选地，只有程序及其依赖性，从尽可能小的基础上构建图像。特别是，生产中使用的映像不应包含shell或调试实用程序，因为可以使用临时调试容器进行故障排除。

使用Dockerfile中的user指令，构建图像以直接从无特权用户开始。安全上下文允许使用runAsUser和runAsGroup以特定用户和组启动容器映像，即使在映像清单中未指定。但是，图像层中的文件权限可能会使您无法在不修改图像的情况下使用新的无特权用户启动进程。

避免使用图像标记引用图像，尤其是最新的标记，标记后面的图像可以在注册表中轻松修改。优选使用完整的sha256摘要，该摘要对于图像清单是唯一的。此策略可以通过ImagePolicyWebhook强制执行。还可以在部署时使用准入控制器自动验证图像签名，以验证其真实性和完整性。

扫描容器映像可以防止关键漏洞与容器映像一起部署到集群中。图像扫描应在将容器映像部署到集群之前完成，通常作为CI/CD管道中部署过程的一部分完成。图像扫描的目的是获取有关容器图像中可能存在的漏洞及其预防的信息，例如通用漏洞评分系统（CVSS）评分。如果图像扫描的结果与管道符合性规则相结合，则只有经过适当修补的容器图像才会进入生产。

准入控制器

• 允许适当选择准入控制器。
• 吊舱安全策略由吊舱安全准入或/和webhook准入控制器强制执行。
• 准入链插件和webhook配置安全。

准入控制器可以帮助提高集群的安全性。然而，当它们扩展API服务器时，它们本身可能会带来风险，并且应该得到适当的保护。

以下列表提供了一些准入控制器，这些控制器可以用来增强集群和应用程序的安全态势。它包括可在本文件其他部分参考的控制器。

第一组准入控制器包括默认启用的插件，除非您知道自己在做什么，否则请考虑保持启用状态：

证书批准

执行额外的授权检查，以确保批准用户具有批准证书申请的权限。
 

证书签名

执行额外的授权检查，以确保签名用户有权对证书请求进行签名。
 

证书主题限制

拒绝任何指定系统：master的“组”（或“组织属性”）的证书请求。
 

LimitRanger

强制执行LimitRange API约束。
 

突变准入Webhook

允许通过Webhook使用自定义控制器，这些控制器可能会更改它审查的请求。
 

PodSecurity

Pod安全策略的替换，限制已部署Pod的安全上下文。
 

资源配额

强制执行资源配额以防止资源过度使用。
 

验证AdmissionWebhook

允许通过Webhook使用自定义控制器，这些控制器不会更改它审查的请求。
第二组包括默认情况下未启用但处于通用状态的插件，建议用于改善您的安全状况：

拒绝服务外部IP

拒绝Service.spec.externalIP字段的所有净新使用。这是对CVE-2020-8554的缓解措施：使用LoadBalancer或ExternalIP的中间人。

节点限制

限制kubelet的权限仅修改其拥有的pods API资源或代表其自身的节点API资源。它还防止kubelet使用node-restriction.kubernetes.io/annotation，攻击者可以访问kubelet的凭据来影响pod在受控节点上的位置。
第三组包括默认情况下未启用但可用于某些用例的插件：

AlwaysPullImages

强制使用已标记映像的最新版本，并确保部署人员具有使用该映像的权限。
 

ImagePolicyWebhook

允许通过webhook对图像执行附加控件。
 

接下来是什么

• 通过Pod创建的权限提升警告您特定的访问控制风险；检查一下你是如何应对这种威胁的。
  • 如果您使用Kubernetes RBAC，请阅读RBAC良好实践以了解有关授权的更多信息。
• 保护群集以获取有关保护群集免受意外或恶意访问的信息。
• 群集多租户指南，介绍多租户的配置选项建议和最佳实践。
• 博客文章“更深入地了解NSA/CISA Kubernetes强化指南”，了解关于强化Kubernete集群的补充资源。