「走进k8s」Kubernetes1.15.1的RBAC（28）

上次学习了k8s用于配置信息的2个重要的配置对象configmap 和 secret，通过之前的说的重要对象，基本上配置一个应用程序的问题已经不大了。本次说说RBAC ，基于角色的权限访问控制（Role-Based Access Control）作为传统访问控制（自主访问，强制访问）。

（一）RBAC

• ① 介绍

在Kubernetes中，授权有ABAC（基于属性的访问控制）、RBAC（基于角色的访问控制）、Webhook、Node、AlwaysDeny（一直拒绝）和AlwaysAllow（一直允许）这6种模式。从1.6版本起，Kubernetes 默认启用RBAC访问控制策略。从1.8开始，RBAC已作为稳定的功能。通过设置–authorization-mode=RBAC，启用RABC。在RABC API中，通过如下的步骤进行授权：1）定义角色：在定义角色时会指定此角色对于资源的访问控制的规则；2）绑定角色：将主体与角色进行绑定，对用户进行访问授权。

• ② 查看当前K8s 访问控制策略

cat /etc/kubernetes/manifests/kube-apiserver.yaml

没有这个属性，可以考虑添加上，然后重启下api server的服务

- --authorization-mode=Node,RBAC

• ② 资源对象

Kubernetes有一个很基本的特性就是它的[所有资源对象都是模型化的 API 对象]，之前咱们基本上创建pod，展示pod，删除pod，修改pod，都是有点CRUD，(Create、Read、Update、Delete)操作(也就是我们常说的增、删、改、查操作)。 资源列表

1. Pods
2. ConfigMaps
3. Deployments
4. Nodes
5. Secrets
6. Namespaces

资源操作

1. create
2. get
3. delete
4. list
5. update
6. edit
7. watch
8. exec

在更上层，这些资源和 API Group 进行关联，比如Pods属于 Core API Group，而Deployements属于 apps API Group

Kubernetes中进行RBAC的管理，还有角色，规则配置

1.rule

规则，规则是一组属于不同 API Group 资源上的一组操作的集合

2.Role 和 ClusterRole

角色和集群角色，这两个对象都包含上面的 Rules 元素，二者的区别在于，在 Role 中，定义的规则只适用于单个命名空间，也就是和 namespace 关联的，而 ClusterRole 是集群范围内的，因此定义的规则不受命名空间的约束。另外 Role 和 ClusterRole 在Kubernetes中都被定义为集群内部的 API 资源，和我们前面学习过的 Pod、ConfigMap 这些类似，都是我们集群的资源对象，所以同样的可以使用我们前面的kubectl相关的命令来进行操作

3.Subject

主题，对应在集群中尝试操作的对象，集群中定义了3种类型的主题资源：

3.1.User Account

用户，这是有外部独立服务进行管理的，管理员进行私钥的分配，用户可以使用 KeyStone或者 Goolge 帐号，甚至一个用户名和密码的文件列表也可以。对于用户的管理集群内部没有一个关联的资源对象，所以用户不能通过集群内部的 API 来进行管理

3.2.Group

组，这是用来关联多个账户的，集群中有一些默认创建的组，比如cluster-admin

3.3.Service Account

服务帐号，通过Kubernetes API 来管理的一些用户帐号，和 namespace 进行关联的，适用于集群内部运行的应用程序，需要通过 API 来完成权限认证，所以在集群内部进行权限操作，我们都需要使用到 ServiceAccount，这也是我们这节课的重点

4.RoleBinding 和 ClusterRoleBinding

角色绑定和集群角色绑定，简单来说就是把声明的 Subject 和我们的 Role 进行绑定的过程(给某个用户绑定上操作的权限)，二者的区别也是作用范围的区别：RoleBinding 只会影响到当前 namespace 下面的资源操作权限，而 ClusterRoleBinding 会影响到所有的 namespace。

（二）创建访问某个 namespace 的用户

• ① 创建用户

给用户 idig8 创建一个私钥，命名成：idig8.key -out filename ：将生成的私钥保存至filename文件，若未指定输出文件，则为标准输出。-numbits ：指定要生成的私钥的长度，默认为1024。该项必须为命令行的最后一项参数。

openssl genrsa -out idig8.key 2048

利用刚刚创建的私钥创建一个证书签名请求文件：idig8.csr 要注意需要确保在-subj参数中指定用户名和组(CN表示用户名，O表示组)

openssl req -new -key idig8.key -out idig8.csr -subj "/CN=idig8/O=zhugeaming"

设置证书，这里设置的是1000天。Kubernetes集群的CA，我们使用的是kubeadm安装的集群，CA相关证书位于/etc/kubernetes/pki/目录下面，如果你是二进制方式搭建的，你应该在最开始搭建集群的时候就已经指定好了CA的目录，我们会利用该目录下面的ca.crt和ca.key两个文件来批准上面的证书请求 x509命令具以下的一些功能，例如输出证书信息，签署证书请求文件、生成自签名证书、转换证书格式等

