ABAC有时也被称为PBAC（Policy-Based Access Control）或CBAC（Claims-Based Access Control）
鉴权的作用是，决定一个用户是否有权使用 Kubernetes API 做某些事情。它除了会影响 kubectl 等组件之外，还会对一些运行在集群内部并对集群进行操作的软件产生作用，例如使用了 Kubernetes 插件的 Jenkins，或者是利用 Kubernetes API 进行软件部署的 Helm。ABAC 和 RBAC 都能够对访问策略进行配置。
ABAC，基于属性的访问控制，是一个强大的概念。然而，正如在Kubernetes实施的那样，ABAC很难管理和理解。它需要在集群的主虚拟机上进行ssh和根文件系统访问，以更改授权策略。要使权限更改生效，必须重新启动集群API服务器。
RBAC权限策略是直接使用kubectl或Kubernetes API配置的。可以授权用户使用RBAC本身来更改授权策略，这样就可以在不泄露对集群主服务器的ssh访问的情况下委派资源管理。RBAC策略很容易映射到Kubernetes API中使用的资源和操作。
因为 Kubernetes 社区的投入和偏好，相对于 ABAC 而言，RBAC 是更好的选择。RBAC角色授权详解
使用 ABAC 鉴权kubernetes.io文档
Casbin轻量级开源访问控制框架
基于属性的访问控制（Attribute-based access control - ABAC）定义了访问控制范例， 其中通过使用将属性组合在一起的策略来向用户授予访问权限。策略可以使用任何类型的属性（用户属性、资源属性、 对象，环境属性等）
ABAC被一些人称为是权限系统设计的未来。
不同于常见的将用户通过某种方式关联到权限的方式，ABAC则是通过动态计算一个或一组属性来是否满足某种条件来进行授权判断（可以编写简单的逻辑）。属性通常来说分为四类：用户属性（如用户年龄），环境属性（如当前时间），操作属性（如读取）和对象属性（如一篇文章，又称资源属性），所以理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。
例如:规则：“允许所有班主任在上课时间自由进出校门”这条规则，其中，“班主任”是用户的角色属性，“上课时间”是环境属性，“进出”是操作属性，而“校门”就是对象属性了。为了实现便捷的规则设置和规则判断执行，ABAC通常有配置文件（XML、YAML等）或DSL配合规则解析引擎使用。XACML（eXtensible Access Control Markup Language）是ABAC的一个实现，但是该设计过于复杂，故不做介绍。
总结一下，ABAC有如下特点：
1.集中化管理
2.可以按需实现不同颗粒度的权限控制
3.不需要预定义判断逻辑，减轻了权限系统的维护成本，特别是在需求经常变化的系统中
4.定义权限时，不能直观看出用户和对象间的关系
5.规则如果稍微复杂一点，或者设计混乱，会给管理者维护和追查带来麻烦
6.权限判断需要实时执行，规则过多会导致性能问题
注意：该ABAC授权功能在Kubernetes 1.6版本开始已被弃用!
基于 ABAC 模式，可以这样指定策略文件 --authorization-policy-file=SOME_FILENAME。
此文件格式是 JSON Lines，不应存在外层的列表或映射，每行应只有一个映射。
每一行都是一个策略对象，策略对象是具有以下属性的映射：
✔ 版本控制属性：
apiVersion，字符串类型：有效值为abac.authorization.kubernetes.io/v1beta1，允许对策略格式进行版本控制和转换。
kind，字符串类型：有效值为 Policy，允许对策略格式进行版本控制和转换。
✔ spec 配置为具有以下映射的属性：
主体匹配属性：
user，字符串类型；来自 --token-auth-file 的用户字符串，如果你指定 user，它必须与验证用户的用户名匹配。
group，字符串类型；如果指定 group，它必须与经过身份验证的用户的一个组匹配，system:authenticated 匹配所有经过身份验证的请求。system:unauthenticated 匹配所有未经过身份验证的请求。
✔ 资源匹配属性：
♥apiGroup，字符串类型；一个 API 组。
例： apps, networking.k8s.io
通配符：* 匹配所有 API 组。
♥namespace，字符串类型；一个命名空间。
例如：kube-system
通配符：* 匹配所有资源请求。
♥resource，字符串类型；资源类型。
例：pods, deployments
通配符：* 匹配所有资源请求。
✔ 非资源匹配属性：
nonResourcePath，字符串类型；非资源请求路径。
例如：/version或 /apis
通配符：* 匹配所有非资源请求。
/foo/* 匹配 /foo/ 的所有子路径。
readonly，键入布尔值，如果为 true，则表示该策略仅适用于 get、list 和 watch 操作。
鉴权算法Note:
属性未设置等效于属性被设置为对应类型的"零值"(例如空字符串、0、false)，然而，出于可读性考虑，应尽量选择不设置这类属性。
在将来策略可能以 JSON 格式表示，并通过 REST 界面进行管理。
✔ 请求具有与策略对象的属性对应的属性。
✔ 当接收到请求时，确定属性。未知属性设置为其类型的零值（例如：空字符串，0，false）。
✔ 设置为 "*" 的属性将匹配相应属性的任何值。
✔ 检查属性的元组，以匹配策略文件中的每个策略。如果至少有一行匹配请求属性，则请求被鉴权（但仍可能无法通过稍后的合法性检查）。
✔ 要允许任何经过身份验证的用户执行某些操作，请将策略组属性设置为 system:authenticated。
✔ 要允许任何未经身份验证的用户执行某些操作，请将策略组属性设置为 system:unauthenticated。
✔ 要允许用户执行任何操作，请使用设置为 “*” 的 apiGroup，namespace，resource 和 nonResourcePath 属性编写策略。
kubectl 使用 api-server 的 /api 和 /apis 端点来发现服务资源类型， 并使用位于 /openapi/v2 的模式信息来验证通过创建/更新操作发送到 API 的对象。
当使用 ABAC 鉴权时，这些特殊资源必须显式地通过策略中的 nonResourcePath 属性暴露出来（参见下面的 示例）：
✔ /api，/api/* ，/apis 和 /apis/* 用于 API 版本协商。
✔ /version 通过 kubectl version 检索服务器版本。
✔ /swaggerapi/* 用于创建 / 更新操作。
要检查涉及到特定 kubectl 操作的 HTTP 调用，你可以调整详细程度： kubectl --v=8 version
Alice 可以对所有资源做任何事情：
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}
kubelet 可以读取任何 pod：
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}}
kubelet 可以读写事件：
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "events"}}
Bob 可以在命名空间 projectCaribou 中读取 pod：
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}}
任何人都可以对所有非资源路径进行只读请求：
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:authenticated", "readonly": true, "nonResourcePath": "*"}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}
服务帐户的快速说明
服务帐户自动生成用户。用户名是根据命名约定生成的：
system:serviceaccount::
创建新的命名空间也会导致创建一个新的服务帐户：
system:serviceaccount::default
例如，如果要将 API 的 kube-system 完整权限中的默认服务帐户授予，则可以将此行添加到策略文件中：
{"apiVersion":"abac.authorization.kubernetes.io/v1beta1","kind":"Policy","spec":{"user":"system:serviceaccount:kube-system:default","namespace":"*","resource":"*","apiGroup":"*"}}
需要重新启动 apiserver 以获取新的策略行。
结语
权限系统设计可谓博大精深，这篇文章只是介绍了一点皮毛。
随着人类在信息化道路上越走越远，权限系统的设计也在不断创新，但目前好像处在了平台期。
可能因为在RBAC到ABAC之间有着巨大的鸿沟，无法轻易跨越，也可能是一些基于RBAC的微创新方案还不够规范化从而做到普及。不过在服务化架构的浪潮下，未来这一块必然有极高的需求，也许巨头们已经开始布局了。
Before you get stronger, you have to go through a period of nobody’s attention!
