【Kubernetes运维篇】RBAC认证授权详解(一)

一、RBAC授权认证理论知识

1、什么是RBAC授权？

RBAC是一种基于角色访问控制方式，它将权限和角色相关联，用户加入到角色中，就会拥有角色中的权限，RBAC的核心思想是，将权限赋予给角色，角色中加入多个用户，加入进来的用户会具有角色的权限，如果修改权限也是针对角色进行操作，而不是针对每个用户进行权限操作，这样效率太低了。

2、认证基本流程

第一步：认证，针对用户做认证，判断用户是否符合要求

K8S中主要通过APIservice对外提供服务，那么就需要针对apiserver做用户认证，如果任何用户都可以访问apiserver，那么就可以随意在K8S集群中创建、删除等操作，这就很危险了，也容易遭到黑客的攻击，所以我们需要针对apiserver做用户授权认证，确保是合法符合要求的用户。

第二步：授权，认证通过，针对用户做权限控制，赋予那些权限

认证通过后仅仅表示此用户是被apiserver进行的用户，可以访问apiserver，但是不一定拥有删除资源，创建资源的权限，需要进行授权操作，常见的授权方式有rbac授权。

第三步：准入控制

用户认证授权通过后，最后一步就是准入控制，K8S提供多种准入控制，有点类似于插件，为apiserver提供更好的 “可拓展性”。请求apiserver时，通过认证，鉴权后、持久化(api对象，保存到etcd前)，会经过"准入控制"，它可以做变更和验证。

比如：如果我们创建Pod时定义了资源上下限制，但不满足LimitRange规则中定义的资源上下限制，此时LimitRange就会拒绝我们的请求，假如我们定义了一个名称空间叫test，这个名称空间做下资源限制：限制最多可以使用10vCPU、10Gi内存，在这个名称空间下创建的所有Pod都不能超过这个限制。

3、K8S客户端访问apiserver的认证几方式

1、第一种：客户端认证

客户端认证也称双向TLS认证，kubectl在访问apiserver的时候，apiserver要经过CA认证kubectl用户是否合法的，如下图：

2、第二种：Bearertoken方式

Bearetoken方式，可以理解为apiserver将一个密码通过非对称加密方式告诉你了kubectl，然后通过该密码进行相互访问，如下图：

3、第三种：Serviceaccount方式

上面客户端认证、Bearertoken都是外部访问apiserver的时候使用的方式，而Serviceaccount这种方式是内部访问Pod和apiserver交互采用的一种方式。

Serviceaccount包括了Namespace、Token、CA、且通过目录挂载的方式给予Pod，当Pod运行起来的时候，会读取到这些信息，从而使用该方式和apiserver进行通信，如下图：

当我们使用kubectl操作K8S资源时，需要确定我们使用那个用户进行1访问那个K8S集群，kubectl操作默认读取 /root/.kube/config文件，也可以使用 kubectl config view 命令进行差看config文件内容。

如果config文件没有在/root/.kube/config ，可以使用 --kubeconfig 参数进行指定文件位置：

kubectl get nodes --kubeconfig=/root/.kube/config 

config文件内容如下：

4、RBAC授权常见角色绑定方式

1、第一种：用户基于RoleBinding绑定到Role上

特点：RoleBinding是具有名称空间限制的，这种方式只限定在Rolebinding的名称空间下，如下图：

2、第二种：用户基于RoleBinding绑定到ClusterRole上

特点：没有名称空间限制，如下图：

3、第三种：用户基于ClusterRoleBinding绑定到ClusterRole上

特点：对任何名称空间下用户都具有ClusteRrole所具有的权限，如下图：

5、准入控制插件基本介绍

官方中文参考文档

在K8S中准入控制器的模块有很多，其中比较常用的有LimitRanger、ResourceQuota、ServiceAccount，也是K8S默认启用的准入模块(具体看K8S版本)，我们只需要定义对应的规则即可。

如果是使用kubeadm方式搭建的K8S集群，我们可以修改 /etc/kubernetes/manifests/kube-apiserver.yaml文件中--enable-admission-plugins 参数定义使用的准入插件，多个使用逗号隔开，改完重启kubelet即可生效。

二、Useraccount、Serviceaccount基本使用

1、Useraccount、Serviceaccount介绍

Useraccount：用户账户，是给K8S集群外部用户使用的，如kubectl访问K8S集群要用useraccount用户，kubeadm搭建的K8s集群默认useraccount用户是kubernetes-admin。

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

Serviceaccount：服务账户，是给Pod使用的账户，就是在Pod容器内可以访问到apiserver，serviceaccount仅局限它所在的名称空间，每个名称空间创建是都会自动创建一个默认的serviceaccount，在创建Pod时，指定了此名称空间，且没有指定serviceaccount，那么这个Pod会使用此名称空间下默认的serviceaccount。

如下图，是在创建Pod时没有指定serviceaccount，会使用名称空间下默认的serviceaccount。

2、案例：创建ServiceAccount绑定到Pod

第一步：创建名为sa-test的ServiceAccount

 kubectl create sa sa-test

第二步：创建Pod指定ServiceAccount

cat sa-test.yaml 
---
apiVersion: v1
kind: Pod
metadata:
  name: sa-test
  namespace: default
spec:
  serviceAccountName: sa-test  # 指定sa
  containers:
  - name: sa-nginx
    image: nginx
    imagePullPolicy: IfNotPresent

kubectl apply -f sa-test.yaml

第三步：进入容器测试是否可以调用apiserver接口

kubectl exec -it sa-test  -- /bin/bash

指定sa后证书存放在/var/run/secrets/kubernetes.io/serviceaccount/目录

cd /var/run/secrets/kubernetes.io/serviceaccount/
ls
ca.crt	namespace  token

我们指定证书调用apiserver接口

curl --cacert ./ca.crt -H "Authorization: Bearer $(cat ./token)" https://kubernetesapi/v1/namespaces/kube-system

返回信息如下：就是被拒绝访问了，原因是我们只创建了sa用户，没进行授权

第四步：对sa做授权，然后在进行访问

创建一个 ClusterRoleBinding（集群角色绑定）来授予名为 sa-test 的服务账号在 default 命名空间下拥有 cluster-admin 集群角色的权限。通过这个绑定，sa-test 可以在整个集群中拥有最高权限，包括对集群节点、命名空间、Pod 等资源的管理权限。

kubectl create clusterrolebinding sa-test-admin --clusterrole=cluster-admin  --serviceaccount=default:sa-test

进入容器在请求一下：

kubectl exec -it sa-test  -- /bin/bash
cd /var/run/secrets/kubernetes.io/serviceaccount/

curl --cacert ./ca.crt -H "Authorization: Bearer $(cat ./token)" https://kubernetesapi/v1/namespaces/kube-system

进行授权后就可以访问到apiserver接口了如下图：

由于RBAC授权内容较多，分两次进行讲解，请关下篇文章，感谢支持~