前面介绍看k8s的各种认证方式，以及和企业认证如何集成，认证完之后，认证是用来知道request代表的人，或者个体，组件是谁。

认证结束了只能认清楚你是谁了，你能够做什么操作我还是不确定的，这个事情就要通过鉴权来解决。

授权

---

k8s有各种各样的对象，因为是声明式的系统，在任何用户操作这些对象的时候，我要去知道你有没有这个操作权限，所以要通过严格的鉴权策略来定义整个集群，哪些用户有哪些对象的操作权限。

授权主要是用于对集群资源的访问控制，通过检查请求包含的相关属性值，与相对应的访问策略相比较，API请求必须满足某些策略才能被处理。

跟认证类似，Kubernetes也支持多种授权机制，并支持同时开启多个授权插件（只要有一个验证通过即可）。

如果授权成功，则用户的请求会发送到准入控制模块做进一步的请求验证;对于授权失败的请求则返回 HTTP 403。

Kubernetes授权仅处理以下的请求属性∶

• user, group, extra（它会去处理request里面所带的用户信息，用户组信息，要知道发起人是谁）
• API、请求方法（如 get、post、update、patch和delete）和请求路径（如/api））请求资源和子资源（其次就是通过什么样的方法来操作对象）
• Namespace
• API Group

目前，Kubernetes 支持以下授权插件∶

• ABAC
• RBAC
• Webhook
• Node

RBAC VS ABAC

---

ABAC（Attribute Based Access Control）本来是不错的概念，但是在Kubernetes 中的实现比较难于管理和理解，而且需要对Master 所在节点的 SSH和文件系统权限，要使得对授权的变更成功生效，还需要重新启动 API Server。

而 RBAC 的授权策略可以利用kubectl或者Kubernetes API直接进行配置。RBAC可以授权给用户，让用户有权进行授权管理，这样就可以无需接触节点，直接进行授权管理。RBAC在Kubernetes中被映射为 API资源和操作。

RBAC老图

---

所谓的rbac就是以role为核心的这样一个鉴权体系， 首先要去定义一些权限，这些权限是什么，要去操作哪些对象，通过什么样的方式操作这些对象。

将对象和操作组合在一起，这两个对象的组合在一起就叫做permission，我们会将一堆的permission整合到一个角色里面，这个角色最后可以授予到某个用户那去的，user和role会产生绑定关系。

RBAC 新解

---

RBAC：其实就定义了谁能够对什么对象，怎么样去做操作。

谁其实有两类，一类是基于外部认证系统的话，它就是一个user，如果是Kubernetes自己生成的系统账号，那么就是一个serviceaccount，授权什么权限给它呢？其实就是Kubernetes各种对象，哪个api group的，哪个resource，有哪些对象组合，verbs就是正真的operation了。

举个例子：我是core group的v1版本的pod对象，比如pod status就是subresource，它和主对象是分离的，它是一个附属对象。

所谓的watch就是说我能够get watch list delete 等这一类的操作组合。

这样就将对象和它所谓的操作整合起来了，这样就整合为role对象了，可以定义一个role，这role里面可以定义我有哪些api group，每个api group里面有哪些对象，每个对象又有什么样的操作权限，将这些操作权限汇聚成一个role，这个role要和主题的subject去做一个绑定关系，这里就会有rolebinding对象。

产生绑定关系了之后就可以这个主体就可以以verb方式去操作这个对象了。

Role与ClusterRole

---

Role（角色）是一系列权限的集合，例如一个角色可以包含读取Pod的权限和列出Pod的权限。Role只能用来给某个特定namespace中的资源作鉴权，对多namespace和集群级的资源或者是非资源类的API（如/healthz）使用ClusterRole。（cluster rolebinding和role binding作用的范围是不一样的，role和rolebinding和namespace相关，如果我定义了一个role，这个role是要放在某个namespace下面，role和rolebinding都要建立在同一个namespace下面）（带有cluster的是集群范围的，可以操作集群当中所以namespace下的某些资源对象）

带有cluster关键字的代表全局范围的对象，不带的代表namespace相关的对象。

因为cluster role是全局可见，其实可以绑到role binding。 

用户、组管理

---

角色绑定（Role Binding）是将角色中定义的权限赋予一个或者一组用户。

它包含若干主体（用户、组或服务账户）的列表和对这些主体所获得的角色的引用。组的概念∶

• 当与外部认证系统对接时，用户信息（UserInfo）可包含Group 信息，授权可针对用户群组 
• 当对 ServiceAccount授权时，Group 代表某个 namespace 下的所有 ServiceAccount。

授权主体分为两类， 一类是user，user是和外部系统对接的时候，如果是kubernetes自己生成的ｓａ，那么就是sa类型。

授权不仅仅可以针对用户，sa，去做授权，还可以针对一个group去做授权。

在之前做认证的时候，不仅仅可以返回用户的信息，还可以返回用户组的信息，如果授权针对于用户组，用户属于这个用户组，那么授权就会通过。

针对sa来说也有group的概念，sa是namespace＋sa的名称，在一个ns里面其实可以有很多的ｓａ，所以ns就是sa的聚合地，针对sa来说group就是它的ns。

如果我有一个权限授予了某个ns，那么ns下面所有的sa都有权限。

针对群组授权

---

其他都一样，在绑定的时候不会sa，user了，绑定的kind是group，左边的manager其实就是group的名字了，右边是sa group的名字 ，也即是qa　ns下面的所有sa都有权限。

规划系统角色

---

对于强隔离的场景，比如有个集群，集群里面支持了100个用户，这100个用户属于不同的用业务部门，我希望让他们批次完全不感知，这个时候就需要做一些控制了，不认你读取任何的global配置，不让你知道有多少个ns，你只需要关系你自己ns就行了。

要对集群的权限做严格的管控。

与权限相关的最佳实践

---

再强调一个cluster是和pv没有关系的，如果通过clusterrole去绑定角色，那么整个集群范围生效。

所以clusterrole给到用户的时候，一定要慎重。

集群管理员是通过cluster role去授予的，针对于不同的用户通过ns相关的rolebinding去授予的，剩下的事情让他们自己去运营了。

值得一提的是有些对象是全局对象，比如CRD对象，一般CRD的创建权限可以不下发，用户去建立CRD要去做扩展的时候，创建完CRD要给其相应的权限它们才能使用。

 现在不推荐开启insecure的访问权限，不要让任何人绕过认证鉴权。

运营过程当中出现的陷阱

---