【容器安全】保护kubernetes集群

本文档涵盖了与保护集群免受意外或恶意访问有关的主题，并提供了有关总体安全性的建议。

开始之前

• 
  您需要有一个Kubernetes集群，并且必须配置kubectl命令行工具才能与集群通信。建议在至少有两个节点不充当控制平面主机的集群上运行本教程。如果您还没有集群，您可以使用minikube创建一个集群，也可以使用以下Kubernetes游乐场之一：
  • Killercoda
  • Play with Kubernetes

要检查版本，请输入kubectl version。

控制对Kubernetes API的访问

由于Kubernetes完全由API驱动，控制和限制谁可以访问集群以及允许他们执行什么操作是第一道防线。

对所有API通信使用传输层安全性（TLS）

Kubernetes期望集群中的所有API通信默认使用TLS加密，并且大多数安装方法将允许创建必要的证书并将其分发到集群组件。请注意，某些组件和安装方法可能会通过HTTP启用本地端口，管理员应熟悉每个组件的设置，以识别潜在的不安全流量。

API身份验证

为API服务器选择一种身份验证机制，以便在安装群集时与常见访问模式相匹配。例如，小型单用户集群可能希望使用简单的证书或静态承载令牌方法。较大的集群可能希望集成现有的OIDC或LDAP服务器，以允许将用户细分为多个组。

所有API客户端都必须经过身份验证，即使是那些属于基础设施的客户端，如节点、代理、调度程序和卷插件。这些客户端通常是服务帐户或使用x509客户端证书，它们在集群启动时自动创建，或者作为集群安装的一部分进行设置。

有关详细信息，请参阅身份验证参考文档。

API授权

一旦通过了身份验证，每个API调用也将通过授权检查。Kubernetes提供了一个集成的基于角色的访问控制（RBAC）组件，该组件将传入的用户或组与绑定到角色中的一组权限相匹配。这些权限将谓词（get、create、delete）与资源（pod、服务、节点）相结合，可以是命名空间范围的，也可以是集群范围的。提供了一组现成的角色，根据客户端可能想要执行的操作提供合理的默认责任分离。建议您将Node和RBAC授权器与NodeRestriction准入插件结合使用。

与身份验证一样，简单而广泛的角色可能适用于较小的集群，但随着越来越多的用户与集群交互，可能有必要将团队划分为具有更有限角色的独立命名空间。

有了授权，了解一个对象的更新如何导致其他地方的操作是很重要的。例如，用户可能无法直接创建pod，但允许他们创建一个部署，代表他们创建pod，将允许他们间接创建这些pod。同样，从API中删除一个节点将导致调度到该节点的pods被终止，并在其他节点上重新创建。开箱即用的角色代表了灵活性和常见用例之间的平衡，但应仔细审查更有限的角色，以防止意外升级。如果开箱即用的角色不能满足您的需求，您可以为您的用例指定特定的角色。

有关更多信息，请参阅授权参考部分。

控制对Kubelet的访问

Kubelets公开HTTPS端点，这些端点授予对节点和容器的强大控制权。默认情况下，Kubelets允许未经身份验证的访问此API。

生产集群应启用Kubelet身份验证和授权。

有关更多信息，请参阅Kubelet身份验证/授权参考资料。

在运行时控制工作负载或用户的功能

Kubernetes中的授权是有意的高级别，专注于对资源的粗略操作。更强大的控件作为策略存在，通过用例限制这些对象对集群、它们自己和其他资源的作用。

限制群集上的资源使用情况

资源配额限制授予命名空间的资源数量或容量。这通常用于限制命名空间可以分配的CPU、内存或持久磁盘的数量，但也可以控制每个命名空间中存在的pod、服务或卷的数量。

限制范围限制上述某些资源的最大或最小大小，以防止用户为内存等常用保留资源请求不合理的高值或低值，或者在没有指定默认限制时提供默认限制。

控制容器运行的特权

pod定义包含一个安全上下文，允许它请求以特定Linux用户身份在节点上运行（如root）的访问权限、特权运行或访问主机网络的访问权限，以及其他允许它在主机节点上不受约束地运行的控件。

您可以配置Pod安全准入，以强制在命名空间中使用特定的Pod安全标准，或检测违规行为。

通常，大多数应用程序工作负载需要有限的主机资源访问权限，这样它们就可以作为根进程（uid 0）成功运行，而无需访问主机信息。但是，考虑到与根用户相关联的特权，您应该编写应用程序容器以作为非根用户运行。同样，希望防止客户端应用程序逃离其容器的管理员应应用基线或受限Pod安全标准

防止容器加载不需要的内核模块

如果在某些情况下需要，例如连接硬件或安装文件系统时，Linux内核会自动从磁盘加载内核模块。与Kubernetes特别相关的是，即使是没有特权的进程也可以通过创建适当类型的套接字来加载某些与网络协议相关的内核模块。这可能允许攻击者利用管理员认为未使用的内核模块中的安全漏洞进行攻击。

若要防止自动加载特定模块，可以从节点中卸载这些模块，或者添加规则来阻止它们。在大多数Linux发行版上，您可以创建一个文件，如/etc/modprobe.d/kubernetes-blacklist.conf，其中包含以下内容：

# DCCP is unlikely to be needed, has had multiple serious
# vulnerabilities, and is not well-maintained.
blacklist dccp

# SCTP is not used in most Kubernetes clusters, and has also had
# vulnerabilities in the past.
blacklist sctp

