云原生 | 从零开始学Kubernetes二十八完结篇—rbac授权深入讲解

Posted 2023-04-04 cloud、泡泡

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了云原生 | 从零开始学Kubernetes二十八完结篇—rbac授权深入讲解相关的知识，希望对你有一定的参考价值。

该篇文章已经被专栏《从零开始学k8s》收录
上一篇文章：配置管理中心Secret和rbac授权点击跳转

rbac授权

写在最后

上一篇文章的下部分

1、ServiceAccount

Service account 是为了方便 Pod 里面的进程调用 Kubernetes API 或其他外部服务而设计的。它与 User account 不同，User account 是为人设计的，而 service account 则是为 Pod 中的进程调用 Kubernetes API 而设计；User account 是跨 namespace 的，而 service account 则是仅局限它所在的 namespace；每个 namespace 都会自动创建一个 default service account；开启 ServiceAccount Admission Controller 后

1）每个 Pod 在创建后都会自动设置 spec.serviceAccount 为 default（除非指定了其他 ServiceAccout）

2）验证 Pod 引用的 service account 已经存在，否则拒绝创建；

当创建 pod 的时候，如果没有指定一个 serviceaccount，系统会自动在与该 pod 相同的 namespace 下为其指派一个 default service account。这是 pod 和 apiserver 之间进行通信的账号，如下：

[root@k8smaster secret]# kubectl get pods
NAME                               READY   STATUS              RESTARTS   AGE
mysql-pod-volume                   1/1     Running             0          50m
nginx-f89759699-5qdtn              1/1     Running             1          19d
pod-secret                         1/1     Running             0          17m
pod-secret-volume                  1/1     Running             0          11m
[root@k8smaster secret]# kubectl get pods mysql-pod-volume -o yaml | grep "serviceAccountName"
  serviceAccountName: default
[root@k8smaster secret]# kubectl describe pods mysql-pod-volume
Volumes:
  mysql-config:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      mysql
    Optional:  false
  default-token-788ff:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-788ff
    Optional:    false

 
从上面可以看到每个 Pod 无论定义与否都会有个存储卷，这个存储卷为 default-token-***。pod 和 apiserver 的认证信息通过 secret 进行定义，由于认证信息属于敏感信息，所以需要保存在 secret 资源当中，并以存储卷的方式挂载到 Pod 当中。从而让 Pod 内运行的应用通过对应的 secret 中的信息来连接 apiserver，并完成认证。每个 namespace 中都有一个默认的叫做 default 的 serviceaccount 资源。查看名称空间内的 secret，也可以看到对应的 default-token。让当前名称空间中所有的 pod 在连接 apiserver 时可以使用的预制认证信息，从而保证 pod 之间的通信。
 
[root@k8smaster secret]# kubectl get sa
NAME              SECRETS   AGE
default           1         19d

[root@k8smaster secret]# kubectl get secret
NAME                          TYPE                                  DATA   AGE
default-token-788ff           kubernetes.io/service-account-token   3      19d

默认的 service account 仅仅只能获取当前 Pod 自身的相关属性，无法观察到其他名称空间 Pod 的相关属性信息。如果想要扩展 Pod，假设有一个 Pod 需要用于管理其他 Pod 或者是其他资源对象，是无法通过自身的名称空间的 serviceaccount 进行获取其他 Pod 的相关属性信息的，此时就需要进行手动创建一个 serviceaccount，并在创建 Pod 时进行定义。那么 serviceaccount 该如何进行定义呢？实际上，service accout 也属于一个 k8s 资源，serviceAccount 也属于标准的 k8s 资源，可以创建一个 serviceAccount，创建之后由我们创建的 pod 使用 serviceAccountName 去加载自己定义的 serviceAccount 就可以了，如下：

