当认证通过以后，并不意味着你有访问资源可能。因为需要鉴权，这样才有访问具体对象的权限。
上面认证过程，只是确认通信的双方都确认了对方是可信的，可以相互通信。而鉴权是确定请求方有哪些资源的权限（具体对资源有哪些资源的权限就需要鉴权）。API Server 目前支持以下几种授权策略（通过 API Server 的启动参数 “--authorization-mode” 设置）
AlwaysDeny：表示拒绝所有的请求，一般用于测试AlwaysAllow：允许接收所有请求，如果集群不需要授权流程，则可以采用该策略ABAC（Attribute-Based Access Control）：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制（老版本采用的方式，也就是定义属性的访问类型，如果用户拥有这个属性就能访问对应的资源。需要定义一长串的属性，并且ABAC修改完之后并不能生效，现在淘汰了）Webbook：通过调用外部 REST 服务对用户进行授权（在集群外部对集群鉴权）RBAC（Role-Based Access Control）：基于角色的访问控制，现行默认规则（拥有角色就代表拥有访问资源某些权限）现在使用RBAC，前面这几种不做讨论
RBAC（Role-Based Access Control）基于角色的访问控制，在 Kubernetes 1.5 中引入，现行版本成为默认标准。相对其它访问控制方式，拥有以下优势：
对集群中的资源（pod deploy cpu.......）和非资源（元信息如pod状态）均拥有完整的覆盖整个 RBAC 完全由几个 API 对象完成，同其它 API 对象一样，可以用 kubectl 或 API 进行操作可以在运行时进行调整，无需重启 API Server（ABAC修改需要重启API server生效）
RBAC 引入了 4 个新的顶级资源对象：Role（角色）、ClusterRole（集群角色）、RoleBinding（角色绑定）、ClusterRoleBinding（集群角色绑定），4 种对象类型均可以通过 kubectl 与 API 操作
对对象的操作会被赋予为role，比如有一个创建pod的角色。角色绑定就是将角色赋予给用户或者组或者SA。
角色赋予给张三，会需要指定名称空间，比如default名称空间，这个过程就叫做角色绑定，如果还有李四，那么还有一个名称空间test，那么还需要创建角色赋予李四。
这样在不同的名称空间下面创建的同一个动作比如读pod，那么每个名称空间都需要创建这个读pod的角色，太费劲了。
为了解决这样的问题可以先创建一个集群角色，集群角色可以读取所有名称空间里面的pod信息，然后再进行角色绑定，而不是集群角色绑定。
很多用户需要读对应名称空间下面的角色，这样就可以使用角色绑定集群角色。这样就可以赋予王五赵六，这里的角色绑定需要指定名称空间。王五赵六绑定的是角色绑定不是集群角色绑定，如果这里进行的是集群角色绑定，在这里admin做了集群角色绑定，那么admin这个用户可以读k8s集群当中所有pod信息。
也就是 并不是角色对应角色绑定，也可以集群角色也是对应的是角色绑定
需要注意的是 Kubenetes 并不会提供用户管理，那么 User、Group、ServiceAccount 指定的用户又是从哪里来的呢？ Kubenetes 组件（kubectl、kube-proxy）或是其他自定义的用户在向 CA 申请证书时，需要提供一个证书请求文件（在k8s里面没有创建用户的命令，用户的命令在定义CA证书的时候就已经提供了）
API Server会把客户端证书的CN字段作为User，把names.O字段作为Group
kubelet 使用 TLS Bootstaping 认证时，API Server 可以使用 Bootstrap Tokens 或者 Token authenticationfile 验证=token，无论哪一种，Kubenetes 都会为 token 绑定一个默认的 User 和 Group
Pod使用 ServiceAccount 认证时，service-account-token 中的 JWT 会保存 User 信息
有了用户信息，再创建一对角色/角色绑定(集群角色/集群角色绑定)资源对象，就可以完成权限绑定了
