k8s rbac有哪些role

Kubernetes RBAC（基于角色的访问控制）中的Role包括ClusterRole、Role、Admin、Edit、View、AggregateRole。其中，ClusterRole是一种非命名空间的角色，可以在集群范围内使用；Role是一种命名空间的角色，只能在指定的命名空间内使用。ClusterRole更适用于集群管理员需要在多个命名空间之间进行统一管理的场景，而Role适用于需要对特定命名空间进行精细化权限控制的场景。

一、CLUSTERROLE

ClusterRole是在Kubernetes RBAC系统中用于定义非命名空间的权限资源。它可以授予对集群范围内的资源的访问权限，如节点、持久卷等。ClusterRole特别适合于集群管理员需要跨命名空间进行操作的场景。ClusterRole可以与ClusterRoleBinding绑定，从而授予用户、组或服务账户相应的权限。

ClusterRole的主要作用是提供一种集中的权限管理机制。例如，如果你有多个命名空间，并且想要某些用户具有在所有这些命名空间中读取Pod的权限，那么你可以创建一个ClusterRole并将其绑定到这些用户。这样，你只需要管理一个角色，而不是在每个命名空间中都创建一个Role。

典型的ClusterRole示例如下：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: read-pods
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

这个示例定义了一个名为read-pods的ClusterRole，授予对Pod资源的读取权限。

二、ROLE

Role是Kubernetes RBAC系统中的另一种角色类型，用于定义命名空间范围内的权限。与ClusterRole不同，Role只能在一个特定的命名空间内使用。这使得Role非常适合需要对单个命名空间进行精细化权限控制的场景。

Role可以与RoleBinding绑定，从而授予用户、组或服务账户相应的权限。Role的主要优势在于其灵活性和精细化控制。例如，如果你有一个开发团队需要对开发命名空间中的资源进行操作，但不应接触生产命名空间中的资源，那么你可以在开发命名空间中创建相应的Role并绑定到开发团队的用户。

典型的Role示例如下：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

这个示例定义了一个名为pod-reader的Role，授予对开发命名空间中Pod资源的读取权限。

三、ADMIN

Admin是一种预定义的ClusterRole，旨在为用户提供对特定命名空间内的大部分资源的管理权限。Admin角色适用于那些需要在命名空间内进行大部分操作的用户，但不包括对Kubernetes集群本身的管理权限。Admin角色通常授予项目管理员或团队领导，他们需要管理命名空间中的资源，如Pod、Service、ConfigMap等。

Admin角色的权限范围相对较广，但仍然受到一些限制。例如，它不包括对集群范围资源（如节点和持久卷）的管理权限。Admin角色的典型应用场景是团队合作项目中，团队领导需要管理项目中的资源，但不应接触其他项目或集群资源。

典型的Admin角色示例如下：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: admin
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

这个示例定义了一个名为admin的ClusterRole，授予对大多数资源的所有操作权限。

四、EDIT

Edit是一种预定义的ClusterRole，授予用户对特定命名空间内资源的编辑权限。Edit角色适用于那些需要在命名空间内创建、更新和删除资源的用户，但不包括对Kubernetes集群本身的管理权限。Edit角色通常授予开发人员，他们需要对命名空间中的资源进行修改，但不需要管理权限。

Edit角色的权限范围相对较广，但仍然受到一些限制。例如，它不包括对角色和角色绑定的管理权限。Edit角色的典型应用场景是开发团队中，开发人员需要对项目中的资源进行修改，但不应接触项目中的角色和角色绑定。

典型的Edit角色示例如下：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: edit
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

这个示例定义了一个名为edit的ClusterRole，授予对大多数资源的编辑权限。

五、VIEW

View是一种预定义的ClusterRole，授予用户对特定命名空间内资源的读取权限。View角色适用于那些只需要查看资源状态，但不需要进行任何修改操作的用户。View角色通常授予观测人员或审计人员，他们需要查看命名空间中的资源状态，但不应对资源进行任何修改。

