这些用来审计 Kubernetes RBAC 策略的方法你都见过吗？

认证与授权对任何安全系统来说都至关重要，Kubernetes 也不例外。即使我们不是安全工作人员，也需要了解我们的 Kubernetes 集群是否具有足够的访问控制权限。Kubernetes 社区也越来越关注容器的安全评估（包括渗透测试，配置审计，模拟攻击），如果你是应用安全工程师，或者是安全感知的 DevOps 工程师，最好了解一下 Kubernetes 的授权模型。

Kubernetes 的授权控制原则与大多数系统一样：在授予访问权限时采用最小授权原则。例如，如果某个 Pod 使用了特定的 serviceAccount，那么该 Pod 被限定为只能拥有指定的权限，只能访问特定的资源。

Kubernetes 从 1.6 开始支持基于角色的访问控制机制（Role-Based Access，RBAC），集群管理员可以对用户或服务账号的角色进行更精确的资源访问控制。先简单回顾一下 RBAC 的原理。

 

1.RBAC 基础概念

---

RBAC 授权策略会创建一系列的 Role 和 ClusterRole 来绑定相应的资源实体（serviceAccount 或 group，user），以此来限制其对集群的操作。每一个 Role 都基于 Create, Read, Update, Delete（CRUD）模型来构建，并使用“动词”来应用相应的权限。例如，动词 get 表示能够获取特定资源的详细信息。如果你想获取对 Secrets 的访问权限，可以创建如下的 ClusterRole：

 

2.RBAC 实践

---

RBAC 授权模型为我们提供了一种精确的访问控制机制，但随着环境越来越复杂，这些 RBAC 配置也越来越难维护。RBAC 配置可能包含了 Roles, RoleBindings, ClusterRoles, ClusterRoleBindings, ServiceAccounts 和 Groups 等，想要跟踪它们之间的关系非常困难。

举个栗子，先创建一个名叫 helm 的 ServiceAccount，然后创建相应的 Role 绑定 “tiller-world” namespace，该 Role 只拥有 list pods 的权限，最后通过创建 RoleBinding 将该 Role 与之前创建的 ServiceAccount 绑定。

 如果你想知道新创建的授权对象是否仅被授予必要的访问权限，就需要审查这些对象及其在集群中的关系。有时候还需要确保其仅对特定的资源实例具有访问权限，不允许访问所有的资源实例。例如，如果你不想让上面的 ServiceAccount 访问所有的 Secret，只允许它访问特定的 Secret，可以使用 resourceNames 字段指定：

这个方法的问题在于无法过滤集群中不存在的资源，这意味着如果资源的名称是动态变化的，那么就无法创建相应的 Role，除非在创建 Role 的同时创建资源。