【K8S运维知识汇总】第4天4：rbac原理详解

最新推荐文章于 2024-08-14 02:56:39 发布

就叫一片白纸

最新推荐文章于 2024-08-14 02:56:39 发布

阅读量751

点赞数

分类专栏： K8S运维知识汇总

本文链接：https://blog.csdn.net/qq_33591055/article/details/107431327

版权

K8S运维知识汇总专栏收录该内容

54 篇文章 36 订阅

订阅专栏

kube-system下实例了两个deployment，核心资源，一个是coredns，一个是dashboard
在这里插入图片描述

traefik在daemonset里，两个pod控制器需要掌握，daemonset，deployment
在这里插入图片描述

这里使用json格式来展示的yaml
在这里插入图片描述

spec就是真正定义pod控制器的属性，selector就是标签选择器，
在这里插入图片描述

下面就是定义一个template模版，实际上是pod的模版，pod的一些特性就被定义到了pod控制器里，pod资源本身是一组对象，启动参数，内容，挂载，存活性探针都可以定义到pod控制器里
在这里插入图片描述

里面有一堆启动参数
在这里插入图片描述

一个是暴露81端口，一个是用nat的网络8080
在这里插入图片描述

resource是限制你pod的资源的
在这里插入图片描述

从spec到这都是pod特性，可以用explain来看显示的意思
在这里插入图片描述

serviceaccount服务账号，牵扯到了k8s的核心理念，rbac
在这里插入图片描述

基于角色的访问控制，RBAC（role basic access control）
在这里插入图片描述

对一些资源有一些权限（读get，写wirte，更新update，列出list，监视watch），用户就有用户账户，在k8s里有两种账户（用户账户user accoun UA，服务账户 service account SA）。
之前启动kubelet的时候做了一个kubeconfig配置文件，这个kubeconfig配置文件就是用户的配置文件
在这里插入图片描述

这个名字就是k8s集群里的一个用户账户，用户账户的名字就叫k8s的node
在这里插入图片描述

什么样的账户什么样的权限，这个就是授权的过程，k8s基于角色的访问控制下，无法直接给账户赋予权限，只能通过中间的一个角色，先给用户账户和服务账号先去绑定响应的角色，然后给相应的角色赋予相应的权限，也就是等于中间收个过路费
在这里插入图片描述

角色就完美充当了，账户要想获得集群里相应权限的中间人，无法给账户赋予直接的权限。
在这里插入图片描述

在k8s里有两种角色（role普通角色（只能应用在某一个特定的名称空间下，比如kube-system名称空间，就可以给kube-system里创建相应的角色，如果create一个role资源指定了-n namespace=kube-system，name这个角色只对本名称空间有效），clusterRole集群角色，对集群整个有效）

所以绑定角色操作就有2种，role binding，clusterrolebinding，把账户绑定角色，就称为绑定角色，也是一种资源，也有对应的yaml文件

服务账户是所有在k8s里面运行的pod，是k8s最小的运行单元，所有的pod都必须有一个服务用户service account

default名称空间，有两个起来的pod

在这里插入图片描述

对应的镜像是nginx;curl
在这里插入图片描述

只要运行在k8s集群里的pod，就一定有一个服务账户，如果没有显示指定的服务账户，就给你一个默认的服务账户
在这里插入图片描述

traefik的rbac的yaml文件最好看
在这里插入图片描述

第一段配置声明了一个叫service account的服务用户，这个服务用户的名字叫traefik-ingress-controller。名称空间在kube-system。
实际上这段就创建了服务用户
在这里插入图片描述

这一段其实在做clusterRole，相当于去声明一个集群角色，名字叫traefik-ingress-controller。然后定义了一组规则rules：定义角色的同时赋予权限
在这里插入图片描述

clusterRolebinding集群角色绑定，说白了就是把之前定义的角色和traefik-ingress-controller服务账号关联起来

