Attribute-Based Access Control 是一种基于 Attribute 来定义权限的鉴权机制。

ABAC 翻译过来意思是基于属性的权限访问控制 ，这个模型在如今的云系统中使用的比较多，比如 AWS，阿里云，腾讯云，京东云等，它们都是用 ABAC 来管控 IaaS 以及 PaaS 的资源，曾经 K8s 也使用过这个模型来进行权限管控。

我们上面说过，RBAC 的能力可以用这么一句话来描述：一个用户通过和角色绑定，具备了一些对数据操作的能力，往简单的说就是一个用户有了一些对数据操作的能力。但是，如果在复杂的权限管控场景中，RBAC 显得有些力不从心，比如说：

  • 用户在晚上不能访问这个系统，但是白天可以
  • 用户只能在内网对订单具备修改权限，而在外网就只有查看权限
  • 用户对 2021-03-19 日之前创建的订单有操作权限
  • 用户只能在深圳进行查看订单，而去了国外就不可以
  • 用户在公司内部可以访问所有数据，但是在外部就只能访问公开数据
    我们很容易就发现，RBAC仅仅描述了用户可以做什么 操作 ，但是操作的 条件 ，以及操作的 数据 ，模型本身是没有这些限制的，这也是由于其模型能力的不足所导致的，但这却恰恰是 ABAC 的长处，ABAC 的思想是基于 用户 、以及将要访问的 数据的属性 、以及各种环境因素去动态计算用户是否有权限进行操作。我们先简单介绍一下 NIST ABAC 设计指引中的一些术语:

ABAC Model
ABAC Model

代表未来：但是为什么 k8s 用的主要都是 rbac 呢？

ABAC, Attribute Based Access Control, is a powerful concept. However, as implemented in Kubernetes, ABAC is difficult to manage and understand. It requires ssh and root filesystem access on the master VM of the cluster to make authorization policy changes. For permission changes to take effect the cluster API server must be restarted.

RBAC permission policies are configured using kubectl or the Kubernetes API directly. Users can be authorized to make authorization policy changes using RBAC itself, making it possible to delegate resource management without giving away ssh access to the cluster master. RBAC policies map easily to the resources and operations used in the Kubernetes API.

Based on where the Kubernetes community is focusing their development efforts, going forward RBAC should be preferred over ABAC.