前面介绍看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（Attribute Based Access Control）本来是不错的概念，但是在Kubernetes 中的实现比较难于管理和理解，而且需要对Master 所在节点的 SSH和文件系统权限，要使得对授权的变更成功生效，还需要重新启动 API Server。
而 RBAC 的授权策略可以利用kubectl或者Kubernetes API直接进行配置。RBAC可以授权给用户，让用户有权进行授权管理，这样就可以无需接触节点，直接进行授权管理。RBAC在Kubernetes中被映射为 API资源和操作。
ＲＢＡＣ老图
所谓的ｒｂａｃ就是以ｒｏｌｅ为核心的这样一个鉴权体系， 首先要去定义一些权限，这些权限是什么，要去操作哪些对象，通过什么样的方式操作这些对象。
将对象和操作组合在一起，这两个对象的组合在一起就叫做permission，我们会将一堆的permission整合到一个角色里面，这个角色最后可以授予到某个用户那去的，user和role会产生绑定关系。
ＲＢＡＣ新解
ＲＢＡＣ：其实就定义了谁能够对什么对象，怎么样去做操作。
谁其实有两类，一类是基于外部认证系统的话，它就是一个user，如果是ｋ８ｓ自己生成的系统账号，那么就是一个ｓｅｒｖｉｃｅａｃｃｏｕｎｔ，授权什么权限给它呢？其实就是ｋ８ｓ各种对象，哪个ａｐｉｇｒｏｕｐ的，哪个resource，有哪些对象组合，verbs就是正真的operation了。
举个例子：我是ｃｏｒｅ ｇｒｏｕｐ的ｖ１版本的ｐｏｄ对象，比如ｐｏｄ ｓｔａｔｕｓ就是ｓｕｂresource，它和主对象是分离的，它是一个附属对象。
所谓的watch就是说我能够ｇｅｔ ｗａｔｃｈ ｌｉｓｔ ｄｅｌｅｔｅ等这一类的操作组合。
这样就将对象和它所谓的操作整合起来了，这样就整合为ｒｏｌｅ对象了，可以定义一个ｒｏｌｅ，这个ｒｏｌｅ里面可以定义我有哪些ａｐｉｇｒｏｕｐ，每个ａｐｉｇｒｏｕｐ里面有哪些对象，每个对象又有什么样的操作权限，将这些操作权限汇聚成一个ｒｏｌｅ，这个肉了要和主题的ｓｕｂｊｅｃｔ去做一个绑定关系，这里就会有ｒｏｌｅｂｉｎｄｉｎｇ对象。
产生绑定关系了之后就可以这个主体就可以以ｖｅｒｂ方式去操作这个对象了。
Ｒｏｌｅ与Ｃｌｕｓｔｅｒｒｏｌｅ
Role（角色）是一系列权限的集合，例如一个角色可以包含读取Pod的权限和列出Pod的权限。Role只能用来给某个特定namespace中的资源作鉴权，对多namespace和集群级的资源或者是非资源类的API（如/healthz）使用ClusterRole。（ｃｌｕｓｔｅｒｒｏｌｅｂｉｎｇ和ｒｏｌｅｅｂｉｎｄｉｎｇ作用的范围是不一样的，ｒｏｌｅ和ｒｏｌｅｂｉｎｄｉｎｇ和ｎａｍｓｐａｃｅ相关，如果我定义了一个ｒｏｌｅ，这个ｒｏｌｅ是要放在某个ｎａｍｓｐａｃｅ下面，ｒｏｌｅ和ｒｏｌｅｂｉｎｄｉｎｇ都要建立在同一个ｎａｍｓｐａｃｅ下面。ｃｌｕｓｔｅｒｒｏｌｅｂｉｎｄｉｎｇ）（带有cluster的是集群范围的，可以操作集群当中所以ｎａｍｅｓｐａｃｅ下的某些资源对象）
带有cluster关键字的代表全局范围的对象，不带的代表namespace相关的对象。
因为ｃｌｕｓｔｅｒｒｏｌｅ是全局可见，其实可以绑到ｒｏｌｅｂｉｎｄｉｎｇ，
Ｂｉｎｄｉｎｇ
用户、组管理
角色绑定（Role Binding）是将角色中定义的权限赋予一个或者一组用户。
它包含若干主体（用户、组或服务账户）的列表和对这些主体所获得的角色的引用。组的概念∶
- 当与外部认证系统对接时，用户信息（UserInfo）可包含Group 信息，授权可针对用户群组
- 当对 ServiceAccount授权时，Group 代表某个 namespace 下的所有 ServiceAccount。
授权主体分为两类， 一类是ｕｓｅｒ，ｕｓｅｒ是和外部系统对接的时候，如果是ｋ８ｓ自己生成的ｓａ，那么就是ｓａ类型。
授权不仅仅可以针对用户，ｓａ，去做授权，还可以针对一个ｇｒｏｕｐ去做授权。
在之前做认证的时候，不仅仅可以返回用户的信息，还可以返回用户组的信息，如果授权针对于用户组，用户属于这个用户组，那么授权就会通过。
针对ｓａ来说也有group的概念，ｓａ是ｎａｍｓｐａｃｅ＋ｓａ的名称，在一个ｎｓ里面其实可以有很多的ｓａ，所以ｎｓ就是ｓａ的聚合地，针对ｓａ来说ｇｒｏｕｐ就是它的ｎｓ。
如果我有一个权限授予了某个ｎｓ，那么ｎｓ下面所有的ｓａ都有权限。
针对群组授权
其他都一样，在绑定的时候不会ｓａ，ｕｓｅｒ了，绑定的ｋｉｎｄ是ｇｒｏｕｐ，左边的manager其实就是group的名字了，右边是ｓａ ｇｒｏｕｐ的名字 ，也即是ｑａ ｎｓ下面的所有ｓａ都有权限。
规划系统角色
对于强隔离的场景，比如有个集群，集群里面支持了１００个用户，这１００个用户属于不同的用业务部门，我希望让他们批次完全不感知，这个时候就需要做一些控制了，不认你读取任何的global配置，不让你知道有多少个ｎｓ，你只需要关系你自己ｎｓ就行了。
要对集群的权限做严格的管控。
与权限相关的最佳实践
再强调一个ｃｌｕｓｔｅｒｒｏｌｅ是和ｎｓ没有关系的，如果通过ｃｌｕｓｔｅｒｒｏｌｅ去绑定角色，那么整个集群范围生效。
所以ｃｌｕｓｔｅｒｒｏｌｅ给到用户的时候，一定要慎重。
集群管理员是通过ｃｌｕｓｔｅｒｒｏｌｅ去授予的，针对于不同的用户通过ｎｓ相关的ｒｏｌｅｂｉｎｄｉｎｇ去授予的，剩下的事情让他们自己去运营了。
值得一提的是有些对象是全局对象，比如ＣＲＤ对象，一般ＣＲＤ的创建权限可以不下发，用户去建立ＣＲＤ要去做扩展的时候，创建完ＣＲＤ要给其相应的权限它们才能使用。
现在不推荐开启ｉｎｓｅｃｕｒｅ的访问权限，不要让任何人绕过认证鉴权。
运营过程当中出现的陷阱
