RBAC Kubernetes 最佳安保通常

「引言」

Kubernetes 是一个开源的容器编排平台，用于智能化部署、裁减和控制容器化运行程序。它提供了丰盛的性能，如服务发现、负载平衡、智能缩放等。随着 Kubernetes 在云原生畛域的宽泛运行， 「有效控制谁可以对 Kubernetes 集群口头何种操作变得至关关键」 。本文将简明引见 Kubernetes的认证与授权体系以及RBAC授权原理。经过实践案例展现RBAC控制不当或许造成的安保风险，而后向大家分享RBAC安保研发与运维的最佳通常，以及咱们在字节跳动外部的安保防护和控制阅历。

背景常识

本章节将对 Kubernetes 的认证和授权体系启动概述，了解这些机制的原理有助于了解不同场景下集群权限的安保风险。特意是那些能够被随便应用的未授权访问破绽，以及那些容易被漠视的权限优化与横向移动攻打风险。

Kubernetes 认证与授权体系

Kubernetes 的认证与授权体系关键用于满足对关键服务 API（API Server、Kubelet Server）的访问控制。在经过多年的开展后，Kubernetes 曾经成功了一套比拟完善的认证与授权机制，可以满足用户大少数场景的经常使用需求。

「API Server」

Kubernetes 是一个以容器技术为基础，以申明式 API Server 为外围的散布式容器编排系统。Kubernetes 简直一切的性能都经过 API Server 对外暴露。而 API Server 支持了多种认证机制，内置了多种授权形式和准入控制器，准许用户依据须要灵敏性能和经常使用。

便捷来说，当一个用户访问 Kubernetes 的 API Server 时，API Server 会经常使用启用的认证器依次对恳求启出发份认证，API Server 经常使用第一个成功认证的身份来标识恳求者；而后再经常使用启用的授权器依次对恳求启动授权战略的审核，当有恣意一个授权器显式地准许、拒绝一个恳求时，则立刻前往授权结果（假设没有授权器显式地授权，那么恳求也将被拒绝）。除此之外，在 API Server 真正处置恳求前，它还会经常使用启用的准入控制器对恳求进一步变异和验证。只要一切的准入控制器都验证经事先，恳求才会被真正处置。

「KubeletServer」

Kubernetes 中还有一个十分关键的组件，那就是 Kubelet。它充任了散布式系统中的 Agent 角色，并经常使用节点专属的用户证书访问 API Server，控制节点上的资源。但 Kubelet 自身也会作为服务端，对外提供服务。从而实如今容器外口头命令、失掉目的消息、容器日志、宿服务器日志等性能。

Kubernetes 也为 Kubelet Server 提供了多种认证和授权形式。值得一提的是其中的 webhook 认证和 webhook 授权，它们实质上是向 API Server 发送 TokenReview 和 SubjectAccessReview 恳求，对客户端的身份启动认证与授权。

「小结」

Kubernetes 为 API Server 和 Kubelet Server 支持了多种认证机制、授权机制、准入控制器，以及灵敏的自定义接口。这些机制虽然能够满足各种用户需求，但也给用户带来了困扰。由于假设不了解这些机制的原理和负面影响，就很容易为集群引入安保风险和入侵检测盲点。特意是那些能够被随便应用的未授权访问破绽，以及那些容易被漠视的提权与横向移动攻打风险。

请参见附录和参考文献，了解更多 API Server 和 Kubelet Server 的认证、授权、准入控制的技术细节。

Kubernetes RBAC 授权原理

RBAC 是 Kubernetes 自动启用的授权机制，也是 Kubernetes 外围组件所经常使用的授权机制。用户在经常使用集群时，往往须要经常使用 RBAC 授权机制来为其用户账号授权，以便部署、运维上班负载及所需的各种资源。各类云原生运行的 Operator、Controller 往往也须要应用 RBAC 授权机制来为其服务账户授权，以确保它们能够访问必要的资源，从而成功其性能。