[root@k8smaster secret]# kubectl create sa paopao
serviceaccount/paopao created
[root@k8smaster secret]# kubectl get sa
NAME              SECRETS   AGE
default           1         19d
nfs-provisioner   1         47h
paopao            1         3s
[root@k8smaster secret]# kubectl describe sa paopao
Name:                paopao
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   paopao-token-g72jh
Tokens:              paopao-token-g72jh			#自动生成token
Events:              <none>
[root@k8smaster secret]# kubectl get secret
NAME                          TYPE                                  DATA   AGE
default-token-788ff           kubernetes.io/service-account-token   3      19d
mysecret                      Opaque                                2      27m
mysql-password                Opaque                                1      40m
nfs-provisioner-token-tv5dl   kubernetes.io/service-account-token   3      2d
paopao-token-g72jh            kubernetes.io/service-account-token   3      31s		#自动生成secret
[root@k8smaster secret]# kubectl describe secret paopao-token-g72jh 
Name:         paopao-token-g72jh
Namespace:    default
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: paopao
              kubernetes.io/service-account.uid: 74643ebf-6198-4b3a-9aee-ea0da0e6b1a8

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1025 bytes
namespace:  7 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6ImpCVzZXa0U2WDczX0NMeU1yUDM5YkluTWVPdlNFbUp0UnF3aVNnVzhXTkUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InBhb3Bhby10b2tlbi1nNzJqaCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJwYW9wYW8iLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI3NDY0M2ViZi02MTk4LTRiM2EtOWFlZS1lYTBkYTBlNmIxYTgiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpwYW9wYW8ifQ.IzS3gXVOMXlKWSyVk-4Xh04351XkoG5axWba1fOwhrFLMNRT2RdMm3LRvvki_WIuL8prvGNerMt4cG3YzRIgLMTZ1Rk3BtLzo3HY9D4qr4FxZxXdFsqd87kHG5_ExpqzAHn__anL5758XMvsuQCwf-k6wRktbGOIDb6jXZuCVViRyomWWPJaLIBXa5BBlXHKft9mXuM6--293w21-RPTW29tMaIVf18bWXU3OpaPFiULtpUB3faqqmS3H7dKrbwn1uhSwmp4mxU1ossXCcPAdxL-Shh9L3yZ6fTuZTDxgmKb9yF6twVwcmuLr5HFZ3a5Tr_TVI91Z6IBXYlnu0bYuw	#可以看到有这个

上面可以看到生成了 paopao-token-g72jh 的 token 详细信息，这个 token 就是 sa 连接 apiserver 的认证信息，这个 token 也是登陆 k8s dashboard 的 token，这些是一个认证信息，能够登陆k8s，能认证到 k8s，但是不能做别的事情，不代表权限，想要做其他事情，需要授权
#比如在pod部署一个prometheus,如果要获取k8s监控指标要和apiserver交互，不然无法获取，这个时候需要生成sa，做一个rbac授权，比如可以对k8s所有资源下的所有名称空间都访问，才能获取到k8s资源

2、kubeconfig 文件

在 K8S 集群当中，每一个用户对资源的访问都是需要通过 apiserver 进行通信认证才能进行访问的，那么在此机制当中，对资源的访问可以是 token，也可以是通过配置文件的方式进行保存和使用认证信息，可以通过 kubectl config 进行查看配置，如下：

[root@k8smaster secret]# kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://192.168.11.139:6443	#apiserver 的地址
  name: kubernetes						#集群的名字
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes		#上下文的名字
current-context: kubernetes-admin@kubernetes	#当前上下文的名字
kind: Config
preferences: 
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
在上面的配置文件当中，定义了集群、上下文以及用户。其中 Config 也是 K8S 的标准资源之一，在该配置文件当中定义了一个集群列表，指定的集群可以有多个；用户列表也可以有多个，指明集群。而在上下文列表当中，是进行定义可以使用哪个用户对哪个集群进行访问，以及当前使用的上下文是什么。

授权

如果用户通过认证，什么权限都没有，需要一些后续的授权操作，如对资源的增删该查等， kubernetes1.6 之后开始有 RBAC（基于角色的访问控制机制）授权检查机制。 Kubernetes 的授权是基于插件形成的，其常用的授权插件有以下几种：

1）Node（节点认证）

2）ABAC(基于属性的访问控制)

3）RBAC（基于角色的访问控制）

4）Webhook（基于 http 回调机制的访问控制）

什么是 RBAC（基于角色的访问控制）？

让一个用户（Users）扮演一个角色（Role），角色拥有权限，从而让用户拥有这样的权限，随后在授权机制当中，只需要将权限授予某个角色，此时用户将获取对应角色的权限，从而实现角色的访问控制。如图：

在 k8s 的授权机制当中，采用 RBAC 的方式进行授权，其工作逻辑是，把对对象的操作权限定义到一个角色当中，再将用户绑定到该角色，从而使用户得到对应角色的权限。如果通过 rolebinding 绑定 role，只能对 rolebingding 所在的名称空间的资源有权限，上图 user1 这个用户绑定到 role1 上，只对 role1 这个名称空间的资源有权限，对其他名称空间资源没有权限，属于名称空间级别的；

另外，k8s 为此还有一种集群级别的授权机制，就是定义一个集群角色（ClusterRole），对集群内的所有资源都有可操作的权限，从而将 User2 通过 ClusterRoleBinding 到 ClusterRole，从而使 User2 拥有集群的操作权限。

Role、RoleBinding、ClusterRole 和 ClusterRoleBinding 的关系如下图：

通过上图可以看到，可以通过 rolebinding 绑定 role，rolebinding 绑定 clusterrole， clusterrolebinding 绑定 clusterrole。

上面我们说了两个角色绑定：

（1）用户通过 rolebinding 绑定 role