在这里插入图片描述

metadata是name是集群角色绑定的名字，roleref是参考哪个集群角色是traefik-ingress-controller。
subjects就是集群角色给哪个用户使用，类型是服务用户，和集群角色通过clusterrolebinding这种资源，关联起来了
在这里插入图片描述

所有的rbac文件，无外乎这几步，创建账户，比如traefik是以pod身份在k8s集群工作，所以只能用服务账号。kubelet就不是工作在k8s里的，是在宿主机上二进制部署的，就不能用服务账户，而是用户账户，只能给kubelete做kubeconfig，kubecetl 4部，setuser，set creditals，seyt context ，use context，创建用户账户就需要这四步，实际上就是去创建一个用户账户的配置文件
在这里插入图片描述

traefik是通过pod的方式，交付在k8s里，pod要去取得一定的权限，必须给它创建一个服务账户，第二步就是定义角色去赋予角色相应的权限，就是创建一个clusterRole，就是traefike-ingress-clusterRole。
第三步是绑定角色（账户和角色绑定起来）
这就是RBAC的本质

traefik里的daemonset一定就指定你的service accountname就是你刚才创建的serviceaccount。既然有RBAC，就是让pod具有能够调度k8s里相应资源的能力，相当于创建一个serviceaccount账户，然后给这个账户赋予相应的权限，然后要对这个账户做角色绑定。
在声明traefik控制器的时候，要显示的指令，serviceaccountname就是traefik-ingress-controller
在这里插入图片描述

dashboard比traefik稍微复杂点
在这里插入图片描述

声明了一个服务账户，叫做kubernetes-dashboard-admin
在这里插入图片描述

下面做了角色绑定，没有做定义角色并赋予权限。做了一个clutserRolbinding的name是kubernetes-dashboard-admin。
roleRef是参考哪个角色，这里参考了默认集群里带有的集群角色cluster-admin，集群管理员
在这里插入图片描述

默认带有一堆集群角色，有一个默认的集群角色叫cluster-admin
在这里插入图片描述

这个yaml就是定义角色并赋予权限

在这里插入图片描述

名字是cluster-admin
在这里插入图片描述

权限是对所有api组，所有资源，所有权限，也就是具有k8s集群的最高权限
在这里插入图片描述

在dashboard的rbac.yaml里，只做了两件事情，
1.创建了一个新的服务账户service account
2.把创建好的账号和集群中默认的clsuterRole角色，绑定起来
在这里插入图片描述

默认的集群角色，名字是system:node
在这里插入图片描述

对api组里的哪些资源有哪些权限，对哪个资源组里的什么资源有什么权限
在这里插入图片描述

这个用户是k8s-node，给这个用户账户，去绑定一个集群角色，叫system:node（集群角色）。
真正绑定的时候cluter-node和user之间关系
在这里插入图片描述

这个dashboard的pod，它的用户账户就是k8s的最高权限
在这里插入图片描述

看一下官方的rbac文件
在这里插入图片描述

声明了一种role资源，这个role资源称为kubernetes-dashboard。名字是kubernetes-dashboard-minimal，说明我们要给dashboard最小化权限
在这里插入图片描述

给了一堆角色的权限
在这里插入图片描述

做了一个roleBinding
在这里插入图片描述

官方的service account写在deployment里了

在这里插入图片描述

官方也是三步，1.定义service account，2.定义一个普通角色并授予最小化权限，3.把普通角色和最小化权限做了绑定
其实告诉我们dashboard，可以不用集群管理员的形式运行
在这里插入图片描述

kubenetes dashboard可以接受两种配置文件，kubeconfig是普通用户的配置文件（把普通用户做出来，然后把普通用户绑定一个集群角色，这个集群角色可以是自定义的具有某些权限的角色或者集群角色，也可能是用默认的集群角色）
dashboard就要看你登录上来人具有什么权限
在这里插入图片描述