openssl x509 -req -in idig8.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out idig8.crt -days 1000

查看证书信息

ls# idig8,crt，idig8.csr ，idig8.key

证书文件和私钥文件在k8s集群中创建新的凭证和上下文(Context)

 kubectl config set-credentials idig8 --client-certificate=idig8.crt  --client-key=idig8.key

用户idig8创建了，然后为这个用户设置新的 Context

kubectl config set-context idig8-context --cluster=kubernetes --namespace=kube-system --user=idig8

• ② 创建角色

创建角色绑定权限，创建dig8-role.yaml文件 verbs: ["*"] 代表所有权限

apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:  name: idig8-role  namespace: kube-systemrules:- apiGroups: ["", "extensions", "apps"]  resources: ["deployments", "replicasets", "pods"]  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

执行创建

kubectl apply -f idig8-role.yaml

查看信息

kubectl get role -n kube-system

• ③ 角色权限绑定

有了角色，角色需要绑定某个用户，才能完成某个用户的权限。 创建绑定的rolebinding.yaml 文件中我们看到了subjects关键字，这里就是我们上面提到的用来尝试操作集群的对象，这里对应上面的 User 帐号 idig8

apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  name: idig8-rolebinding  namespace: kube-systemsubjects:- kind: User  name: idig8  apiGroup: ""roleRef:  kind: Role  name: idig8-role  apiGroup: ""

使用kubectl创建上面的资源对象

kubectil apply -f idig8-rolebinding.yaml

• ④ 测试下 idig8-context上下文来操作

2个命令查询结果是一样的

kubectl get pods --context=idig8-context kubectl get pods -n kube-system

如果查看-n=default 就会报错

 kubectl get pods -n default

这是给咱们一个用户绑定权限的方式。

（三）创建访问某个 namespace 的用户

创建一个ServiceAccount一个集群内部的用户只能操作 kube-system 这个命名空间下面的 pods 和 deployments

• ① 创建 ServiceAcount 对象

kubectl create sa idig8-sa -n kube-system

• ② 新建一个 Role 对象

角色没有创建、删除、更新 Pod 的权限

kubectl create -f idig8-sa-role.yaml

• ③ 新建一个角色和用户的绑定

创建一个 RoleBinding 对象，将上面的 idig8-sa 和角色 idig8-sa-role 进行绑定

kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:  name: idig8-sa-rolebinding  namespace: kube-systemsubjects:- kind: ServiceAccount  name: idig8-sa  namespace: kube-systemroleRef:  kind: Role  name: idig8-sa-role  apiGroup: rbac.authorization.k8s.io

kubectl create -f idig8-sa-rolebinding.yaml

`

• ④ 查看关联的token

一个 ServiceAccount 会生成一个 Secret 对象和它进行映射，这个 Secret 里面包含一个 token。

kubectl get secret -n kube-system |grep idig8-sa# 查看上边对应的secret 打印出来kubectl get secret idig8-sa-token-nxgqx -o jsonpath={.data.token} -n kube-system |base64 -d

• ⑤ 使用dashboard 查看

使用上边的token

（四）创建访问所有 namespace 的用户

在创建一个新的 ServiceAccount，需要他操作的权限作用于所有的 namespace，需要使用到 ClusterRole 和 ClusterRoleBinding 这两种资源对象了。

• ① 创建 ServiceAcount 对象

kubectl create sa idig8-sa2 -n kube-system

• ② 然后创建一个 ClusterRoleBinding 对象

ClusterRoleBinding 资源对象，是作用于整个集群的，也没有单独新建一个 ClusterRole 对象，而是使用的 cluster-admin 这个对象，这是Kubernetes集群内置的 ClusterRole 对象，可以使用kubectl get clusterrole 和kubectl get clusterrolebinding查看系统内置的一些集群角色和集群角色绑定，这里使用的 cluster-admin 这个集群角色是拥有最高权限的集群角色，要谨慎使用该集群角色。

kind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1beta1metadata:  name: idig8-sa2-clusterrolebindingsubjects:- kind: ServiceAccount  name: idig8-sa2  namespace: kube-systemroleRef:  kind: ClusterRole  name: cluster-admin  apiGroup: rbac.authorization.k8s.io

kubectl create -f idig8-sa-rolebinding.yaml

`

• ③ 查看关联的token

一个 ServiceAccount 会生成一个 Secret 对象和它进行映射，这个 Secret 里面包含一个 token。

kubectl get secret -n kube-system |grep idig8-sa2# 查看上边对应的secret 打印出来kubectl get secret idig8-sa-token-nxgqx -o jsonpath={.data.token} -n kube-system |base64 -d

• ④ 使用dashboard 查看

使用上边的token

已经没有全面的提示权限问题了，因为已经设置了管理员权限

PS：RBAC只是k8s中的一种安全的认证方式，后面在一起说说k8s的关于安全的一些设计。