（2）用户通过 clusterrolebinding 绑定 clusterrole

还有一种：rolebinding 绑定 clusterrole

rolebinding 绑定 clusterrole 的好处：
假如有 6 个名称空间，每个名称空间的用户都需要对自己的名称空间有管理员权限，那么需要定义6个 role 和 rolebinding，然后依次绑定，如果名称空间更多，我们需要定义更多的 role，这个是很麻烦的，所以我们引入 clusterrole，定义一个 clusterrole，对 clusterrole 授予所有权限，然后用户通过 rolebinding 绑定到 clusterrole，就会拥有自己名称空间的管理员权限了

注：RoleBinding 仅对当前名称空间有对应的权限。

准入控制

一般而言，准入控制只是用来定义我们授权检查完成之后的后续的其他安全检查操作的，进一步补充了授权机制，由多个插件组合实行，一般而言在创建，删除，修改或者做代理时做补充。

Kubernetes 的 Admission Control 实际上是一个准入控制器(Admission Controller)插件列表，发送到 APIServer 的请求都需要经过这个列表中的每个准入控制器插件的检查，如果某一个控制器插件准入失败，就准入失败。

控制器插件如下：

AlwaysAdmit：允许所有请求通过

AlwaysPullImages：在启动容器之前总是去下载镜像，相当于每当容器启动前做一次用于是否有权使用该容器镜像的检查

AlwaysDeny：禁止所有请求通过，用于测试

DenyEscalatingExec：拒绝 exec 和 attach 命令到有升级特权的 Pod 的终端用户访问。如果集中包含升级特权的容器，而要限制终端用户在这些容器中执行命令的能力，推荐使用此插件

ImagePolicyWebhook ServiceAccount：这个插件实现了 serviceAccounts 等等自动化，如果使用 ServiceAccount 对象，强烈推荐使用这个插件

SecurityContextDeny：将 Pod 定义中定义了的 SecurityContext 选项全部失效。

SecurityContext 包含在容器中定义了操作系统级别的安全选型如 fsGroup，selinux 等选项

ResourceQuota：用于 namespace 上的配额管理，它会观察进入的请求，确保在 namespace 上的配额不超标。推荐将这个插件放到准入控制器列表的最后一个。ResourceQuota 准入控制器既可以限制某个 namespace 中创建资源的数量，又可以限制某个 namespace 中被 Pod 请求的资源总量。ResourceQuota 准入控制器和 ResourceQuota 资源对象一起可以实现资源配额管理。

LimitRanger：用于 Pod 和容器上的配额管理，它会观察进入的请求，确保 Pod 和容器上的配额不会超标。准入控制器 LimitRanger 和资源对象 LimitRange 一起实现资源限制管理

NamespaceLifecycle：当一个请求是在一个不存在的 namespace 下创建资源对象时，该请求会被拒绝。当删除一个 namespace 时，将会删除该 namespace 下的所有资源对象

DefaultStorageClass
DefaultTolerationSeconds
PodSecurityPolicy
当 Kubernetes 版本>=1.6.0，官方建议使用这些插件：
–admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds
当 Kubernetes 版本>=1.4.0，官方建议使用这些插件：
–admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota
以上是标准的准入插件，如果是自己定制的话，k8s1.7版 出了两个 alpha features, Initializers 和 External Admission Webhooks

RBAC 认证授权策略

RBAC 介绍

在 Kubernetes 中，所有资源对象都是通过 API 进行操作，他们保存在 etcd 里。而对 etcd 的操作我们需要通过访问 kube-apiserver 来实现，上面的 Service Account 其实就是 APIServer 的认证过程，而授权的机制是通过 RBAC：基于角色的访问控制实现。

RBAC 有四个资源对象，分别是 Role、ClusterRole、RoleBinding、ClusterRoleBinding

Role：角色

一组权限的集合，在一个命名空间中，可以用其来定义一个角色，只能对命名空间内的资源进行授权。如果是集群级别的资源，则需要使用 ClusterRole。
例如：定义一个角色用来读取 Pod 的权限
apiVersion: rbac.authorization.k8s.io/v1		#认证相关的api
kind: Role
metadata:
  namespace: rbac 								#只能对rbac这个名称空间才有权限
  name: pod-read								
rules:											#策略
  - apiGroups: [""]								#k8s所有的apiversion都支持 kubectl api-versions查看
    resources: ["pods"] 						#资源名字
    resourceNames: []							#如果需要具体的pod就写具体的 不写就是所有的
    verbs: ["get","watch","list"]				#具体的步骤吗，获取，查看，以列表列出来
rules 中的参数说明：
1、apiGroups：支持的 API 组列表，例如："apiVersion: batch/v1"等
2、resources：支持的资源对象列表，例如 pods、deplayments、jobs 等
3、resourceNames: 指定 resource 的名称
4、verbs：对资源对象的操作方法列表。

