k8s权限管理（RBAC）

1：安全认证

1、访问控制概述

• 客户端
  
  
  
  • useraccount，一般是独立于k8s之外的其他服务管理的用户账号
    
  • serviceaccount，k8s管理的账号，用于为pod中的服务进程在访问k8s时提供身份标识
    
  
  

服务账户：

• service account adminsion controller:
  
  
  
  • 对于pod进行修改，创建
    
  
  

• 授权裁决
  
  
  
  • api请求的k8s授权在api服务器内进行，api服务器根据所有策略评估所有的请求属性，然后允许或拒绝请求
    
  • api的请求的所有部分,都必须通过某种授权来允许机制以便继承访问，默认情况下拒绝访问
    
  • 
    
  
  

2、焦点概念

1、脚色(Role)与集群脚色(ClusterRole)

用于定义对资源的访问权限

• 脚色(Role)---命名空间下的权限的设置(增编削查)
  
  
  
  • role是一种kubernetes对象，它定义了特定命名空间内资源的一组权限，这些权限可以是创建，读取，更新和删除等操作，针对特定的API资源对象(Pod,Service,CongifMap等)
    
  • role对象只在特定的命名空间内收效，即它定义的权限只适用于该命名空间内的资源
    
  
  
• 集群脚色(ClusterRole)---对于整个集群的权限的设置
  
  
  
  • ClusterRole也是一种k8s对象，与Role雷同，但是作用的范围更广泛，可以应用于整个集群，而不限于特定的命名空间
    
  • ClusterRole定义了对集群范围内的资源的权限，可以包罗所有命名空间中资源，也可以包含集群级别的资源，比方，节点，命名空间等
    
  
  
• 二者的区别
  
  
  
  • role的作用范围只有对名称空间,而ClusterRole作用的与整个集群的资源
    
    
    
    
  
  

2、脚色绑定(RoleBinding)与集群脚色绑定(ClusterRoleBinding)

在kubernetes中，脚色绑定和集群脚色绑定用于将用户，组，或服务账户与脚色或集群脚色关联起来，从而赋予他们相应的权限，他们的作用就是将权限分配给特定的实体，使其能够执行定义在脚色或集群脚色中的操作

• 脚色绑定(RoleBinding)
  
  
  
  • RoleBinding是一种kubernetes对象，用于将特定的脚色(role)与特定的用户，组，或者服务账户绑定在一起，从而赋予他们在某个命名空间内的资源上执行操作的权限
    
  • 比方，可以创建一个RoleBinding，将脚色(editor)与用户alice绑定在一起,如许alice就具有在特定命名空间内编辑资源的权限
    
  
  
• 集群脚色绑定(ClusterRoleBinding)
  
  
  
  • 作用范围更加的广,将集群脚色与用户，组，服务账户绑定在一起，赋予他们在整个集群范围内执行操作的权限
    
  • 比方,可以创建一个ClusterRoleBind,将集群脚色管理员(ClusterAdmin)与用户组"管理员组"绑定在一起,如许管理员组就具有在整个集群中执行管理员操作的权限
    
  
  
• 通过脚色绑定,kubernetes管理员可以机动的控制不同用户，组,服务账户对集群资源的访问权限，从而实现安全的权限管理
  
  
  
  

3、主体(Subject)

在kubernetes中，主体(Subject)是具有身份的实体,通常是用户，组，或服务账户，主体通过脚色绑定或者集群脚色绑定与脚色或者集群脚色关联在一起，从而获取对kubernetes资源的访问权限

• 主体
  
  
  
  • 用户：k8s中与外部身份验证服务集成,以允许使用基于用户和密码的身份验证机制登录到集群中，登录成功后，用户被视为主体，并根据被分配脚色获得相应的权限
    
  • 组：在某些情况下，将一组用户构造在一起，并且为整个组分配权限可能更加的方便，不消一个一个的用户分配权限，他们参加到一个组中，然后对于这个组分配权限;可以通过脚色绑定或集群脚色绑定将组与脚色或者集群脚色关联起来,从而将权限分配给组内的所有成员，快捷
    
  • 服务账户：服务账户是k8s一种特殊类型的身份，用于表现正在运行的容器或pod,他们通常用于实现应用程序和其他k8s部署的自动化任务，通常为服务账户分配适当的脚色或集群脚色，可以确保他们具有执行操作所需的权限
    
  
  
• 总之
  
  
  
  • 主体在k8s中代表了具有身份的实体，通过脚色绑定，或集群脚色绑定相关联，从而获得对k8s资源的访问权限
    
  
  

3、RBAC在k8s中实现

1、k8s api server与RBAC组件

kubernetes api server与RBAC组件之间实现认证授权机制过程如下

