构建Kubernetes？现在尝试这5个RBAC工具来审计权限

Kubernetes RBAC是一种高效的基于角色的授权方法，用于在Kubernetes集群中提供细粒度的资源访问。

然而，如果不正确使用，它很容易引起合规性灾难。这就是为什么我们需要RBAC工具来审计和定位Kubernetes中的风险权限。

在本文中，我们将讨论Kubernetes RBAC是什么，为什么审计风险权限很重要，并发现哪些工具可以帮助我们最好地审计风险权限！

什么是RBAC？

基于角色的访问控制（RBAC）是一种机制，其中每个访问授权都基于分配给用户的角色。通过这个系统，可以限制应用程序或用户对Kubernetes集群的资源（命名空间、Pod、作业）的访问。

在Kubernetes中，RBAC策略可以用于管理系统用户（用户或组）以及服务账户（Service Account）的访问权限。

Kubernetes中还有其他授权用户的方法，如基于属性的访问控制（ABAC），通过Webhook或节点授权，但在稳定版本中最常用和本地授权机制是RBAC。

几乎所有与资源的交互都是通过其API服务器完成的，这意味着最终所有操作都限制于向该服务器发出HTTP请求（这是主节点或控制面板的重要组件）。

Kubernetes有四个与RBAC相关的对象，可以组合使用来设置集群资源访问权限。它们是Role、ClusterRole、RoleBinding和ClusterRoleBinding。与所有Kubernetes对象一样，要使用这些对象，必须使用Kubernetes API。

Kubernetes中的角色

在Kubernetes上，有两种类型的角色，称为Role和ClusterRole。两者之间的最大区别在于，Role属于具体的命名空间，而ClusterRole是全局的，适用于整个集群。因此，在ClusterRole的情况下，它的名称必须是唯一的，因为它属于集群。在Role的情况下，两个不同的命名空间可以有相同名称的Role。

还应该提到的另一个差异是，Role允许访问同一命名空间内的资源，而ClusterRole除了可以访问任何命名空间的资源外，还可以访问同一命名空间的资源，如节点等。

现在我们知道了角色的类型，下一步是了解我们可以给谁分配这些角色。在这种情况下，我们有用户账户、服务账户和组。

用户账户是分配给特定用户的账户，而服务账户则由进程使用。例如，想象一下，我们的应用程序需要以编程方式访问集群中的资源，为此我们会使用一个服务账户。

最后，我们需要将角色与账户（用户或服务）或组进行绑定的“粘合剂”。Kubernetes中有两个资源可用于此目的：RoleBinding和ClusterRoleBinding。RoleBinding可以引用在同一命名空间中的角色，而ClusterRoleBinding可以引用任何命名空间中的Role并分配全局权限。

需要注意的是，权限只允许访问资源，因为“默认情况下，所有都被拒绝”，可以为同一用户分配多个角色

使用RBAC的唯一先决条件是在我们的集群上启用它，使用“--authorization-mode=RBAC”选项。我们可以使用以下命令检查：

kubectl api-versions

什么是有风险的RBAC权限，如何修复？

任何允许或可能允许未经授权访问Pod资源的权限都被视为危险权限。例如，如果用户具有编辑权限，他们可以编辑自己的角色并访问他们本来不被允许访问的资源。这可能导致合规问题。

同样地，如果旧权限未经检查，则某些用户可以访问他们不再需要的资源。

当您拥有大量角色时，手动查找此类危险权限是困难且耗时的。为了简化此过程，有一些RBAC权限审计工具可帮助扫描整个集群以定位任何危险权限。RBAC的有效性也取决于最新的RBAC策略，而这又要求定期进行权限审计。

以下是一些基于不同语言和用户界面的最佳RBAC工具。

KubiScan

KubiScan是一个基于Python的RBAC工具，用于扫描Kubernetes集群中的危险权限。该工具必须在Master节点内执行，然后可以直接从终端运行以给出危险权限列表。Kubiscan可用于查找危险角色、集群角色、角色绑定、集群绑定、主体、Pod甚至容器。

Krane

Krane是由Appvia开发的基于Ruby的Kubernetes RBAC静态分析和可视化工具。它可以作为CLI本地运行，也可以在CI/CD流水线中运行。此外，它还可以作为一个独立的服务在Kubernetes容器中运行。Krane通过分面树和图形网络视图分析RBAC权限。它还通过Slack集成提供任何危险权限的警报。