ClusterRole：集群角色

具有和角色一致的命名空间资源的管理能力，还可用于以下特殊元素的授权
1、集群范围的资源，例如 Node
2、非资源型的路径，例如：/healthz
3、包含全部命名空间的资源，例如 Pods
例如：定义一个集群角色可让用户访问任意 secrets
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secrets-clusterrole
rules:
  - apiGroups: [""]
    resources: ["secrets"]			#对所有名称空间下的secrets都有查看的权限
    verbs: ["get","watch","list"]

RoleBinding：角色绑定、ClusterRolebinding：集群角色绑定

角色绑定和集群角色绑定用于把一个角色绑定在一个目标上，可以是 User，Group，Service Account，使用 RoleBinding 为某个命名空间授权，使用 ClusterRoleBinding 为集群范围内授权。
例如：将在 rbac 命名空间中把 pod-read 角色授予用户 es
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-read-bind
  namespace: rbac
subjects:									#主体
- kind: User							
  name: es									#要对es这个用户
  apiGroup: rbac.authorization.k8s.io
roleRef:									#通过 pod-read-bind 绑定到roleref上
- kind: Role
  name: pod-read							#角色名字
  apiGroup: rbac.authorizatioin.k8s.io
#用户es在rbac这个命名空间下具有role设置的权限，比如资源查看

RoleBinding 也可以引用 ClusterRole，对属于同一命名空间内的 ClusterRole 定义的资源主体进行授权， 例如：es 能获取到集群中所有的资源信息
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: es-allresource
  namespace: rbac
subjects:
- kind: User
  name: es								#通过RoleBinding绑定到cluster-admin这个ClusterRole上 管理员的角色
  apiGroup: rbac.authorization.k8s.io
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin

集群角色绑定的角色只能是集群角色，用于进行集群级别或对所有命名空间都生效的授权
例如：允许 manager 组的用户读取所有 namaspace 的 secrets
apiVersion: rabc.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secret-global
subjects:
- kind: Group
  name: manager							#通过ClusterRoleBinding绑定到secret-read这个ClusterRole
  apiGroup: rabc.authorization.k8s.io
ruleRef:
- kind: ClusterRole
  name: secret-read						#读的权限
  apiGroup: rabc.authorization.k8s.io

资源的引用方式

多数资源可以用其名称的字符串表示，也就是 Endpoint 中的 URL 相对路径
例如 pod 中的日志是GET /api/v1/namaspaces/namespace/pods/podname/log

如果需要在一个 RBAC 对象中体现上下级资源，就需要使用“/”分割资源和下级资源。
例如：若想授权让某个主体同时能够读取 Pod 和 Pod log，则可以配置 resources 为一个数组
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: logs-reader
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods","pods/log"]				#对pods和podslog下的资源可以读取
  verbs: ["get","list"]

资源还可以通过名称（ResourceName）进行引用，在指定 ResourceName 后，使用 get、delete、update、patch 请求，就会被限制在这个资源实例范围内
例如，下面的声明让一个主体只能对名为 my-configmap 的 Configmap 进行 get 和 update 操作：
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namaspace: default
  name: configmap-update
rules:
- apiGroups: [""]
  resources: ["configmap"]
  resourceNames: ["my-configmap"]				#只能对这个名字my-configmap进行get和更新操作
  verbs: ["get","update"]

常见角色示例

（1）允许读取核心 API 组的 Pod 资源

rules:
- apiGroups: [""]					#读取所有apiversion的pods的资源可以查看信息等
  resources: ["pods"]
  verbs: ["get","list","watch"]

（2）允许读写 extensions 和 apps 两个 API 组中的 deployment 资源 rules:

- apiGroups: ["extensions","apps"]									#组名，apiversion下也能看到组
  resources: ["deployments"]										#对上面两个组下的deplo资源有下面的权限
  verbs: ["get","list","watch","create","update","patch","delete"]  #查看 更新 删除等

（3）允许读取 Pod 以及读写 job 信息

rules:
- apiGroups: [""]														#所有核心api
  resources: ["pods"]													#读取pods资源
  verbs: ["get","list","watch"]、
- apiVersion: ["batch","extensions"]									#能对这两个组的jobs资源删除更新等
  resources: ["jobs"]	
  verbs: ["get","list","watch","create","update","patch","delete"]

（4）允许读取一个名为 my-config 的 ConfigMap（必须绑定到一个 RoleBinding 来限制到一个 Namespace 下的 ConfigMap）：

rules:
- apiGroups: [""]					#所有api
  resources: ["configmap"]			#获取configmap资源
  resourceNames: ["my-configmap"]	#为资源取得名字，configmap可能很多，只能查看my-configmap这个configmap
  verbs: ["get"]