• 认证(Authentication)
  
  
  
  • 当用户或服务向api server发起请求时,首先会经过认证阶段,认证过程验证请求的身份是否合法,并确定请求的发起者是谁，哪一个主体(用户,组，服务账户)
    
  • k8s支持多种认证方式,包罗基本验证,客户端证书认证,Token认证等，用户可以根据需求选择适合的认证方式
    
  • 认证成功后,api server将为请求分配一个身份标识，用于后续的操作
    
  
  
• 授权(Authorization)---流程
  
  
  
  • 在认证成功后,api server 会将请求与RBAC规则进行匹配，以确定请求是否被允许执行，这个过程被称为授权
    
  • RBAC规则由Role,ClusterRole，RoleBinding和ClusterRoleBinding定义，用于描述用户，组或服务账户在集群中的访问权限
    
  • 当请求达到API server后，api server会将请求中包含的身份信息，以及RBAC规则中定义的权限来决定是否允许执行请求所涉及的操作
    
  • 如果请求的身份与RBAC规则匹配且有足够的权限，则api server授权请求执行操作，否则，请求被拒绝，并返回相应的错误信息
    
  
  
• 总之
  
  
  
  • 综上所述,api server与RBAC组件之间实现认证授权机制过程包罗认证和授权2个阶段,认证阶段用于验证请求的身份,确定请的发起者是谁;授权阶段则用于根据RBAC规则查抄请求的权限,决定是否运行执行操作,这个2个阶段共同构成了k8s的访问控制机制,  确保请求的合法性和安全性
    
    
    
    
  
  

2、RBAC权限查抄流程

RBAC(基于脚色的访问控制),在k8s中权限查抄流程如下

• 认证
  
  
  
  • 用户或服务通过身份验证机制(证书，令牌等)与api server建立连接
    
  
  
• 授权：一但用户或服务通过认证，api server对请求的进行授权查抄，授权查抄的过程包罗以下步调
  
  
  
  • 识别主体，api server根据认证信息识别请求的主体,即发送请求的用户，服务或实体
    
  • 确定请求的操作和目标资源，api server解析请求中包含的操作(比方,get,post,delete等)和目标资源(pod,deploy等)
    
  • 查询RBAC规则,api server根据主体和请求的操作的资源,查询与之相关的RABC规则,这些规则通常存储在集群中的role,ClusterRole，rolebinding和clusterrolebinding中
    
  • 匹配规则，api server会将查询到的规则与请求的进行匹配,如果存在请求匹配的规则,则请求被授权执行，否则，请求被拒绝
    
  
  
• 执行请求：如果请求同构了授权查抄，api server将hi执行请求所代表的操作，列如创建，更新，删除资源等
  
• 通过以上的流程，RBAC系统实现了对用户和服务细粒度访问控制，确保只有经过授权的和服务才能执行特定的操作
  
  
  
  

2、操作

1、Role资源的编写

1. apiVersion: rbac.authorization.k8s.io/v1
2. kind: Role
3. metadata:
4.    name: pod-reader   #角色的名称
5.    namespace: dev     #名称空间的权限设置
6. rules:
7. - apiGroups: [""]  #管理的资源组
8.   resources: ["pods"]   #具体的资源
9.   verbs: ["get","list"]   #具体的操作
11. #rule只能对于一个名称空间设置权限，

复制代码

3、创建平常用户和服务账户

1、创建平常用户

原理：通过创建证书和切换上下文环境的方式来创建和切换用户