为了更一般地阻止模块加载，可以使用Linux安全模块（如SELinux）完全拒绝容器的module_request权限，从而防止内核在任何情况下为容器加载模块。（Pod仍然可以使用手动加载的模块，或者由内核代表一些更有特权的进程加载的模块。）

限制网络访问

命名空间的网络策略允许应用程序作者限制其他命名空间中的哪些pod可以访问其命名空间中的pod和端口。许多受支持的Kubernetes网络提供商现在都尊重网络策略。

配额和限制范围还可以用于控制用户是否可以请求节点端口或负载平衡服务，在许多集群上，负载平衡服务可以控制这些用户应用程序是否在集群外可见。

可以提供额外的保护，在每个插件或每个环境的基础上控制网络规则，例如每个节点的防火墙，物理隔离集群节点以防止串扰，或高级网络策略。

限制云元数据API访问

云平台（AWS、Azure、GCE等）经常在本地向实例公开元数据服务。默认情况下，这些API可由运行在实例上的pod访问，并且可以包含该节点的云凭据，或kubelet凭据等供应数据。这些凭据可用于在集群内升级或升级到同一帐户下的其他云服务。

在云平台上运行Kubernetes时，请限制对实例凭据的权限，使用网络策略限制pod对元数据API的访问，并避免使用供应数据传递机密。

控制pod可以访问哪些节点

默认情况下，对哪些节点可以运行pod没有任何限制。Kubernetes提供了一套丰富的策略，用于控制节点上pod的放置，以及最终用户可以使用的基于污染的pod放置和驱逐。对于许多集群来说，使用这些策略来分离工作负载可能是作者通过工具采用或强制执行的约定。

作为管理员，测试版准入插件PodNodeSelector可以用于强制命名空间内的pod默认或需要特定的节点选择器，如果最终用户无法更改命名空间，这可能会严重限制所有pod在特定工作负载中的位置。

保护群集组件不受损害

本节介绍了一些常见的保护集群不受损害的模式。

限制访问etcd

API对etcd后端的写访问相当于在整个集群上获得根，而读访问可以用于快速升级。管理员应始终使用从API服务器到其etcd服务器的强凭据，例如通过TLS客户端证书的相互身份验证，并且通常建议将etcd服务器隔离在只有API服务器可以访问的防火墙之后。

小心
允许集群中的其他组件以对完整密钥空间的读或写访问权限访问主etcd实例，相当于授予集群管理员访问权限。强烈建议对非主组件使用单独的etcd实例，或使用etcd ACL来限制对密钥空间子集的读写访问。
 

启用审核日志记录

审计记录器是一个测试版功能，它记录API采取的操作，以便在发生泄漏时进行后续分析。建议启用审核日志记录并将审核文件归档到安全服务器上。

限制对alpha或beta功能的访问

Alpha和beta Kubernetes功能正在积极开发中，可能存在导致安全漏洞的限制或漏洞。始终评估阿尔法或贝塔功能可能为您的安全态势带来的潜在风险提供的价值。如果有疑问，请禁用不使用的功能。

频繁轮换基础架构凭据

机密或凭据的生存期越短，攻击者就越难使用该凭据。设置证书的短寿命并自动轮换证书。使用身份验证提供程序，该提供程序可以控制已发行代币的可用时间，并尽可能使用短寿命。如果您在外部集成中使用服务帐户令牌，请计划频繁轮换这些令牌。例如，一旦引导阶段完成，用于设置节点的引导令牌就应该被吊销或删除其授权

在启用第三方集成之前，请先查看它们

许多到Kubernetes的第三方集成可能会更改集群的安全配置文件。启用集成时，在授予扩展访问权限之前，请始终检查扩展请求的权限。例如，许多安全集成可能会请求访问以查看集群上的所有机密，这实际上使该组件成为集群管理员。如果有疑问，请尽可能将集成限制为在单个命名空间中运行。

如果创建pod的组件可以在像kube系统命名空间这样的命名空间中这样做，那么它们也可能出乎意料地强大，因为如果这些服务帐户被授予访问许可PodSecurityPolicies的权限，这些pod可以获得对服务帐户密钥的访问权限，或者以提升的权限运行。

如果您使用Pod Security准入，并允许任何组件在允许特权Pod的命名空间内创建Pod，那么这些Pod可能能够逃离其容器，并使用这种扩展的访问来提升其特权。

您不应允许不受信任的组件在任何系统命名空间（名称以kube-开头的组件）中创建Pod，也不应允许在任何授予访问权限允许权限升级的命名空间中创建Pods。

静态加密机密

一般来说，etcd数据库将包含可通过Kubernetes API访问的任何信息，并可能使攻击者能够显著了解集群的状态。始终使用经过充分审查的备份和加密解决方案加密备份，并尽可能考虑使用全磁盘加密。

Kubernetes支持对Kubernetesneneneba API中的信息进行可选的静态加密。这可以确保当Kubernetes存储对象（例如Secret或ConfigMap对象）的数据时，API服务器会写入对象的加密表示。这种加密意味着，即使有权访问etcd备份数据的人也无法查看这些对象的内容。在Kubernetes 1.30中，您还可以加密自定义资源；CustomResourceDefinitions中定义的扩展API的静态加密已作为v1.26版本的一部分添加到Kubernetes中。

接收安全更新警报并报告漏洞

加入kubernetes公告群，获取有关安全公告的电子邮件。有关如何报告漏洞的更多信息，请参阅安全报告页面。

接下来是什么

有关Kubernetes安全指南的其他信息的安全检查表