原文白皮书
https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms起初是看到POH Team的这篇谷歌云漏洞赏金计划2022Top7案例学习参考；其中5th Prize: Kubernetes Privilege Escalation: Excessive Permissions in Popular Platforms；这是一篇来自paloalto的白皮书。并没有直接描述漏洞或者安全问题，但是其揭示了诸多提供Kubernetes服务的公有云厂商在pods失陷后与特权下的”DaemonSets”容器产生的权限提升的火花，并给出了kubernetes权限配置安全合理性的检测工具；Google认为这对于Kubernetes生态有所裨益，因此给出了$17311的奖励
前言
近年来越来越多的用户部署和使用，k8s使用量猛增。不安全的默认配置是新兴复杂平台典型的成长阵痛，k8s也是。但现在大多数k8s平台已经根除不安全的默认配置，之前广泛存在的未授权错误配置（例如未授权的kubelet访问）已经越来越少见。习惯通过简单的攻击来破坏集群的攻击者们可能对此提升不太满意，但务实的攻击者们开始着手目标针对更微妙的问题。
Unit 42团队最近在野目睹了这种趋势，因为它们捕获了Siloscape样本，一个迄今最复杂的k8s恶意软件样本，它将多个漏洞连接在一起，以危害Pod，逃逸并接管Node，最终获取整个集群的控制权。这个样本演示了一种以前从未在野见过的方法：在破坏一个node节点后，它会检查节点是否有过多权限，如果没有就不会继续攻击。
随着相对简单的k8s攻击失去关联性，攻击者开始瞄准过多权限和RBAC错误配置。
Kubernetes 基于角色的访问控制 (RBAC) 是 Kubernetes 中的主要授权⽅案，管理用户、组、pod 和节点对 Kubernetes 资源的权限
K8s RBAC配置具有强制最小权限访问以避免攻击者的能力，但错误配置很容易被忽视。看似受限的权限通常有强大的功能，如这个基本的问题“哪些Pods可以提升权限？”很难回答。在本报告中旨在解决这个问题。我们引入一个框架，该框架根据强大的权限所引发的攻击对它们进行分类；有数十个最强大的k8s权限映射；并发布rbac-police，这是一个开源工具可以识别K8s集群中高权限和提权路径。
为了解高权限的普遍性和影响，我们分析了流行的 Kubernetes 平台——托管服务、发行、CNI——寻找以过多权限运行的基础设施组件。在检查的62.5%的k8s平台中，强大的DaemonSet在集群中每个节点上发布了高权限凭证。因此在50%的平台中，单个容器逃逸就足以危及整个集群。
DaemonSet 通常用于将基础设施 Pod 部署到所有工作节点上。
我们与受影响的平台合作解决这些问题并剥夺过多的权限。原来运行强大DaemonSet的62.5%只剩下25%。同样，容器逃逸肯定会导致集群接管的平台百分比从 50% 下降到仅 25%，而且很快还会有更多平台出现这种情况。虽然这朝着正确的方向发展，但 RBAC 错误配置和过多的权限在不久的将来可能仍然是 Kubernetes 的重大安全风险。
请继续阅读，以更好地了解RBAC风险以及如何通过开源⼯具和最佳实践配置来解决这些风险。学习将 RBAC 从盲点转变为额外的防御层。
执行摘要
近年来，Kubernetes 平台在安全性方面取得了重大进展，消除了严重的错误配置并建立了安全基线。由于容易受到直接攻击的集群越来越少，威胁行为者开始适应并寻找滥用更微妙问题的技术。最近的恶意软件样本表明Kubernetes 威胁参与者开始针对过多的权限。
Kubernetes基于角色的访问控制(RBAC) 是⼀种授权方案，用于管理用户、组、服务账户和 pod 对 Kubernetes 资源的权限。如果使用得当，RBAC 可以强制执行最低权限的访问并使攻击者失望。如果配置错误，过多的权限会使集群面临权限升级攻击，并增加受损凭证和容器逃逸的影响范围。
RBAC错误配置很容易被忽略
看似受限的权限可能非常强大，在某些情况下，与集群管理相当。因此，开源附加组件和基础设施组件会无意中请求强大的权限，而用户在没有意识到对其集群安全性的全面影响的情况下授予了这些权限。
Prisma® Cloud 研究人员确定了数十种强大的 Kubernetes 权限（已知的和新颖的），并根据它们引发的攻击将它们分类为五种主要的 Kubernetes 攻击类型。
高权限广泛存在
为了了解强大权限的普遍性，Prisma Cloud 研究人员分析了流行的 Kubernetes 平台（托管服务、发行版和容器网络接口 (CNI)），以识别强大的 DaemonSet，这些 DaemonSet 可以在集群中的每个节点上分发强大的凭据。
在检查的 Kubernetes 发行版和托管服务中，75% 默认运行强大的 DaemonSet。其余 25% 的人在启用推荐功能的情况下也这样做了。检查主流容器网络接口(CNI)，50% 默认安装强大的 DaemonSet。
过多权限导致影响大的攻击
当松散地授予强大的权限时，它们更有可能落入坏人之手。在Kubernetes中。这可能以多种方式发生，但通过强大的DaemonSet和容器逃逸最容易看到。
当强大的 DaemonSets 在每个节点上分配强大的令牌时，容器逃逸的危害范围会急剧增加。根据已识别的DaemonSet，在所审查的50%的Kubernetes平台中，单个容器逃逸足以危及整个集群。
在 12.5% 的平台中，单个容器逃逸可能足以接管一些集群。对于另外 12.5% 的人来说，如果启用了推荐的功能，容器逃逸足以危及整个集群。
图 2：所分析的 Kubernetes 平台中容器逃逸的影响
RBAC错误配置是可解决的
Prisma Cloud 研究人员与供应商和开源项目合作，剥离过多的权限并减少强大凭据的分发。原来运行强大DaemonSet的62.5%只剩下25%。同样，容器逃逸保证导致集群接管的平台数量从50%下降到仅25%。这表明RBAC错误配置是可以解决的，并且强⼤的权限通常可以被删除。它还强调了受审查的供应商和开源项目对其平台安全的承诺。
为了帮助 Kubernetes 用户评估和改善其集群的RBAC状况，本报告与rbac-police一起发布，一个新的开源工具，可以识别Kubernetes集群中强大的权限和特权升级路径。新的RBAC检查也贡献给了Checkov，领先的开源基础设施即代码(IaC)扫描器。
最后，“建议”部分探讨了⼀些最佳实践，这些最佳实践可以减少强大凭据的分发并限制受损凭据的传播半径，以及可以实时检测和防止权限升级攻击的准入策略。
基于角色的访问控制101
Kubernetes RBAC 是⼀种授权方案，用于管理对 Kubernetes 资源的访问。权限分为 Roles 或 ClusterRoles，并且可以通过 RoleBindings 或 ClusterRoleBindings 授予用户、组和服务账号。通过 RoleBindings 授予的权限仅限于命名空间，而通过 ClusterRoleBindings 授予的权限实际上在集群范围内有效。
例如，下面的 ClusterRoleBinding 将“pod-reader”ClusterRole 授予“read er-sa”服务账号SA。
“reader-sa”服务现在账号已被授权执行“pod-reader”ClusterRole 中list的操作。
如上所示，K8s权限可以通过规则来表达，每个规则允许对一个或多个API组中一个或多个资源，执行一个或多个动作。上述规则允许在核心API组中list列举和get获取pod。常见的动作动词包括：
• get: retrieve a resource by name 根据名称检索资源
• list: retrieve all resources 检索全部资源
• create: create a resource 创建资源
• update: replace an existing resource 替换现有资源
• patch: modify an existing resource 修改现有资源
• delete: delete a resource 删除资源
如图3所示，可以通过将Role和ClusterRole(也就是权限)绑定到Pod的服务账号来授予Pod权限。分配了”reader-sa”服务账号的Pod能够检索集群范围内的pod。
对高k8s权限进行分类
攻击者可能会滥用某些 Kubernetes 权限来升级权限、横向移动或获得对集群更广泛的控制。从现在开始，这些将被称为“强大的权限”。
一些强大的权限几乎相当于集群管理员，而其他权限只能在特定场景下滥用以进行有限的攻击。为了在讨论强大的权限时建立一个通用框架，我们根据它们所引发的攻击将它们分为五种攻击类型。
当涉及到强大的权限时，范围是关键。当在整个集群上授予权限时，权限可以与管理员等效，但当范围仅限于命名空间或特定资源名称时，权限是无害的。为了包含所有可能的强大权限，上表假设在集群范围内授予权限。
某些强大的权限会引发多种攻击，因此会映射到多个攻击类别。另一方面，一些更复杂的攻击需要结合列出的权限才能执行。不足以自行发起攻击的权限被标记为黄色。
为了避免不成比例的膨胀，表 1 汇总了类似的动作和资源。更新update和补丁patch动作聚合为虚拟的“modify”修改动词，而修改modify和创建create则组合称为”control”控制。 DaemonSets、Deployments、CronJobs 和其他 pod 控制器被视为pod controller “pod 控制器”。因此，对 Pod 控制器的写权限表示为⼀个虚拟的“control pod controller” “控制 Pod 控制器”权限，而不是实际的 21 种相关权限（例如，创建Deployment、更新update Deployment、修补patch Deployment、创建 CronJobs 等）。
表 1 不可能包含 Kubernetes 中的所有强大权限，但它是我们所知的最完整的列表。还值得注意的是，我们还没有研究其他“较弱”的攻击类别，例如拒绝服务 (DoS)。
以下是每个攻击类别的细分。
Acquire Tokens(获取Tokens)
该组包含允许直接或间接检索retrieve或颁发issue服务账号SA令牌的权限。决定这些权限影响的主要因素是它们的范围，无论它们是否是通过拥有强大服务账号的特权命名空间授予的。默认情况下唯⼀具有特权的命名空间是 kube-system，但某些平台可能会安装其他特权命名空间。
权限包括：create pods(创建pods)，create secrets(创建secrets)，list secrets，update Deployment(更新Deployment)，create serviceAccount/token(创建SA或token)
攻击示例
在 kube-system 命名空间中拥有 create serviceAccounts/token 权限的攻击者可以通过 TokenRequests为预装的强大服务账号颁发新令牌。
远程代码执行
该组中的权限允许在 Pod 上执行代码，也可能在节点上执行代码。攻击者不⼀定会通过滥用这些权限来提升权限——这取决于受攻击的 Pod 或节点的权限。尽管如此，这些权限仍然会增加计算资源，并可能增加攻击者控制下的业务逻辑。
权限包括：create pods/exec, create nodes/proxy, patch DaemonSets, create pods
攻击示例
拥有 create pods/exec 权限的攻击者可以在其他 pod 上执行代码，例如通过 kubectl exec 提供的接口。
操作身份认证/授权Authentication/Authorization (AuthN/AuthZ)
该组中的权限允许操作身份验证和授权。它们通常通过设计为授予权限或模拟其他身份等用例启用权限升级。它们非常强大，用户在授予它们时应格外小心。
攻击示例
可以绑定clusterrolebinding的攻击者可以将预安装的集群管理员cluster-admin这个cluster role集群角色授予其失陷的身份。
Steal Pods——窃取Pod
某些权限或权限组合可能允许攻击者将 Pod 从一个节点窃取到另一个节点。为了使这种攻击产生影响，攻击者必须⾸先破坏他打算放置被盗 Pod 的节点。窃取 Pod 包含两个步骤：驱逐 Pod，然后确保它落在您的节点上。为了最⼤限度地发挥影响，攻击者会使用强大的服务账号令牌来瞄准 Pod。
一项相似的攻击——影响未来Pod调度——在报告中没有包含。
权限包括： update nodes, create pods/eviction, delete pods, update nodes/status
更新node、创建Pod/驱逐、删除Pod、更新节点/状态
攻击示例
破坏节点并拥有更新节点权限的攻击者可以从其他节点窃取 Pod 到其受损节点上。通过向目标节点添加具有 NoExecute 效果的污点，攻击者可以强制 Kubernetes 驱逐并重新调度目标节点的 pod。通过向所有其他节点添加具有 NoSchedule 效果的污点，攻击者可以确保将被逐出的 Pod 重新安排到其受感染的节点上。
值得注意的是，容忍 NoExecute 污点的 pod 不能通过这种技术被窃取。这些 Pod 并不常见，但⼀个流行的例子是 Calico 安装的相当于管理员的“tigera-Operator”Pod。
据我们所知，利用NoExecute污点窃取 Pod 是一种新颖的攻击技术。
Meddler-in-the-Middle——中间人攻击
该组中的权限可能允许攻击者对集群中的 Pod、节点或服务发起中间人攻击。利用该组中的权限通常需要一些先决条件才能产生相对较弱的影响。此外，使用TLS 保护通信可以消除大多数中间人攻击。
权限包括：update services/status, control endpointslices, patch pods/status
攻击示例
拥有update services/status更新服务/状态权限的攻击者可以利⽤CVE-2020-8554通过负载均衡器 IP 将 Pod 和节点发送的流量从其预期目标重定向到现有端点。攻击者必须控制现有端点才能成为有意义的攻击。
容器逃逸和强大的DaemonSet:有毒的组合
当强大的权限被宽松授予时，它们更有可能落入坏人之手。在 Kubernetes 中，这可能以多种方式发生，但通过强大的 DaemonSet 和容器逃逸(container escape)最容易看到。
当强大的 DaemonSet 在集群中的每个节点上分发强大的令牌时，容器逃逸的利用危害会急剧增加。安装了强大的 DaemonSets 后，成功逃离容器的攻击者⼀定会中大奖——在受感染的节点上获得强大的凭据。
我们使⽤“Trampoline pods”作为强大pods的同义词。这个名字表明了它们的影响：设法破坏 Trampoline Pod 或其节点的攻击者可以滥用其令牌在集群中横向，破坏其他节点并获得更高的权限。并非所有Trampoline pods都提供相同的弹力。根据权限的不同，某些权限可能允许攻击者危害整个集群，而其他权限则可能仅在某些情况下被滥用。
运行一些功能强大的Pod是合理的。强大的权限存在是有原因的：有时需要它们。不作为 DaemonSet 的⼀部分运行的强大 pod 可以通过多种方法（在“Recommendations”建议中描述）与不受信任和公开暴露的 pod 隔离。即使没有积极采取措施隔离它们，非DaemonSet Trampolines 也不太可能出现在特定的受感染节点上。
Trampoline DaemonSets 之所以成为安全问题的主要原因是强大凭证的分发。借助强大的 DaemonSet，集群中的每个节点都拥有强大的凭据，这意味着成功逃脱容器的攻击者一定能在受感染的节点上找到强大的令牌。
节点默认不是powerful吗？
如果没有强大的 DaemonSet，节点上唯一可用的集群凭据属于节点代理——Kubelet。2017 年，Kubernetes 通过发布NodeRestriction解决了源于Kubelet权限的权限提升攻击准入控制器。NodeRestriction将Kubelet的权限限制为已绑定到其节点的资源，例如在其之上运行的Pod。因此，node无法提升权限或成为集群管理员，因此如果没有 Trampoline Pod，容器逃逸不足以接管整个集群。
值得注意的是，NodeRestiction 并不完美 – Kubelet 仍然可以读取大多数集群对象、绕过出口网络策略、发起某些拒绝服务 (DoS) 攻击，甚至对 pod 支持的服务发起 Meddler 中间人攻击。虽然这些都是可能的，但重要的是要区分哪些权限可以对某些配置进行低严重性攻击，哪些权限可以可靠地滥用以升级权限并危害集群。
下⼀节将介绍流行Kubernetes 平台中的 Trampoline DaemonSet。如果 DaemonSet 只启⽤低严重性或不可靠的攻击（包括 Kubelet 可以独立执行的攻击），我们并不认为 DaemonSet 很强大。只有当守护进程的权限实际上可以导致整个集群受到损害时，它们才被认为是强大的。
流行Kubernetes平台中强大的DaemonSet
为了了解强大权限的普遍性和现实世界的影响，Prisma Cloud 研究人员分析了八种流行的 Kubernetes 平台，并寻找以强大权限运行的 DaemonSet。表2：被分析的8个k8s平台
在检查的 Kubernetes 平台中，62.5% 默认安装了强大的 DaemonSet，而另外 12.5% 的平台也启用了推荐功能。图8：分析的8个 Kubernetes 平台中流行的 DaemonSet
表3：被分析的k8s平台中强大的DaemonSet
容器逃逸影响范围
根据已确定的强大DaemonSet，在 50% 的 Kubernetes 平台中，审查的单个容器逃逸足以危及整个集群。另外 12.5% 的情况下，容器逃逸可能足以接管⼀些集群。对于 12.5% 的平台来说，如果启用了推荐的功能，容器逃逸就足以危及整个集群。图9：所分析的k8s平台中容器逃逸的影响
在某些平台中，DaemonSet 拥有与管理员等效的权限，这意味着滥用它们来获取管理员权限非常简单。在其他平台中，DaemonSet 的功能不足以自行成为完全管理员，但它们确实拥有允许接管其他 Pod 的权限。在大多数这些平台中，由于默认安装了与管理员等效的 Pod，因此攻击者仍然可以滥用平台的 DaemonSet 来获取管理员权限。
例如，在 Antrea 中，antrea-agent DaemonSet 的功能不足以单独获得管理员权限，但它确实拥有强大的权限，可以接管其他 pod。由于 Antrea 默认安装了⼀个与管理员等效的 pod，因此 antrea-controller、antrea-agent 的权限仍然可能被利用，通过滥用它们来危害 antrea-controller pod 来获取管理员权限。
表4：容器逃逸对分析平台的影响
如果您的集群依赖于受影响的平台之一，请不要惊慌。原因如下：
- 要滥用强大的 DaemonSet，攻击者首先需要妥协，然后逃离容器。
- 一些平台已经发布了取消强大DaemonSet 特权的版本。
- 最佳实践强化可以防止某些攻击。例如，容器镜像的允许列表策略可以阻止横向移动攻击，这些攻击滥用更新pod“patch Pod”权限，用攻击者控制的镜像替换现有 Pod 的映像。
- 话虽如此，如果您运行多租户集群，您将面临更大的风险。
“Escape == Admin”列中的“在某些集群中可能”表示容器逃逸的先决条件足以危害整个集群，但在某些集群中很可能会满足。例如，攻击者滥用可以窃取 Pod 的强大DaemonSet，只有在集群中存在可窃取的管理员权限的 Pod 时，才能获取集群管理员权限。
例如，在 EKS 中，默认情况下没有这样的 pod。尽管如此，根据安装管理等效 pod 的流行 Kubernetes 附加组件的绝对数量，许多野外集群很可能满足这个先决条件。默认情况下安装相当于 admin 的 pod 的⼀些流行项目包括 ingress-nginx、cert-manager、Kynvero、traefik 和 aws-load-balancer。
值得注意的是，Cilium 有两种流行的安装方法。上表适用于默认记录的 cilium-cli。虽然默认的 Helm 安装也部署了同样强大的 DaemonSet 来接管其他 pod，但它没有部署可以作为其目标的管理等效 pod。因此，当通过 Helm 安装 Cilium 时，考虑到用户安装了相当于管理员的 pod（或者换句话说，“可能在某些集群中”），容器逃逸仅足以危及整个集群。
流行平台中强大的Kubelet
虽然大多数 Kubernetes 发行版和托管服务都采用了 NodeRestriction 准入控制器，但有些仍然运行功能强大的
Kubelet。强大的 Kubelet 引入了与强大的 DaemonSet 相同的安全风险。受损的节点可以提升权限并接管集群的其余部分。
以下是所分析的托管服务和发行版中功能强大的 Kubelet 的细分。
受影响平台的修复和缓解措施
我们在 2021 年 12 月至 2022 年 2 月期间向受影响的供应商和开源项目报告了已识别的强大DaemonSet 和 Kubelet。绝大多数平台承诺剥夺其 Daemonst 的强大权限，其中⼀些平台已经这样做了。从原来的 62.5%，现在只剩下 25% 仍然运行强大的 DaemonSets。
平台通过各种技术来处理强大的 DaemonSet。大多数人应用了以下三种解决方案中的一种或多种：
1.删除：某些权限被认为是不必要的，或者范围太广，因此被简单地删除
2.重新放置：将需要强大权限的功能从在所有节点上运行的 DaemonSet 移动到在少数节点上运行的部署或控制平面。
3.限制：发布准入策略，将强大的 DaemonSet 限制为一些安全且预期的操作。
根据上述改进，单个容器逃逸足以危及整个集群的平台数量从 50% 下降到仅 25%。请记住，这个数字与 Kubernetes 原生攻击有关，不包括可能的针对特定平台的权限提升。
剥夺现有权限可能具有挑战性。我们要感谢本报告中提到的供应商和开源项目，感谢他们为从其平台上删除强大的 DaemonSet 和 Kubelet 所做的努力。
实现更好的Node隔离
Kubernetes 正在一步步向更强的节点隔离迈进。这项工作从 NodeRestriction 准入控制器开始，并随着从流行的 DaemonSet 中删除每个强大的权限而缓慢推进。在不久的将来，完全的节点隔离是不太可能的：一些低严重性的攻击可能会继续存在，并且某些节点将需要托管强大的 Pod。话虽如此，更好的节点隔离当然是可能的。至少，集群不应在每个节点上托管强大的凭据。删除 Trampoline DaemonSet 可以确保大多数节点没有特权。
一些强大的权限将更难删除，部分原因是某些操作缺乏细粒度的访问控制。但这不应该被视为“全有或全无”的问题。即使某些权限无法轻易剥夺，但当以前可以获取管理令牌的 DaemonSet 现在只能发起中间人攻击时，这仍然是一个值得欢迎的改进。
识别高权限
无论您是否使用上述平台，如果您运行 Kubernetes，您的集群都可能托管功能强大（高权限）的 Pod。解决有风险的权限的第一步是识别它们。以下工具可用于识别正在运行的集群和 Kubernetes 清单中的强大权限。
rbac-police
我们很高兴发布rbac-police，我们在整个研究中使用的工具来识别强大的权限。
rbac-police 是一个用Golang 编写的开源命令行界面 (CLI)，它检索集群中 pod、节点和服务账号的权限，并通过内置或自定义 Rego 策略对其进行评估。评估集群的 RBAC 状态就像运行rbac-police eval lib⼀样简单。
下图显示了 rbac-police 输出的一部分：图 11： rbac-police 针对服务账户、Pod 和节点权限过多发出警报
rbac-police 开箱即用，配备了 20 多个策略，每个策略都会寻找一组不同的强大权限。不过它也是 100% 可定制的。您可以编写自己的策略来搜索 Kubernetes RBAC 中的任何模式 ——我们忽略的强大权限、仅影响某些平台的权限或与 CRD （(Custom Resources Definitions自定义资源定义）相关的权限。如果您最终编写了政策，请考虑贡献它。
rbac-police支持的命令如下：
-
rbac-police eval通过内置或自定义Rego 策略评估服务账户、Pod 和节点的RBAC 权限。 -
rbac-police collect检索集群中服务账户、Pod 和节点的RBAC权限。对于保存集群的 RBAC 快照以使⽤不同选项进行多次评估非常有用。 -
rbac-police expand呈现服务账户、pod 和节点的 RBAC 权限以稍微更人性化的格式。对于手动深层探究很有用
对于微调评估，rbac-police 提供了多种选项，包括：
-
--only-sa-on-all-nodes仅评估所有节点上存在的服务账户。对强大的 DaemonSets⾝份识别很有用 -
--namespace, --ignored-namespaces将评估范围限定为单个命名空间；忽略某些命名空间 -
--severity-threshold仅评估严重性等于或大于阈值的策略。
此外，rbac-police 还支持评估节点有效权限的策略——其 Kubelet 权限和 pod 权限的联合。一些更复杂的攻击需要许多权限才能执行。因此，虽然没有⼀个 pod 拥有执行攻击所需的所有权限，但节点上的 pod 组合可能拥有执行攻击所需的所有权限。
查看 rbac-police 的GitHub页面了解更多信息。如果您运行 Kubernetes，请考虑尝试⼀下。它只需几秒钟即可运行，并提供有关 RBAC 状态和可能风险的许多有价值的见解。
Checkov
checkov是 Bridgecrew 的⼀款开源静态代码分析工具，用于扫描基础架构即代码 (IaC) 文件以查找可能导致安全或合规性问题的错误配置。 Checkov 通过在错误配置提交到生产环境之前发出警报来左移安全能力。
我们贡献了4个新的RBAC检查，对包含定义了高权限的角色或集群角色发出告警：CKV_K8S_155、CKV_K8S_156、CKV_K8S_157 和 CKV_K8S_158
这些重点关注可以被滥用以操作身份认证和授权(如impersonation模拟)的高权限。
Checkov目前正在添加对图形检查的支持，可以评估多个 Kubernetes 资源之间的连接。该功能发布后，预计会添加更多 RBAC 检查。
查看Checkov网站了解更多信息
建议
处理高权限RBAC可能很复杂，因为它们很容易被忽略，且经常被第三方附加组件或底层基础设置访问。即使你管理功能强大的组件，删除权限也并不总是那么简单，通常涉及代码更改。
无论运行k8s集群或者维护流行的k8s项目，以下都是可以改善您的RBAC状态的最佳实践和强化措施
-
遵循最小权限原则：仅分配明确需要的权限
a.如果可能，用RoleBinding角色绑定来对某个命名空间下赋予权限而不是集群范围。
b.用资源名称resourceNames缩小特定资源的权限范围
-
跟踪强大的的权限并且保证它们不被授予不太受信任或公开暴露的Pod。如果要维护k8s项目，需要详细记录平台要求的高权限。
-
避免运行高权限的 DaemonSet：
a. 将需要强大权限的功能从所有节点上运行的 DaemonSet 移至在少数或控制平面控制上运行deployment
b. 依赖 Kubelet 凭证来执行仅涉及绑定到本地节点的对象的操作，例如检索相邻 Pod 的secrets。
c. 通过在CRDs和ConfigMaps中的状态存储来最小化写入权限，而不是在核心对象如Pod中
-
使用调度约束将强大的 pod 与不受信任或公开暴露的 pod 隔离，例如污点和容忍制度，NodeAffinity规则，或PodAntiAfinity规则
-
配置policy controller 策略控制器对自动身份发出告警（例如通过SelfSubjectReviews API查询权限的SA和node）
-
配置策略控制器以检测或防止滥用强大权限进行恶意活动。滥用强大权限通常与正常使用不同。有关更多详细信息，请参阅下面的示例。
通过准入控制检测攻击
通常，受损的凭证会表现出不常规的行为，并为防御者提供识别违规行为的机会。在 Kubernetes 中，准入控制可以检测并防止由受损凭证和特权权限发起的攻击。 OPA Gatekeeper和Kynvero等策略控制器可以强制执行策略，阻止或警告对 Kubernetes API 的可疑请求。以下是使用OPA Gatekeeper 的此方法的两个示例。
可疑的SefSubjectReview
凭据盗窃后的常见攻击者模式是查询系统以获取其权限。在 Kubernetes 中，这是通过 SelfSubjectAccessReview 或 SelfSubjectRulesReview API 完成的。非人类身份（例如 serviceAccounts 和查询这些 API 权限的节点）是妥协的强烈迹象。检测这些请求的策略提供了捕获受损凭据的绝佳机会。
这是⼀个策略示例 用于检测此类查询的OPA Gatekeeper。
控制器服务账户SA的可疑分配
默认情况下，kube-system 命名空间托管多个与管理员等效的服务账户，这些账户由作为 api-server 的⼀部分运行的控制器使用。可以在 kube-system 命名空间中创建 pod 或 pod 控制器，或者修改 kube-system 命名空间中的 pod 控制器的攻击者，可以将这些与管理员等效的服务账号之⼀分配给他们控制的 pod，并滥用其强大的令牌来获得集群的完全控制。
在前面介绍的”对高权限k8s权限分类””Classifying Powerful Kubernetes Permissions”框架中，这种攻击被分类在Acquire Tokens获取令牌中。
控制器服务账户通常不会分配给正在运行的 Pod。防御者可以利用这一点来检测这种权限提升攻击，并通过策略对将控制器服务账户附加到现有的或新kube-system pod 的请求发出警报。我们为 OPA Gatekeeper 编写了一个示例，可以在此获取
结论
正如本报告所述，过多的 RBAC 权限很常见，很容易被忽视，并且可能导致针对 Kubernetes 集群的影响较大的权限提升攻击。同时，强化的 RBAC 设置可以强制执行最低权限、阻止意外访问并挫伤攻击者的士气。
由于 Kubernetes 的动态特性以及通常用于操作现代集群的第三方插件的数量，保持安全的 RBAC 状态具有挑战性。有关rbac-police等工具，请参阅“识别高权限”部分，它可以评估您的 RBAC 状态，并参阅“建议”部分，了解即使集群中仍然存在一些强大的 pod，也可以最大限度地降低风险并阻止攻击的方法。
我们要感谢本报告中提到的供应商和开源项目的合作以及他们为最大限度地减少平台上强大凭证的分发所做努力。
附录A: 按照攻击类别划分的高权限
Manipulate Authentication/Authorization (AuthN/AuthZ)
操作身份认证/授权
模拟用户/组/服务账号SA
模拟其他身份，例如用户、组、服务账号SA
role/cluster role提权
向现有role/clusterrole添加任意权限
绑定rolebinding/clusterrole binding
将现有的role/cluster role授予任意身份
批准signer&更新证书签名请求/批准
approve signers & update certificatesigningrequests/approval
Have an existing signer approve a certificatesigningrequest.
让现有签名者批准证书签名请求
控制修改webhooks
修改已授权的角色或集群角色。
指的是在 Kubernetes 的准入过程中能够对资源进行操作或修改的能力。当在 Kubernetes 中创建或修改资源时，准入控制器可以拦截请求，并在允许请求继续之前应用额外的逻辑或修改。
在这个上下文中，”修改已授权的角色和集群角色”意味着”变异的”Webhook 能够修改已授权或允许特定资源的角色和集群角色。这使得 Webhook 能够根据特定条件或要求动态修改与资源相关的权限和访问控制设置。
Acquire Tokens获取令牌
list secrets
检索命名空间中现有服务账号SA的服务账号令牌SA token。
这项攻击在将来通过Kubernetes增强提案(KEP)2799来解决：减少基于服务账号Token的Secret
create secrets
为现有服务账号下发新的服务账号令牌。
create ServiceAccount/Token
通过TokenRequests为现有服务账号下发临时服务账号Token
create pods
将现有服务账号分配给新的Pod，允许该Pod获取其Token。或者，将现有服务账号令牌的secret token作为环境变量或卷挂载到新的Pod中
控制Pod Controller
将现有的服务账号分配给新的或已存在的Pod，允许这些pod访问Token。或者，将现有服务账号令牌的secret token作为环境变量或卷挂载到新的或已存在的Pod中
控制用于验证的webhook
在创建令牌时获取令牌，例如，在为新服务账号创建token secret时。
控制修改webhook
在创建令牌时获取令牌，例如为新服务账号创建token secret时，将服务账号Token附加到新的Pod中
远程代码执行
create pods/exec
通过API Server在现有的Pod中执行命令
更新pod或临时容器
ephermeralcontainer临时容器
https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/ephemeral-containers/
将新容器附加到一个现有的Pod以在其上执行代码。将容器赋予在底层节点上执行代码的特权。
创建node节点或proxy代理
通过kubelet在现有pod中执行命令。
控制pods
通过修改现有pod替换container的镜像。创建一个新的特权pod以在节点上执行代码。
控制pods controller
通过Deployment等pod控制器自由创建或修改pods。通过设置容器为特权容器在node节点上执行代码。
控制修改过的webhook
修改已授权的pod并通过替换一个或多个容器的镜像、命令、参数、环境变量或挂载目录来执行代码。
Steal Pod
更改nodes
通过设置污点节点为NoExecute效果来驱逐一个pod。通过标记其他节点为unsheduled（例如NoSchedule污点），确保它的替换pod（假定pod是由ReplicaSets管理）会运行在特定的节点上。
更改Nodes/status状态
将节点标记为unschedule，例如将其Pod容忍度置为0
创建pods/eviction驱逐
驱逐一个pod，主要为了类似ReplicaSets的控制器能够重新生成它
删除pods
删除一个pod，为了类似ReplicaSets的控制器能够重新生成它
删除nodes
删除一个node来删除它所有的pods，导致类似ReplicaSets的控制器能够重新生成它
更改pods/status状态
将pod标签与同一命名空间中现有的副本控制器(如ReplicaSet)的选择器进行匹配，以欺骗其删除现有的副本。设置pod的就绪时间为副本中最早的时间，确保假的Pod不会正在被删除。
更改pod
将pod标签匹配副本控制器的选择器(如同一命名空间中的ReplicaSet)，以欺骗其删除现有副本。
中间人
控制endpoitslices
更改现有服务的endpointslices来重定向部分流量。为现有服务创建新的endpointslices以重定向其部分流量。
更改endpoits
修改现有服务的endpoints以将服务流量重定向到其他地方。此攻击在配置为使用endpointslice而不是endpoint的集群上无效。
更改service/status
添加负载均衡器IP来利用CVE-2022-8554，并将来自pods和nodes的流量从其指定目标重定向到现有endpoints端点
修改pods/status
将Pod标签与同一命名空间中的服务选择器匹配，以拦截部分流量
修改pods
将Pod标签与同一命名空间中的服务选择器匹配，以拦截部分流量
创建服务
创建一个ExternalIP服务以利用CVE-2022-8554，将来自pods和nodes的流量从指定目标重定向到现有endpoints端点。
控制修改webhooks
修改新的已授权的服务、endpoints端点和endpointslice来重定向集群流量。
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net
