k8s授权和认证
由于k8s是一个容器化平台管理系统，那必定是会提供给各个部门去使用，那每个使用者就应该由管理者分配相应的使用权限。这就不得不提到Kubernetes中的角色访问控制机制（RBAC）支持。Kubernetes 中的 RBAC 支持
在Kubernetes1.6版本中新增角色访问控制机制（Role-Based Access，RBAC）让集群管理员可以针对特定使用者或服务账号的角色，进行更精确的资源访问控制。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。
RBAC vs ABAC
目前 Kubernetes 中有一系列的鉴权机制。
https://kubernetes.io/docs/admin/authorization/
鉴权的作用是，决定一个用户是否有权使用 Kubernetes API 做某些事情。它除了会影响 kubectl 等组件之外，还会对一些运行在集群内部并对集群进行操作的软件产生作用，例如使用了 Kubernetes 插件的 Jenkins，或者是利用 Kubernetes API 进行软件部署的 Helm。ABAC 和 RBAC 都能够对访问策略进行配置。
ABAC（Attribute Based Access Control）本来是不错的概念，但是在 Kubernetes 中的实现比较难于管理和理解（怪我咯），而且需要对 Master 所在节点的 SSH 和文件系统权限，而且要使得对授权的变更成功生效，还需要重新启动 API Server。
而 RBAC 的授权策略可以利用 kubectl 或者 Kubernetes API 直接进行配置。RBAC 可以授权给用户，让用户有权进行授权管理，这样就可以无需接触节点，直接进行授权管理。RBAC 在 Kubernetes 中被映射为 API 资源和操作。
因为 Kubernetes 社区的投入和偏好，相对于 ABAC 而言，RBAC 是更好的选择。
由于在RBAC也不是很好理解，在这里我只能把我说理解的给表达出来，并且给出一些例子。
k8s里面有两种用户,一种是User,一种就是service account,User给人用的,service account给进程用的,让进程有相关的权限。而我们人在使用中接触的最多就是User，因为我们需要看到控制面板，或者通过apiserver去访问不同的api。
之前我在k8s集群搭建教程中说到了让apiserver开启basicauth，通过basic-auth-file文件存放用户名密码，那通过这种方式，我们就可以给k8s创建对应的用户了，这就完成了访问k8s API的认证。
用户创建了，但是在k8s中是没有任何权限的，这就是我要重点说道的授权。
首先来认识几个概念
Role
ClusterRole
RoleBinding
ClusterRoleBinding
RBAC API定义了四个资源对象用于描述RBAC中用户和资源之间的连接权限。
Role和ClusterRole
Role是一系列权限的集合。Role是定义在某个Namespace下的资源，在这个具体的Namespace下使用。ClusterRole与Role相似，只是ClusterRole是整个集群范围内使用的。
RoleBinding和ClusterRoleBinding
RoleBinding把Role绑定到账户主体Subject，让Subject继承Role所在namespace下的权限。ClusterRoleBinding把ClusterRole绑定到Subject，让Subject集成ClusterRole在整个集群中的权限。
账户主体Subject在这里还是叫“用户”吧，包含组group，用户user和ServiceAccount。
通过以上的描述估计大家还是没看懂是啥意思吧，恩我就是这样的。。。那我们实践来了解一下：
首先来看看我创建一个Role.yaml文件,我在安装k8s集群的时候创建了一个user，名字叫test（可以去到初阶k8s集群搭建里去查看我是如何创建的这个用户），我想让这个test只有在default的命名空间里，拥有对pod、deployment、services可读的权限，那么首先我们得有以下的规则，
“在default的命名空间里，拥有对pod、deployment、services可读”的权限
应该这样写：
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods","pods/log"]
verbs: ["get", "watch","list","patch"]
- apiGroups: ["extensions", "apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "patch"]
- apiGroups: [""] # "" indicates the core API group
resources: ["services"]
verbs: ["get", "watch","list","patch"]
这样对比起来就很明显了吧，我们创建了一个名叫reader的规则，它拥有对pod、deployment、services可读的权限，它的作用域是名叫default的命名空间。
规则是创建好了，但是没有人用呀？我们要给test这个用户去使用,也就是说，我们要把这个叫做reader的rule赋给test，这时我们就需要RoleBinding来帮助我们绑定Role：
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: reader-test
namespace: default
subjects:
- kind: User
name: test
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: reader
apiGroup: rbac.authorization.k8s.io
这下就好了，从上面的配置文件看，我们将名叫reader的Role通过名叫reader-test的RoleBinding去赋值到用户test上了，通过kubectl apply -f RoleBinding.yaml,大家即可验证通过test登录到控制台上，只能查看到default命名空间下的pod、deployment、services，并且无法修改无法操作，我们也就完成了以上需求。规则是人定的，想怎么改就根据实际业务需求吧！
授权后的用户，会有一些警告
然鹅，事情真的就这样结束了吗？我们发现通过以上创建好规则是没什么问题了，但是在控制台上，也无法选择别的命名空间了，如下图所示
这就不好办了，也就是说，刚刚使用的RoleBinding和Role都只能在一个命名空间下发挥它的作用，在多个命名空间或者是说在集群的这一整个范围之上呢，有一个集群管理员需要获得namespace 列表和node列表我们应该怎么做？
这就引出了ClusterRoleBinding和ClusterRole这两个资源对象了，我觉得可以理解为RoleBinding和Role的升级版，也就是说，它的控制范围是在集群上的，而不是在某一个命名空间。
在之前的文章中，我们还创建了一个用户admin，我们想让这个admin作为系统观察者，并拥有所有命名空间的pod、deployment、services可读权限，我们可以这样做，按照老步骤：
拥有所有命名空间的pod、deployment、services可读权限
vim ClusterRole.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
#namespace: default
name: admin-nsp
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods","pods/log"]
verbs: ["get", "watch","list","patch","update", "create","delete"]
- apiGroups: ["extensions", "apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
resources: ["services"]
verbs: ["get", "watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
resources: ["namespaces"]
verbs: ["get", "watch","list"]
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "list", "watch"]
我们创造了一个名叫admin-nsp集群级别的规则，很容易看出这个集群规则比之前的Role权利更大，注意啦，这类规则是不需要写命名空间的，它面向的是整个集群，一旦你设置完成，这个规则就拥有对整个集群下的相关权利。
然后我们将它付给我们的用户admin：
vim ClusterRoleBinding
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: read-nsp-global
subjects:
- kind: User
name: admin
apiGroup: rbac.authorization.k8s.io
#- kind: User
# name: test
# apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: admin-nsp
apiGroup: rbac.authorization.k8s.io
通过kubectl apply -f 部署之后就完成了这个admin用户的整个授权。从这个yaml文件看到，这个ClusterRoleBinding可以让我们绑定多个用户，也就是说，设置好的ClusterRole或者是Role都可以被多个用户绑定授权。
通过以上的小例子大家应该能对这四个资源对象有一定的了解了吧，通过一系列的组合方式即可变成一系列灵活的授权模板，这大大的满足了用户多租户多权限的个性化需求。
附：
规则中的一些资源对象
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods","pods/log"]
verbs: ["get", "watch","list","patch","update", "create","delete"]
- apiGroups: ["extensions", "apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
resources: ["services"]
verbs: ["get", "watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
resources: ["configmaps"]
verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
resources: ["persistentvolumeclaims"]
verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
resources: ["secrets"]
verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
resources: ["ingresses.extensions"]
verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
resources: ["daemonsets.apps"]
verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
resources: ["events"]
verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
resources: ["replicasets.apps"]
verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
resources: ["jobs.batch"]
verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
resources: ["cronjobs/batch","cronjobs"]
verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
resources: ["replicationcontrollers"]
verbs: ["get","watch","list","patch","delete","update","create"]
- apiGroups: [""] # "" indicates the core API group
resources: ["statefulsets.apps"]
verbs: ["get","watch","list","patch","delete","update","create"]
本人个人理解。。。有不对的地方还望及时指出。。。
参考文献：
