【2023】Kubernetes-RBAC简单使用

RBAC简单介绍

RBAC 是 Kubernetes 中的一种授权机制，全称为 Role-Based Access Control，基于角色的访问控制。

在 Kubernetes 中，RBAC 机制允许集群管理员通过创建和管理角色和绑定这些角色到用户、组或 ServiceAccount，从而控制对 Kubernetes 资源的访问权限。

在RBAC管理体系中，Kubernetes引入了4个资源对象：Role、ClusterRole、RoleBinding和ClusterRoleBinding。

• Role：作用于特定命名空间内的资源。
• ClusterRole：作用于整个集群内的资源。
• RoleBinding：将 Role 或 ClusterRole 与用户、组或 ServiceAccount 绑定的对象。
• ClusterRoleBinding：将 ClusterRole 与用户、组或 ServiceAccount 绑定的对象。

RBAC授权模型中，又分为以下三种情况

• 用户（User）：通常是集群的管理员或者开发人员。
• 组（Group）：多个用户组成的集合，用于更方便地管理多个用户的权限。
• ServiceAccount：用于 Pod 访问 Kubernetes API 的身份。

RBAC简单示例

Role

Role示例：用于访问某命名空间中的Pod资源，但不能访问其他资源

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: <namespace>name: <role-name>
rules:
- apiGroups: [""] # "" 标明 core API 组resources: ["pods"]verbs: ["get", "watch", "list"]

这个例子说明创建了一个Role资源，允许该namespace中任何ServiceAccount 使用 get、watch 和list操作来访问 Pod 资源。

ClusterRole

ClusterRole示例：创建一个 ClusterRole，使得某些用户可以访问所有命名空间内的 Pod，但是不能访问集群级别的资源。

也可以为以下资源授予访问权限：

• 集群范围资源（比如节点（Node））

• 非资源端点（比如 /healthz）

• 跨名字空间访问的名字空间作用域的资源（如 Pod）

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:# "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制name: <cluster-role-name>
rules:
- apiGroups: [""]# 在 HTTP 层面，用来访问 Secret 资源的名称为 "secrets"resources: ["pods"]verbs: ["get", "watch", "list"]

这是一个ClusterRole定义示例，该集群角色有权访问一个或所有namespace的pods（根据其被RoleBinding还是ClusterRoleBinding绑定而定）的权限。

RoleBinding

RoleBinding：将 Role 和用户、组或 ServiceAccount 绑定起来，使其具有访问特定命名空间内资源的权限。

示例：将 Role 绑定到一个 ServiceAccount 上，使该 ServiceAccount 具有读取和修改某个命名空间内某些资源的权限。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: my-role-bindingnamespace: my-namespace
subjects:
- kind: ServiceAccountname: my-service-accountnamespace: my-namespace
roleRef:kind: Rolename: my-roleapiGroup: rbac.authorization.k8s.io

在这个例子中， RoleBinding 将 my-role 与 my-service-account 绑定在了一起，使得 my-service-account 具有访问 my-namespace 命名空间内 my-role 定义的资源的权限。

subjects下kind用于决定角色类型

clusterrolebinding

clusterrolebinding：ClusterRoleBinding 的作用是将一个 ClusterRole 绑定到一个用户、组或 ServiceAccount 上，从而赋予该用户、组或 ServiceAccount 访问整个集群内的资源的权限。

示例：用ClusterRoleBinding 将 my-clusterrole 与 my-username 绑定在了一起，使得 my-username 具有访问整个集群内 my-clusterrole 定义的资源的权限。

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: my-clusterrole-binding
subjects:
- kind: Username: my-username
roleRef:kind: ClusterRolename: my-clusterroleapiGroup: rbac.authorization.k8s.io

参数简单说明

几种资源类型的一些参数放在一起进行说明

• rules：对资源的访问控制规则
• apiGroups：指定资源所在的 API 组。例如，apiGroups: [“”, “extensions”, “apps”] 表示这个 rule 适用于 core、extensions 和 apps API 组中的资源。
• resources：指定要控制的资源类型。例如，resources: [“pods”, “deployments”] 表示这个 rule 适用于 Pods 和 Deployments 资源。
• verbs：指定要允许的操作。例如，verbs: [“get”, “list”, “watch”] 表示允许对资源进行查看、列出和监视操作。
• subjects：关联角色
• 用于指定与 RoleBinding 或 ClusterRoleBinding 相关联的 Role 或 ClusterRole。

聚合的 ClusterRole

Kubernetes支持将多个ClusterRole聚合成一个新的ClusterRole，这在希望将多个ClusterRole的授权规则进行合并使用时，可以简化管理员的手工配置工作，完成对系统默认ClusterRole的扩展。

通过aggregationRule字段设置需要包含的ClusterRole，使用Label Selector的形式进行设置，逻辑为包含具有指定标签的ClusterRole。

示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: monitoring
aggregationRule:clusterRoleSelectors:- matchLabels:rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # 控制面自动填充这里的规则

如果用户创建了一个包含上述标签的ClusterRole，则系统会自动为聚合ClusterRole设置其rules。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: monitoring-endpointslabels:rbac.example.com/aggregate-to-monitoring: "true"
# 当你创建 "monitoring-endpoints" ClusterRole 时，
# 下面的规则会被添加到 "monitoring" ClusterRole 中
rules:
- apiGroups: [""]resources: ["services", "endpointslices", "pods"]verbs: ["get", "list", "watch"]