（5）读取核心组的 Node 资源（Node 属于集群级的资源，所以必须存在于 ClusterRole 中，并使用 ClusterRoleBinding 进行绑定）

rules:		
- apiGroups: [""]	
  resources: ["nodes"]				
  verbs: ["get","list","watch"]

（6）允许对非资源端点“/healthz”及其所有子路径进行 GET 和 POST 操作（必须使用 ClusterRole 和 ClusterRoleBinding）：

rules:
- nonResourceURLs: ["/healthz","/healthz/*"]	#定义两个具体路径
  verbs: ["get","post"]

常见的角色绑定示例

（1）用户名 alice
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
 
（2）组名 alice
subjects:
- kind: Group
  name: alice
  apiGroup: rbac.authorization.k8s.io
  
（3）kube-system 命名空间中默认 Service Account
subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

（4）qa 命名空间中的所有 Service Account：
subjects:
- kind: Group
  name: system:serviceaccounts:qa			#qa名称空间下所有的sa资源
  apiGroup: rbac.authorization.k8s.io

（5）所有 Service Account
subjects:
- kind: Group
  name: system:serviceaccounts				#所有的sa
  apiGroup: rbac.authorization.k8s.io
 
（6）所有认证用户
subjects:
- kind: Group
  name: system:authenticated				#同
  apiGroup: rbac.authorization.k8s.io
 
（7）所有未认证用户
subjects:
- kind: Group
  name: system:unauthenticated				#同
  apiGroup: rbac.authorization.k8s.io		
 
（8）全部用户
subjects:
- kind: Group
  name: system:authenticated				#包括认证与未认证用户
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

对 Service Account 的授权管理

Service Account 也是一种账号，是给运行在 Pod 里的进程提供了必要的身份证明。需要在 Pod 定义中指明引用的 Service Account，这样就可以对 Pod 进行赋权操作。例如：pod 内可获取 rbac 命名空间的所有 Pod 资源，pod-reader-sc 的 Service Account 是绑定了名为 pod-read 的 Role

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: rbac
spec:
  serviceAccountName: pod-reader-sc		#指定的sc 绑定到rbac命名空间下 可以读取pods
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
默认的 RBAC 策略为控制平台组件、节点和控制器授予有限范围的权限，但是除 kube-system 外的 Service Account 是没有任何权限的。

1 为一个应用专属的 Service Account 赋权
此应用需要在 Pod 的 spec 中指定一个 serviceAccountName。
用于API，Application，Manifest，kubectl create serviceaccount 等创建 Service Account 的命令。

例如为 my-namespace 中的 my-sa Service Account 授予只读权限
kubectl create rolebinding my-sa-view --clusterrole=view --serviceaccount=my-namespace:my-sa --namespace=my-namespace
kubectl 创建 rolebinding rbd 的名字 --service是my-namespace这个命名空间下通过rolebinding绑定到clusterrole上，view是安装k8s的时候默认的角色 只读权限。

2 为一个命名空间中名为 default 的 Service Account 授权
如果一个应用没有指定 serviceAccountName，则会使用名为 default 的 Service Account。
注意，赋予 Service Account “default”的权限会让所有没有指定 serviceAccountName 的 Pod都具有这些权限

例如，在 my-namespace 命名空间中为 Service Account“default”授予只读权限
kubectl create rolebinding default-view --clusterrole=view --serviceaccount=my-namespace:default --namespace=my-namespace

另外，许多系统级 Add-Ons（附加组件）都需要在 kube-system 命名空间中运行，要让这些 Add-Ons 能够使用超级用户权限，则可以把 cluster-admin 权限赋予 kube-system 命名空间中名为 default 的 Service Account，这一操作意味着 kube-system 命名空间包含了通向 API 超级用户的捷径。
kubectl create clusterrolebinding add-ons-add-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default

（3）为命名空间中所有 Service Account 都授予一个角色
如果希望在一个命名空间中，任何 Service Account 应用都具有一个角色，则可以为这一命名空间的 Service Account 群组进行授权
kubectl create rolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts:my-namespace --namespace=my-namespace

（4）为集群范围内所有 Service Account 都授予一个低权限角色
如果不想为每个命名空间管理授权，则可以把一个集群级别的角色赋给所有 Service Account。 
kubectl create clusterrolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts
让所有sa都具有查看的权限，创建pod时用任何一个sa就只有查看的权限

（5）为所有 Service Account 授予超级用户权限
kubectl create clusterrolebinding serviceaccounts-view --clusterrole=cluster-admin --group=system:serviceaccounts

使用 kubectl 命令行工具创建资源对象

（1）在命名空间 rbac 中为用户 es 授权 admin ClusterRole：
kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=es --namespace=rbac
#对于mes这个用户，他对rbac这个命名空间具有admin权限，通过rolebinding绑定到admin这个ClusterRole上
 