1. #创建证书
2. ##创建私钥
3. [root@master ~]# openssl genrsa -out devuser.key 2048
4. ##利用私钥创建一个csr(证书请求)文件
5. openssl req -new -key devuser.key -subj "/CN=devuser" -out devuser.csr
7. ##私钥加上请求文件生成证书
8. openssl x509 -req -in devuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out devuser.crt -days 365
11. #生成账号
12. [root@master ~]#  kubectl config set-credentials devuser --client-certificate=./devuser.crt --client-key=./devuser.key --embed-certs=true
13. User "devuser" set.
15. #设置上下文参数，这里设置名称空间没有直接的关系，并不是这个用户只能在这个名称空间下面操作，其他的空间也可以，要设置权限
16. kubectl config set-context devuser@kubernetes --cluster=kubernetes --user=devuser --namespace=dev
18. #查看上下文
19. [root@master ~]#  kubectl config get-contexts
20. CURRENT   NAME                          CLUSTER      AUTHINFO           NAMESPACE
21.           devuser@kubernetes            kubernetes   devuser            dev
22. *         kubernetes-admin@kubernetes   kubernetes   kubernetes-admin   
24. #切换为创建的用户的上下文环境中
25. [root@master ~]# kubectl config use-context devuser@kubernetes
26. Switched to context "devuser@kubernetes".
27. #发现看不了，因为没有设置这个用户的相关的权限
28. [root@master ~]# kubectl get pod -n dev
29. Error from server (Forbidden): pods is forbidden: User "devuser" cannot list resource "pods" in API group "" in the namespace "dev"
31. #对账号进行授权，先切换回来
32. kubectl config use-context kubernetes-admin@kubernetes
34. #授权文件
35. apiVersion: rbac.authorization.k8s.io/v1
36. kind: Role
37. metadata:
38.    name: devuser-role
39.    namespace: dev
40. rules:
41. - apiGroups: ["*"]
42.   resources: ["pods"]
43.   verbs: ["list"]  #这里只设置了list这个权限，就是查看名称空间下面的所有资源
45. ---
46. apiVersion: rbac.authorization.k8s.io/v1
47. kind: RoleBinding
48. metadata:
49.    name: devuser-rolebinding
50.    namespace: dev
51. subjects:
52. - kind: User
53.   name: devuser
54.   apiGroup: rbac.authorization.k8s.io
55. roleRef:
56.   kind: Role
57.   name: devuser-role
58.   apiGroup: rbac.authorization.k8s.io
61. [root@master role]# kubectl create -f devuser.yaml
62. role.rbac.authorization.k8s.io/devuser-role created
63. rolebinding.rbac.authorization.k8s.io/devuser-rolebinding created
67. #切换到创建的新用户上面，切换上下文件环境
68. #发现只有获取这个名称空间下面资源的权限，其余的权限都没有赋予
69. [root@master role]# kubectl config use-context devuser@kubernetes
70. Switched to context "devuser@kubernetes".
71. [root@master role]# kubectl get pod -n dev
72. NAME     READY   STATUS    RESTARTS   AGE
73. centos   1/1     Running   0          21h
74. [root@master role]# kubectl delete pod -n dev centos
75. Error from server (Forbidden): pods "centos" is forbidden: User "devuser" cannot delete resource "pods" in API group "" in the namespace "dev"

复制代码

2、创建组

3、创建服务账户

1. [/code][size=4]3、账户相关的操作[/size]
3. [code]#查看上下文
4. [root@master ~]#  kubectl config get-contexts
5. CURRENT   NAME                          CLUSTER      AUTHINFO           NAMESPACE
6.           devuser@kubernetes            kubernetes   devuser            dev
7. *         kubernetes-admin@kubernetes   kubernetes   kubernetes-admin   
9. #查看用户相关的权限，查看绑定的相关
10. [root@master ~]# kubectl get rolebindings --all-namespaces | grep devuser
11. [root@master ~]# kubectl get clusterrolebindings | grep devuser

复制代码

4、参数的设置

1、kind为role,clusterrole资源

1、verbs参数

1. #Role,ClusterRole Verbs可以配置参数,定义的是操作
2. * 包含所有的
4. get --- 读取单个资源的详细信息，kubectl get pod my-pod -o yaml
6. list --- 列出这个名称空间下面的所有资源,kubectl get pods
9. watch --- 用于监视资源的变化事件(添加，删除，更新),kubectl get pods --watch
11. create --- 创建新的资源实例,kubectl create -f pod.yaml
13. update --- 用于更新现有的配置信息,kubectl apply -f pod.yaml
14. patch --- 更新部分现有的数据,kubectl patch pod my-pod -p '{"spec":{"containers":[{"name":"my-container","image":"my-new-image"}]}}'
16. delete --- 删除数据,kubectl delete pod my-pod
18. exec --- 在容器内执行命令,kubectl exec -it my-pod -- /bin/bash

复制代码

2、resource参数

1. * 包含所有的资源类型
3. “services”, “endpoints”, “pods”,“secrets”,“configmaps”,“crontabs”,“deployments”,“jobs”,“nodes”,“rolebindings”,“clusterroles”,“daemonsets”,“replicasets”,“statefulsets”,“horizontalpodautoscalers”,“replicationcontrollers”,“cronjobs”

复制代码

3、apigroup参数

1. #定义的是api资源，不同的类型
2. "*" --- 核心api组,pods,service,endpoint,namespace,nodes等
3. "apps" --- 控制器资源,deployments,daemonsets,statefulsets,replicasets等
4. "autoscaling" ---  API 组包含用于自动调整工作负载规模的资源，horizontalpodautoscalers (HPA)
5. "batch" --- API 组包含用于批处理任务的资源，jobs: 一次性任务，确保一个或多个 Pods 成功完成。
6. cronjobs: 基于时间调度的作业。

复制代码

2、RoleBinding和ClusterRoleBinding参数

1、subject参数

1. subjects:
2. - kind: ServiceAccount   #认证账户，服务账户，还有别的参数User
3.   name: mark   #名字
4.   namespace: default   #名称空间

复制代码

2、roleRef参数

1. roleRef:   #绑定角色的方式
2.   kind: ClusterRole   #集群角色绑定
3.   name: pod-clusterrole  #角色的名字
4.   apiGroup: rbac.authorization.k8s.io  #api 资源类型

复制代码

请求经过apiserver时，必须经过的
认证，授权，准入控制
2、


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。