Kubernetes 基于角色的访问控制良好实践

基于角色的访问控制良好实践

Kubernetes RBAC 是一项关键的安全控制，可确保集群用户和工作负载只能访问执行其角色所需的资源。 重要的是确保在为集群用户设计权限时，集群管理员了解可能发生权限提升的区域，以降低过度访问导致安全事件的风险。

一般良好做法

最低权限

理想情况下，应将最少的 RBAC 权限分配给用户和服务帐户。 仅应使用其操作明确要求的权限。 虽然每个集群都会有所不同，但可以应用的一些一般规则是：

• 尽可能在命名空间级别分配权限。使用 RoleBindings 而不是 ClusterRoleBindings 仅在特定命名空间内授予用户权限。
• 尽可能避免提供通配符权限，尤其是对所有资源。由于 Kubernetes 是一个可扩展的系统，提供通配符访问不仅可以授予集群中当前所有对象类型的权限，还可以授予将来创建的所有未来对象类型的权限。
• 除非特别需要，否则管理员不应使用​cluster-admin​帐户。提供具有模拟权限的低权限帐户可以避免意外修改集群资源。

• 避免将用户添加到 ​system:masters​ 组。作为该组成员的任何用户都会绕过所有 RBAC 权限检查，并且将始终拥有不受限制的超级用户访问权限，这不能通过删除角色绑定或集群角色绑定来撤销。顺便说一句，如果集群正在使用授权 webhook，则该组的成员身份也会绕过该 webhook（来自该组成员的用户的请求永远不会发送到 webhook）

尽量减少特权代币的分配

理想情况下，不应为 pod 分配被授予强大权限的服务帐户。 如果工作负载需要强大的权限，请考虑以下做法：

• 限制运行强大 pod 的节点数量。 确保您运行的任何 DaemonSet 都是必需的，并且以最小权限运行以限制容器逃逸的爆炸半径。
• 避免与不受信任或公开的 Pod 一起运行强大的 Pod。 考虑使用 Taints and Toleration、NodeAffinity 或 PodAntiAffinity 来确保 Pod 不会与不受信任或不太受信任的 Pod 一起运行。 特别注意可信度较低的 Pod 不符合 Restricted Pod 安全标准的情况。

Hardening

Kubernetes 默认提供并非每个集群都需要的访问权限。 查看默认提供的 RBAC 权限可以为安全加固提供机会。 通常，不应更改提供给系统的权限：帐户存在一些强化集群权限的选项：

• 查看 ​system:unauthenticated​ 组的绑定并在可能的情况下删除，因为这样可以访问可以在网络级别联系 API 服务器的任何人。
• 通过设置 ​automountServiceAccountToken: false​ 来避免默认自动挂载服务帐户令牌。为 Pod 设置此值将覆盖服务帐户设置，需要服务帐户令牌的工作负载仍然可以挂载它们。

定期审查

定期检查 Kubernetes RBAC 设置是否有冗余条目和可能的权限升级至关重要。 如果攻击者能够创建与已删除用户同名的用户帐户，他们可以自动继承已删除用户的所有权限，尤其是分配给该用户的权限。

Kubernetes RBAC - 提权风险

在 Kubernetes RBAC 中有许多权限，如果授予这些权限，则可以允许用户或服务帐户提升其在集群中的权限或影响集群外的系统。

本节旨在提供集群操作员应注意的区域的可见性，以确保他们不会无意中允许对集群的访问超出预期。

Listing secrets

通常很清楚，允许对 Secrets 的访问将允许用户阅读其内容。 同样重要的是要注意，​list​和​watch​访问也有效地允许用户透露秘密内容。 例如，当返回 List 响应时（例如，通过 ​kubectl get secrets -A -o yaml​），响应包括所有 Secrets 的内容。

工作负载创建

除非有基于 Kubernetes Pod 安全标准的限制，否则能够创建工作负载（Pod 或管理 Pod 的工作负载资源）的用户将能够访问底层节点。

可以运行特权 Pod 的用户可以使用该访问权限来获得节点访问权限，并可能进一步提升他们的权限。如果您不完全信任具有创建适当安全和隔离 Pod 的能力的用户或​​其他主体，则应强制执行基线或受限 Pod 安全标准。您可以使用 Pod 安全准入或其他（第三方）机制来实施该强制。

您还可以使用已弃用的 PodSecurityPolicy 机制来限制用户创建特权 Pod 的能力（注意，PodSecurityPolicy 计划在版本 1.25 中删除）。

在命名空间中创建工作负载还会授予对该命名空间中 Secret 的间接访问权限。在 kube-system 或类似特权的命名空间中创建一个 pod 可以授予用户对他们直接通过 RBAC 没有的 Secret 的访问权限

持久卷创建

对创建 PersistentVolume 的访问可以允许升级对底层主机的访问。 在需要访问持久存储的地方，受信任的管理员应该创建 PersistentVolume，并且受限用户应该使用 PersistentVolumeClaims 来访问该存储。

访问节点的代理子资源

有权访问节点对象的代理子资源的用户有权访问 Kubelet API，该 API 允许在他们有权访问的节点上的每个 pod 上执行命令。 此访问绕过审核日志记录和准入控制，因此在授予此资源权限之前应小心。

Escalate verb

通常，RBAC 系统会阻止用户创建比他们拥有的权限更多的集群角色。 一个例外是​escalate ​verb，拥有此权限的用户可以有效地提升他们的权限。

Bind verb

与​escalate ​verb类似，授予用户此权限允许绕过 Kubernetes 内置的针对权限升级的保护，允许用户创建与具有他们不具有的权限的角色的绑定。

Impersonate verb

此verb允许用户模拟并获得集群中其他用户的权限。 授予它时应小心，以确保不能通过模拟帐户之一获得过多的权限。

CSRs 和证书颁发

CSR API 允许具有 CSR 创建权限和更新​certificatesigningrequests/approval​权限的用户，其中签名者是 ​kubernetes.io/kube-apiserver-client​，以创建新的客户端证书，允许用户对集群进行身份验证。 这些客户端证书可以具有任意名称，包括 Kubernetes 系统组件的副本。 这将有效地允许特权升级。

Token请求

对 ​serviceaccounts/token​ 具有​create​权限的用户可以创建 TokenRequests 来为现有的服务帐户颁发令牌。

控制准入 webhook

控制验证​webhookconfigurations​或​mutatingwebhookconfigurations​的用户可以控制可以读取集群允许的任何对象的webhook，并且在改变webhook的情况下，也可以改变允许的对象。

Kubernetes RBAC - 拒绝服务风险

对象创建拒绝服务

有权在集群中创建对象的用户可能能够根据对象的大小或数量创建足够大的对象来创建拒绝服务条件，正如 Kubernetes 使用的 etcd 中所讨论的那样容易受到 OOM 攻击。 如果允许半受信任或不受信任的用户对系统进行有限访问，这可能与多租户集群特别相关。

缓解此问题的一种选择是使用资源配额来限制可以创建的对象数量。