（2）在命名空间 rbac 中为名为 myapp 的 Service Account 授予 view ClusterRole：
kubctl create rolebinding myapp-role-binding --clusterrole=view --serviceaccount=rbac:myapp --namespace=rbac
#对于myapp这个sa用户，他对rbac这个命名空间就只有查看的权限，通过rolebinding绑定到admin这个ClusterRole上
 
（3）在全集群范围内为用户 root 授予 cluster-admin ClusterRole：
kubectl create clusterrolebinding cluster-binding --clusterrole=cluster-admin --user=root
#对于root这个用户，对所有的名称空间都具有管理员权限，通过clusterrolebinding绑定到admin这个ClusterRole上

（4）在全集群范围内为名为 myapp 的 Service Account 授予 view ClusterRole：
kubectl create clusterrolebinding service-account-binding --clusterrole=view --serviceaccount=myapp
#对于myapp这个sa用户，对所有的名称空间都具有查看的权限，通过clusterrolebinding绑定到view这个ClusterRole上

yaml 文件进行 rbac 授权：https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac

限制不同的用户操作 k8s 集群

ssl 认证 生成一个证书 
1 生成一个私钥 
[root@k8smaster secret]# cd /etc/kubernetes/pki/ 
[root@k8smaster pki]# (umask 077; openssl genrsa -out paopao.key 2048) 
Generating RSA private key, 2048 bit long modulus
.......................................................+++
.....................................................+++
e is 65537 (0x10001)

2 生成一个证书请求,并且生成证书
[root@k8smaster pki]# openssl req -new -key paopao.key -out paopao.csr -subj "/CN=paopao" 
[root@k8smaster pki]# openssl x509 -req -in paopao.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out paopao.crt -days 3650 					用ca这个机构颁发证书，paopao.crt这个证书是被ca.crt这个apiservion信任的
Signature ok
subject=/CN=paopao
Getting CA Private Key

在 kubeconfig 下新增加一个 lucky 这个用户 
1 把 paopao 这个用户添加到 kubernetes 集群中，可以用来认证 apiserver 的连接 
[root@k8smaster pki]# kubectl config set-credentials paopao --client-certificate=./paopao.crt --client-key=./paopao.key --embed-certs=true 
User "paopao" set.
#添加了一个用户paopao，用的客户端证书是paopao.crt，key是paopao.key。

[root@k8smaster pki]# vim /root/.kube/config	#不修改 进去查看刚才创建的用户
- name: paopao
  user:
 
2 在 kubeconfig 下新增加一个 lucky 这个账号 
[root@k8smaster pki]# kubectl config set-context paopao@kubernetes --cluster=kubernetes --user=paopao
Context "paopao@kubernetes" created.
这个上下文包括了k8s集群，用户是paopao

[root@k8smaster pki]# vim /root/.kube/config	#不修改 进去查看刚才创建的
- context:
    cluster: kubernetes
    user: paopao
  name: paopao@kubernetes
current-context: kubernetes-admin@kubernetes

3 切换账号到 paopao，默认没有任何权限 
[root@k8smaster pki]# kubectl config use-context paopao@kubernetes 
Switched to context "paopao@kubernetes".
[root@k8smaster pki]# kubectl get pods
Error from server (Forbidden): pods is forbidden: User "paopao" cannot list resource "pods" in API group "" in the namespace "default"
#没有权限！
[root@k8smaster pki]# kubectl config use-context kubernetes-admin@kubernetes 这个是集群用户，有所有权限 
把 user 这个用户通过 rolebinding 绑定到 clusterrole 上,授予权限,权限只是在 paopao 这个名称空间有效 

1 把 lucky 这个用户通过 rolebinding 绑定到 clusterrole 上 
[root@k8smaster ~]# kubectl create ns paopao 
namespace/paopao created
[root@k8smaster ~]# kubectl create rolebinding paopao -n paopao --clusterrole=cluster-admin --user=paopao
rolebinding.rbac.authorization.k8s.io/paopao created

2 测试是否有权限 
[root@k8smaster ~]# kubectl config use-context paopao@kubernetes 
Switched to context "paopao@kubernetes".
[root@k8smaster ~]# kubectl get pods					没有权限操作其他名称空间 
Error from server (Forbidden): pods is forbidden: User "paopao" cannot list resource "pods" in API group "" in the namespace "default"
[root@k8smaster ~]# kubectl get pods -n paopao			有权限操作这个名称空间 
No resources found in paopao namespace.

添加一个 paopao 的普通用户 
[root@k8smaster ~]# useradd paopao
[root@k8smaster ~]# cp /root/.kube/config /root/testconfig
[root@k8smaster ~]# vim /root/testconfig
#删除以下内容
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes

