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"]

---

本人个人理解。。。有不对的地方还望及时指出。。。

参考文献：

http://blog.frognew.com/2017/04/kubernetes-1.6-rbac.html

Kubernetes中的角色访问控制机制（RBAC）支持