我们使用kubeadm搭建的集群会默认开启RABC（角色访问控制机制），所以我们必须要进行额外的设置。

K8S 1.6引进，是让用户能够访问 k8S API 资源的授权方式【不授权就没有资格访问K8S的资源】

用户(subject)

K8S有两种用户：User和Service Account。其中，User给人用，Service Account给进程用，让进程有相关权限。如Dashboard就是一个进程，我们就可以创建一个Service Account给它。

角色

Role是一系列权限的集合，例如一个Role可包含读取和列出 Pod的权限【 ClusterRole 和 Role 类似，其权限范围是整个集群】

角色绑定

RoleBinding把角色映射到用户，从而让这些用户拥有该角色的权限【ClusterRoleBinding 和RoleBinding 类似，可让用户拥有 ClusterRole 的权限】

Secret

Secret是一个包含少量敏感信息如密码，令牌，或秘钥的对象。把这些信息保存在 Secret对象中，可以在这些信息被使用时加以控制，并可以降低信息泄露的风险。

RBAC核心概念公式

　　role/clusterrole = object + action

　　授权单个名称空间： rolebinding = subject + role/clusterRole

　　授权集群： clusterRoleBinding = subject + clusterRole

action:

　　即具体能对Ojbect做什么，它有: get, list, watch, patch, delete, update, create 等。。。

基于单个名称空间:

　　　　role, clusterrole, rolebinding

　　　整个集群级别:

　　　　clusterrole , clusterrolebinding

原理

K8s中的认证和授权机制:

　　在K8s中我们操作任何资源都需要经历三个检查步骤：认证、授权 和 准入控制。

　　当然这些仅针对普通用户，k8s中默认clusteradmin是拥有最高权限的。

认证: 即用户要登陆k8s上操作资源，你必须提供合法的用户名和密码。

授权: 用户认证通过后，要查看该用户能操作什么资源，若其要操作的资源在其允许操作的资源范围内则通过。

准入控制: 用户要操作的资源，也许需要级联其它相关资源或级联了其它相关操作，那么这些级联的资源 或 级联的操作该用户是否有权限访问？这个就是有准入控制来检查的，若不允许访问级联资源，那么该资源也将无法访问。因为k8s是高度模块化设计，因此，这三种检查都允许用户自定义使用何种检测机制来进行访问控制。

认证:

token: 此方式又称为预共享密钥方式的认证，即用户名和密码，如同MySQL中root要登陆，必须事先在user表中创建root密码.

TLS: 此中方式为证书认证方式，此时K8s服务端 和 客户端要做双向证书认证，即客户端要认证服务端的证书是否为自己认可的CA所签发的证书，且证书中的subject信息CN(主机名)必须与服务端的主机名一致，等等；而服务器端也要认证客户端的证书，也要认可签发该证书的CA，以及证书中的信息也要匹配。以上是两种比较常用的认证方式，还有其它认证，可自行研究。需要注意的是 认证插件中只有一个认证通过，其它插件就无需再次认证了。

授权:

　　它也是模块化设计,它和认证一样都同时支持多个模块并存，但只要有一个模块认证通过，即通过了此关，可进入下一关进一步检查。

　　除了下面几种常用授权模块，我们也可在测试时，使用“总是允许” 或 “总是拒绝”来测试账号。

RBAC：基于角色的访问控制机制，它只有允许授权，没有拒绝授权，因为默认是拒绝所有，我们仅需要定义允许该用户做什么即可。默认kubectl创建的K8s资源，都是默认启用强制RBAC的

ABAC

基于Node的授权

Web-huke的授权（这是一种通过Web的回调机制实现的授权)

准入控制：

　　这块主要是对认证授权通过后，后期对要操作的级联对象操作的检查，无需过多关注。

K8s上的用户账户:

　　k8s客户端(一般用:kubectl) ------>API Server

　　APIServer需要对客户端做认证，默认使用工具安装的K8s，会在用户家目录下创建一个认证配置文件 .kube/config 这里面保存了客户端访问API Server的密钥相关信息，这样当用kubectl访问k8s时，它就会自动读取该配置文件，向API Server发起认证，然后完成操作请求。