- name: kubernetes-admin
  user:
    client-certificate-data: 
#下面的两大行密钥也删除

[root@k8smaster ~]# cp -ar /root/.kube/ /home/paopao/ 
[root@k8smaster ~]# cp -ar /root/testconfig /home/paopao/.kube/config 
cp: overwrite ‘/home/paopao/.kube/config’? y
[root@k8smaster ~]# rm -f /home/paopao/.kube/testconfig 
[root@k8smaster ~]# chown -R paopao.paopao /home/paopao/ 
[root@k8smaster ~]# su - paopao
Last login: Sat Jul 16 00:47:20 PDT 2022 on pts/0
[paopao@k8smaster ~]$ kubectl get pods -n paopao
No resources found in paopao namespace.
#只能查看paopao这个命名空间

写在最后

创作不易，如果觉得内容对你有帮助，麻烦给个三连关注支持一下我！如果有错误，请在评论区指出，我会及时更改！

目前正在更新的系列：待定

感谢各位的观看，文章掺杂个人理解，如有错误请联系我指出~

云原生 | 从零开始学Docker一Docker的安装，启动以及工作原理

一丶Docker浅谈

1.1Docker为什么出现

我们知道，传统的项目开发和运维是两套环境，而且要一一配置环境并且有的时候更新还会导致服务不可用，这就很麻烦了，那么有没有一种很方便不用这么麻烦的技术可以一键安装呢？有！那就是我们的Docker。

1.2Docker能干吗

现在，用Docker可以打包应用以及环境到一个可移植的镜像中，然后发布到Linux或Windows操作系统的机器上，也可以实现虚拟化，十分的方便，用docker隔离，打包装箱，为了让不同东西放在同一个环境，通过隔离机制，把服务器利用到极致。（容器与容器之间互不影响，就和集装箱一样，每个都是单独的个体）
我们来对比一下优缺点

VM：资源占用多，冗余步骤多，启动慢（虚拟出硬件，完整的操作系统，在系统上运行）
容器化技术：不是模拟完整的系统，每个都是隔离起来的，一个崩了不影响其他的，直接运行在宿主机内容，没有自己的内核，不虚拟硬件，轻便。

并且，Docker能让系统运维更简单，测试环境高度一致，也不会出现操作系统不同不能用，有着高效资源利用，内核级别虚拟化，不需要管理程序，可以在一个机器上运行很多容器实例，压榨服务器性能到极致。

二、Docker的安装

2.1 Docker的组成

Docker分为三个部分组成：
1.镜像 image
2.容器 container
3.仓库 repository

镜像：镜像就像一个模板，可以通过这个模板创建容器服务，比如有个tomcat镜像，我们要运行起来然后它就会变成一个容器（提供服务）通过镜像可以创建多个容器，服务或者项目运行在容器中。

容器：Docker利用容器技术做到独立运行一个或者一组应用，通过镜像创建，有启动停止，删除这种基础操作，可以把容器看成简易的linux。

仓库：存放镜像的地方，有公有和私有，共有所有人都可以访问，Docker Hub，阿里云等都有容器服务。

2.2 安装前提

Docker 运行在 CentOS 7上，系统要是64位，内核版本为 3.10 以上。

Docker 运行在 CentOS-6.5 或更高的版本的 CentOS 上，系统要是64位，内核版本为 2.6.32-431 或者以上。

uname -r 查看自己的内核

2.3 安装步骤

官方文档安装点这里

第一步

确定自己的内核以及系统没问题之后，进行一下卸载旧版本，如果报告未安装这些包，则没有问题。

yum remove docker \\
                  docker-client \\
                  docker-client-latest \\
                  docker-common \\
                  docker-latest \\
                  docker-latest-logrotate \\
                  docker-logrotate \\
                  docker-engine

第二步

安装软件包并且配置镜像仓库

安装软件包的命令 yum install -y yum-utils

yum-util 提供yum-config-manager功能

镜像仓库配置 yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

这是阿里仓库，对比官方的镜像仓库会更快（因为官方在国外）。

第三步

检查更新yum索引并且安装Docker CE

检查索引 yum makecache fast

Docker-CE即社区版（由社区维护和提供技术支持，为免费版本，适合个人开发人员和小团队使用），EE 即企业版（为收费版本，由售后团队和技术团队提供技术支持，专为企业开发和IT团队而设计。相比Docker-EE，增加一些额外功能，更重要的是提供了更安全的保障）

yum install docker-ce docker-ce-cli containerd.io docker-compose-plugin

或者你想安装特定版本可以用这个指令

yum list docker-ce --showduplicates | sort -r 查看docker版本

yum -y install docker-ce-18.03.1.ce 安装18.03.1.ce版本

如果你用的宝塔界面，那么可以直接去宝塔官网软件商店下载Docker（比较方便）

