一、Kubernetes 的权限管理
Kubernetes 主要通过 API Server 对外提供服务，Kubernetes 对于访问 API 的用户提供了相应的安全控制：认证和授权。认证解决用户是谁的问题，授权解决用户能做什么的问题。只有通过合理的权限控制，才能够保证整个集群系统的安全可靠。 API 访问需要经过的三个步骤，它们分别是：认证、授权和准入。

Kubernetes 提供了以下 4 种鉴权模式：

Node：一种特殊的授权模块，基于 Node 上运行的 Pod 为 Kubelet 授权
ABAC：基于属性的访问控制
RBAC：基于角色的访问控制
Webhook：HTTP 请求回调，通过一个 WEB 应用鉴定是否有权限进行某项操作本文主要是讲解RBAC鉴权模式。

二、Kubernetes权限管理相关概念
要认识Kubernetes中权限管理，需了解以下几个概念：

apiGroups：资源所属的API组："" 缺省为 core 组资源，如：extensions、apps、batch等。
resources：资源，如： pods、deployments、services、secrets 等。
verbs：动作，如： get、list、watch、create、delete、update 等。
Rule：规则，一组属于不同 API Group 的操作集合；
Role：角色，用于定义一组对 Kubernetes API 对象操作的一组规则，范围限定在 namespace。
ServiceAccount（服务账号）为pod调用api server 准备的账号。
User account（用户账号）为用户调用api server 准备的。
ClusterRole：集群角色，该角色不受 namespace 的限制。
Subject：对象，也就是规则作用的对象。
RoleBinding：将角色和对象进行绑定，范围限定在 namespace。
ClusterRoleBinding：将集群角色和对象进行绑定，不受 namespace 限制。

让一个用户（Users）扮演一个角色（Role），角色拥有权限，从而让用户拥有这样的权限，随后在授权机制当中，只需要将权限授予某个角色，此时用户将获取对应角色的权限，从而实现角色的访问控制，在 Kubernetes的授权机制当中，采用 RBAC 的方式进行授权，其工作逻辑是，把对对象的操作权限定义到一个角色当中，再将用户绑定到该角色，从而使用户得到对应角色的权限。如果通过 rolebinding 绑定 role，只能对 rolebingding 所在的名称空间的资源有权限。另外，Kubernetes 为此还有一种集群级别的授权机制，就是定义一个集群角色（ClusterRole），对集群内的所有资源都有可操作的权限，从而将 User2 通过 ClusterRoleBinding 到 ClusterRole，从而使 User2 拥有集群的操作权限，他们之间的关系如下图所示：

三、具体应用示例
我们以AnyRobot中， nginx-ingress-serviceaccount-nginx SA账号为示例，并将nginx-ingress-role-nginx和nginx-ingress-serviceaccount-nginx进行绑定
1、创建nginx-ingress-serviceaccount-nginx SA账号

apiVersion: v1
kind: ServiceAccount
metadata:
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
name: nginx-ingress-serviceaccount-nginx
namespace: anyrobot
secrets:
- name: nginx-ingress-serviceaccount-nginx-token-kv2vf

2、创建nginx-ingress-role-nginx Role权限

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
name: nginx-ingress-role-nginx
namespace: anyrobot
rules:
- apiGroups:
- "" #core api组
resources:
- namespaces
verbs:
- get #具备的权限
- apiGroups:
- ""
resources:
- configmaps
- pods
- secrets
- endpoints
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- services
verbs:
- get
- list
- update
- watch
- apiGroups:
- extensions
- networking.k8s.io
resources:
- ingresses
verbs:
- get
- list
- watch
- apiGroups:
- extensions
- networking.k8s.io
resources:
- ingresses/status
verbs:
- update
- apiGroups:
- networking.k8s.io
resources:
- ingressclasses
verbs:
- get
- list
- watch
- apiGroups:
- ""
resourceNames:
- ingress-controller-leader-nginx
resources:
- configmaps
verbs:
- get
- update
- apiGroups:
- ""
resources:
- configmaps
verbs:
- create
- apiGroups:
- ""
resources:
- endpoints
verbs:
- create
- get
- update
- apiGroups:
- ""
resources:
- events
verbs:
- create
- patch
- apiGroups:
- discovery.k8s.io
resources:
- endpointslices
verbs:
- list
- get
- watch
- apiGroups:
- coordination.k8s.io
resources:
- leases
verbs:
- create
- get
- update

3、将sa nginx-ingress-serviceaccount-nginx与nginx-ingress-role-nginx role 进行绑定

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
creationTimestamp: "2023-06-14T10:42:18Z"
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
name: nginx-ingress-role-nisa-binding-nginx
namespace: anyrobot #授权的命名空间为anyrobot
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: nginx-ingress-role-nginx # 绑定nginx-ingress-role-nginx role
subjects:
- kind: ServiceAccount
name: nginx-ingress-serviceaccount-nginx # 绑定nginx-ingress-serviceaccount-nginx sa
namespace: anyrobot

4、以上步骤完成后，sa账号nginx-ingress-serviceaccount-nginx即具备nginx-ingress-role-nginx role权限了，同时，AnyRobot也通过同样的方式，实现了其他账号权限细粒度控制。

点个赞吧！

请就本文对您的益处进行评级：

返回上一篇:AnyRobot Pod和ConfigMap有何关联... 下一篇：AnyRobot Eyes 5.0.1.5 版本发布...

标签

产品技术