一、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接口了如下图：
文章来源：https://www.toymoban.com/news/detail-596401.html
由于RBAC授权内容较多，分两次进行讲解，请关下篇文章，感谢支持~文章来源地址https://www.toymoban.com/news/detail-596401.html
到了这里，关于【Kubernetes运维篇】RBAC认证授权详解(一)的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