如果你是腾讯云服务器，那么可以在服务器界面，点击更多

点击重装系统，选择docker镜像也可以直接安装，很方便

第四步

启动docker并且测试版本

如果你安装完成了，那么来尝试一下启动docker吧！

systemctl start docker

如果没有报错，那说明你启动成功了，然后我们设置一下开机自启动。

systemctl enable docker

随后我们检查一下docker的版本

docker version

没有问题！

docker都启动了，那能不玩一下？我们从最开始的helloworld开始！

docker run hello-world 这就是启动镜像的命令

如果你的界面出现了这个，那么说明你的docker没有问题！

此时我们查看一下docker的镜像

docker images

我们会发现刚才的hello-world就在里面！

第五步

最后就是我们的停止docker和卸载docker了

systemctl stop docker

这是停止的指令

yum remove docker-ce docker-ce-cli containerd.io

rm -rf /var/lib/docker

卸载首先卸载docker，然后删除docker的目录。

三、镜像加速

这个东西的话可以在阿里云设置。
登录阿里云，进入控制台，点击弹性计算，容器服务，容器镜像服务，在镜像工具里面有一个镜像加速器，选择对应版本的操作文档跟着来就好了。（腾讯云个人版本好像没有加速）

四、run的工作原理

五、Dokcer怎么工作的

docker是一个client-server结构的系统，docker的守护进程一直在后台运行在主机上（好比装了个mysql，一直在后台运行），通过Socket从客户端访问。Dockerserver（服务进程）接收到dockerclient的指令，就会执行这个命令。

客户端连接到守护进程之后它会启动一些容器，都在服务之内，通过这个守护进程造作容器资源（容器里面就好比有个小的linux虚拟机可以跑占用资源进程很少，互相隔离，如果想从外部访问要进行一个连通）

六、Docker为什么比VM快

Docker有更少的抽象层

vm要虚拟出硬件才行，而docker没有这一层，直接在主机安装服务，运行在服务里的每个隔离的都是容器由于docker不需要Hypervisor实现硬件资源虚拟化运行在docker容器上的程序直接使用的都是实际物理机的硬件资源。因此在CPU、内存利用率上docker将会在效率上有明显优势。

Docker不需要Guest OS

docker利用的宿主机的内核，vm是需要GuestOS。 docker不用重新加载一个操作系统内核，避免引导，虚拟机需要加载GuestOS，时间是分钟级别。docker是利用宿主机的操作系统，就不需要在虚拟出来了，省略了这个复杂的过程，时间是秒级。Docker底层用的是物理机的资源，虚拟机需要模拟物理机的操作系统，所以Docker加载得更快，而虚拟机更慢。

七、写在最后

创作不易，如果觉得内容对你有帮助，麻烦给个三连关注支持一下我！
目前正在更新的系列：从0开始的蓝桥杯省一之路，云原生系列。
感谢各位的观看，文章掺杂个人理解，如有错误请联系我指出~

以上是关于云原生 | 从零开始学Kubernetes二十八完结篇—rbac授权深入讲解的主要内容，如果未能解决你的问题，请参考以下文章

云原生 | 从零开始学Kubernetes三Kubernetes集群管理工具kubectl

云原生 | 从零开始学Kubernetes二使用kubeadm搭建K8S集群

云原生 | 从零开始学Docker六如何写出自己的镜像——Docker file

云原生 | 从零开始学Docker一Docker的安装，启动以及工作原理

云原生 | 从零开始学istio二Istio核心特性与架构

云原生（三十八） | Kubernetes篇之Jenkins入门和安装

云原生 | 从零开始学Kubernetes二十八完结篇—rbac授权深入讲解

rbac授权

1、ServiceAccount

2、kubeconfig 文件

授权

什么是 RBAC（基于角色的访问控制）？

准入控制

RBAC 认证授权策略

Role：角色

ClusterRole：集群角色

RoleBinding：角色绑定、ClusterRolebinding：集群角 色绑定

资源的引用方式

常见角色示例

常见的角色绑定示例

对 Service Account 的授权管理

使用 kubectl 命令行工具创建资源对象

限制不同的用户操作 k8s 集群

写在最后

云原生 | 从零开始学Docker一Docker的安装，启动以及工作原理

【从零开始学Docker】安装篇

一丶Docker浅谈

1.1Docker为什么出现

1.2Docker能干吗

二、Docker的安装

2.1 Docker的组成

2.2 安装前提

2.3 安装步骤

第一步

第二步

第三步

第四步

第五步

三、镜像加速

四、run的工作原理

五、Dokcer怎么工作的

六、Docker为什么比VM快

Docker有更少的抽象层

Docker不需要Guest OS

七、写在最后

RoleBinding：角色绑定、ClusterRolebinding：集群角色绑定