View角色的权限范围相对较小，仅限于读取操作。例如，它包括对Pod、Service、ConfigMap等资源的读取权限，但不包括创建、更新和删除操作。View角色的典型应用场景是运维团队中，运维人员需要查看项目中的资源状态，但不应修改任何资源。

典型的View角色示例如下：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: view
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]

这个示例定义了一个名为view的ClusterRole，授予对大多数资源的读取权限。

六、AGGREGATEROLE

AggregateRole是一种特殊的角色类型，用于将多个角色的权限聚合到一个角色中。AggregateRole的主要作用是简化权限管理，通过将多个角色的权限组合在一起，从而减少重复配置。例如，如果一个用户需要多个角色的权限，你可以创建一个AggregateRole并将这些角色的权限聚合到一起，然后将AggregateRole绑定到用户。

AggregateRole的典型应用场景是复杂权限管理中，需要将多个角色的权限组合在一起的情况。例如，如果一个用户需要Admin和View角色的权限，你可以创建一个AggregateRole并将Admin和View角色的权限聚合到一起。

典型的AggregateRole示例如下：

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: aggregate-role aggregationRule: clusterRoleSelectors: - matchLabels: rbac.authorization.k8s.io/aggregate-to-admin: "true" - matchLabels: rbac.authorization.k8s.io/aggregate-to-view: "true" rules: []

这个示例定义了一个名为aggregate-role的ClusterRole，通过聚合Admin和View角色的权限，简化了权限管理。

相关问答FAQs：

1. 什么是 Kubernetes RBAC 中的 Role 和 RoleBinding？

在 Kubernetes 的 RBAC（Role-Based Access Control）中，Role 和 RoleBinding 是关键概念。什么是 Role 和 RoleBinding？

Role 定义了一组可以在单个命名空间内访问资源的规则。它可以指定哪些操作（例如创建、更新或删除）可以被执行，以及可以被操作的资源类型（如 Pod、Deployment 等）。RoleBinding 则将 Role 绑定到特定的用户、组或 ServiceAccount，从而赋予它们在命名空间内的访问权限。

例如，一个 Role 可能允许用户读取和更新命名空间内的 ConfigMap 资源，而 RoleBinding 则将该 Role 绑定到一个特定的用户，使得该用户可以执行这些操作。

2. 如何创建和管理 Kubernetes RBAC 的 Role 和 RoleBinding？

在 Kubernetes 中创建和管理 RBAC 的 Role 和 RoleBinding 是很常见的操作。如何创建和管理 Role 和 RoleBinding？

首先，您需要定义一个 Role，可以通过 YAML 文件或者直接使用 kubectl create 命令来创建。在 Role 的定义中，您需要指定该 Role 允许的操作和资源类型。例如，以下是一个简单的 Role 定义示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

然后，您可以通过 RoleBinding 将 Role 绑定到特定的用户或 ServiceAccount。例如：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

通过以上配置，用户 alice 将被授予在 default 命名空间内读取 Pods 资源的权限。

3. 如何审计和监控 Kubernetes RBAC 的使用情况？

审计和监控 Kubernetes 中 RBAC 的使用情况对于确保安全性和遵循最佳实践非常重要。如何审计和监控 RBAC 使用情况？

一种常见的方法是使用 Kubernetes 的审计功能，它可以记录所有对 RBAC 对象的更改和访问尝试。您可以配置 Kubernetes 的 API server 来启用审计，并将审计日志存储在安全的位置供后续分析和审查。

此外，还可以使用第三方工具来实时监控 RBAC 对象的使用情况。这些工具可以帮助您识别潜在的安全风险或者未经授权的访问尝试，以便及时采取必要的措施保护您的集群安全。

关于 GitLab 的更多内容，可以查看官网文档：
官网地址： https://gitlab.cn
文档地址： https://docs.gitlab.cn
论坛地址： https://forum.gitlab.cn

原创文章，作者：DevSecOps，如若转载，请注明出处：https://devops.gitlab.cn/archives/40330