上方的示用意展现了用户账号和服务账号访问 API Server 时的认证、授权、准入控制环节。

在 Kubernetes 的 RBAC 授权体系中，引入了以下几种概念：

「Role & ClusterRole」

「Role & ClusterRoleBinding」

由以上可知，和 ClusterRole 内的代表一系列显式授予的权限，听从 Deny-by-Default 安保模型。由于不支持 "deny" 规定，因此不支持显式的扫除某些权限。

这一特点使得某些运行场景不可应用 RBAC 授权机制成功：在授予一切已知、未知 CRD 资源操作权限的同时，显式地扫除某些敏感权限。但咱们可以借助 ABAC、Webhook 授权形式，联合准入控制器来为此类场景的服务账号启动权限控制，从而缓解这类疑问。

上方是一个经过 RBAC 授权机制为 ServiceAccount 绑定权限的示例：

apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:name: example-clusterrolenamespace: example-nsrules:- apiGroups:- appsresources:- daemonsets- deployments- replicasets- statefulsetsresourcesNames:- testverbs:- '*'- nonResourceURLs:- /healthz- /healthz/*verbs:- get---apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:name: example-rolebindingnamespace: example-nsroleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: example-clusterrolesubjects:- kind: ServiceAccountname: example-sanamespace: example-ns

RBAC 安保风险剖析

Kubernetes 是一个散布式的容器编排系统。除了要确保 Kubernetes 基础组件的性能安保（例如 API Server、Kubelet Server 基本的认证授权性能等，对应 CIS Kubernetes Benchmark 中的第一至第四章中的要求）外，咱们还须要对其 RBAC 授权性能启动精细化控制。

正确的授予主体 RBAC 权限能够防止为集群引入不用要的稳固性 & 安保性风险，而不失当的权限设置或许造成敏感数据暴露、资源滥用、权限优化，甚至要挟整个集群的安保。接上去咱们将借助文献和案例来进一步说明其安保风险。

概述

在 Kubernetes 中，可以经过对资源的操作来成功消息窃取、权限优化、横向移动等攻打。例如可以应用 pods/exec 资源的 create 权限经过 API Server 在指定容器外口头恣意命令，也可以应用 nodes/proxy 资源的 create 权限间接访问 Kubelet Server 在指定容器外口头恣意命令，还可以应用 pods 的 create 权限创立具备安保风险的容器、应用 pods 的 patch 权限在指定 Pod 的容器外口头代码...... 「随着 Kubernetes 的宽泛经常使用，此类风险在云厂商、PaaS平台、云原生运行、SaaS产品中愈演愈烈，轻则被用于后浸透入侵，重则会给产品引入安保破绽。」

Palo Alto Networks 的安保钻研员深化剖析了 Kubernetes 中的一切敏感权限，并依据其危害类型将其分类和分级[2]（重大等级请参考开源名目 rbac-police 的风险权限扫描战略集）。如下图所示，在这些敏感权限中，有许多都可以被攻打者用于消息走漏、权限优化、横向移动等攻打，最终成功整个集群的接收。

Palo Alto Networks 的钻研结果标明，在针对干流私有云、CNI 厂商的剖析中，有将近 50% 的厂商存在容器逃逸后随便造成集群失陷的安保疑问。另外有 25% 的厂商存在容器逃逸后在必定条件下造成集群失陷的安保风险[2]。

地下案例

风险示例

上方的示例演示了攻打者可以应用恣意 secrets 的 create 权限，来失掉了蕴含敏感权限的 ServiceAccount（这里以窃取 prometheus-agent SA 的 token 为例）的 token。对此，咱们倡导经常使用公用命名空间中的 Role 来定义所需权限，从而与 kube-system 等敏感命名空距离离。

上方的示例演示了攻打者可以应用恣意 secrets 的 get 权限，来爆破失掉保留 SA token 的 secrets。虽然爆破 SA token 须要较长期间（爆破一个领有 5 个随机字符串的 SA token 最多须要 27^5 次），但此权限也或许被用于窃取其他已知称号的 secrets 资源。对此，咱们倡导经常使用 Role 定义角色，或许经过 resourceNames 对 secrets 的权限范围启动解放，而非授予所有命名空间中恣意 secrets 的 get 权限。

以上数据和案例标明，Kubernetes RBAC 权限控制已成为一个必定仔细看待并及时采取有效进攻措施的安保疑问。

RBAC 安保研发与运维最佳通常

基于咱们在字节跳动外部的安保通常，咱们为 RBAC 授权性能总结了如下准则，以指引大家启动 Kubernetes RBAC 权限控制，从而降落由此为集群引入的安保风险。

遵照最小权限准则

在 RBAC 角色中调配权限时，请遵照最小权限准则授予口头义务所需的最低权限。例如：

RBAC 权限最小化不应被视作“非黑即白”，哪怕组件的某些敏感权限不可收敛，最小化权限依然对降落风险、参与入侵检测的机率有关键作用。

防止经常使用自动角色/用户/用户组

普通状况下，Kubernetes 和基于 Kubernetes 的 PaaS 平台会智能将一些自动角色绑定到自动用户和用户组，以保证系统的反常运转。如需检查 Kubernetes 创立的自动角色和绑定的完整列表，请参阅 Default roles and role bindings。

大局部自动角色（例如 cluster-admin, edit, system:node 等）都会被授予较宽泛的权限。因此，咱们 「不倡导」 将自动角色绑定到服务账号，除非您知道并接受由此带来的安保风险。用户可以依据实践须要将其绑定到用户账号上。

除此之外，咱们 「应当防止」 为系统用户（例如 system:anonymous, system:serviceaccounts:NAMESPACE:default 等）、系统用户组（例如 system:authenticated, system:serviceaccounts 等）绑定额外的角色，这会造成权限的非预期分散，引入重大的安保风险。

防止为 default 服务账号授予权限

在附录 1 的“准入控制机制”一节中，咱们提到了自动启用的 ServiceAccount 准入控制器。创立 Pod 时假设未指定 ServiceAccount，那么 ServiceAccount 准入控制器会将命名空间内名为 default 的 ServiceAccount 调配给 Pod。

因此，咱们 「应当防止」 为 default 服务账号授予权限，这会造成非预期的权限暴露。

尽量防止经常使用通配符

字符是一个实用于一切内容的通配符， 「应尽量防止」 在规定中经常使用通配符。这容易形成授权范围过大，除非您明白通晓并接受此行为或许引入的安保风险。倡导您在 RBAC 规定中明白指定 API 组（apiGroups）、资源（resources）、动词（verbs），甚至是资源称号（resourceNames）。

例如，在字段中指定将授予、、、、、 deletecollection 和等权限。下表举例说明了如何防止在规定中经常使用通配符。

尽量防止经常使用敏感权限

设计角色前，请先细心评价存在权限优化、命令口头、消息走漏等安保风险的权限。例如 secrets 的操作权限、证书签发权限、pods/exec 访问权限等，更多请参考 Kubernetes RBAC - privilege escalation risks和 风险权限扫描战略集。

为运行服务、控制组件授予敏感权限会给整个集群引入安保风险。在系统设计和开发时， 「应尽量防止」 经常使用它们，并配合其他手腕启动安保编排、安保加固和入侵检测。

尽量经常使用独自规定对特定资源授予权限

规划规定时，倡导您尝试以下简明步骤，在每个角色中驳回更高效、可读、易于保养的规定设计[4]：

这种方法可成功更有条理的规定设计，将对多个资源授予相革命词的规定组合起来，将为资源授予不同动词的规定彼此分散[4]。

例如，假设您的上班负载须要失掉 deployments 资源的权限，但须要 daemonsets 资源的和权限，则您应该在创立角色是经常使用独自规定。当您将 RBAC 角色绑定到上班负载时，该角色将不可对 deployments 资源启动操作[4]。

再举一例，假设您的上班负载须要资源和 daemonsets 资源的和权限，您可以将它们组分解一条规定，由于上班负载须要在这两个资源上经常使用相反的动词[4]。

在下表中，这两种规定设计均有效，但拆分规定会依据须要更精细地限度资源访问权限[4]。

安保编排与其它

有些场景下，业务需求或许与安保要求发生抵触。例如一些运行必需某些敏感权限才可以反常运转或提供必要性能。对此，咱们倡导您思考采取以下安保编排、纵深进攻战略来尽量降落风险。

「经常使用公用命名空间」

「制订不凡调度战略」

「独自部署敏感组件」

「树立纵深进攻」

RBAC 安保防护与控制通常

在许多企业中，往往会由于安保看法无余、云原生安保树立展开较晚、经常使用开源云原生运行等要素，曾经为系统引入了少量 RBAC 权限风险。但由于触及基础设备，并且缺乏相应的常识和手腕，针对这类风险的防护和控制往往充溢应战。接上去笔者将向大家引见咱们在字节跳动外部的一些阅历和通常，抛砖引玉供大家参考。

全体思绪

经过地下案例和红蓝演练等形式，向研发团队展现 K8s RBAC 失误性能抵消费环境安保性和稳固性形成的危害。与 DevOps 团队在风险认知上达成分歧，从而自上而下对齐控制目的。在展开控制上班前，应依据企业的实践状况制勘误当的方案。同时，安保团队应提供控制所需的常识库、工具和系统，与 Ops 团队构建适宜的控制流程，以确保控制上班顺利推进。此外，安保团队还应继续增强反入侵才干树立，为 K8s RBAC 等安保风险提供兜底保证。

制订方案

制订实际可行的方案，以及提供必要的工具与系统，是收敛 K8s RBAC 安保风险的关键前提和保证。

「数据驱动」

「明白优先级」

「增量管控 & 存量整改」

防护与控制框架

在字节外部，咱们构建了如下图所示的安保防护和控制框架，并推进了权限控制上班。

在开发与集成阶段，咱们借助最佳安保通常来指点研发部门启动安保的 RBAC 权限设计和开发。并在局部 CI/CD 流水线中集成了安保扫描，对存在风险 RBAC 性能的 chart 产物启动阻拦、告警和记载。

在部署阶段，咱们经过与 PaaS 平台集成的准入控制机制、K8s 准入控制器来对合法的运行和资源启动增量管控。并指点关键业务经过安保编排等手腕来降落具备敏感权限的控制组件的安保风险。这里咱们基于开源名目 Kyverno 的战略引擎，成功了 Policy as Code。从而在流水线安保扫描、准入控制中成功战略兼容，降落了安保战略的保养老本。

在运转阶段，咱们经过活期扫描（基于开源名目 rbac-police）来继续识别风险。此外，咱们还设计成功了针对服务账号和用户账号的行为建模才干。此才干基于账户行为来生成最小权限的角色定义，为组件的权限收敛提供参考。由于不是一切的敏感权限都能失掉整改，因此，在通常中咱们会基于 K8s 的审计日志启动入侵检测，从而发现潜在的攻打行为。

经过以上机制，咱们构建了针对 K8s RBAC 安保风险的防护和控制框架，为字节外部大规模消费集群的 RBAC 安保控制和防护提供了必要才干。

总结

RBAC 是 Kubernetes 中的一项关键的授权机制，正确地性能 RBAC 关于保证基于 Kubernetes 的系统安保至关关键。在设计中，咱们应遵照最小权限准则启动权限设计，并了解敏感权限的安保风险，为其引入必要的防护才干。在开发中，咱们要留意防止适度授权、权限凌乱等疑问。在安保防护和运营中，咱们还要平衡安保要求和业务需求，继续收敛安保风险，树立纵深进攻体系。

宿愿本文能让大家更好地理解 Kubernetes 的权限体系，了解 RBAC 授权形式的安保风险和最佳安保通常，从而指点系统的安保设计、开发和防护，最终构建愈加安保牢靠的系统。

参考文献