Role-Based Access Control

RBAC（Role-Based Access Control，基于角色的访问控制）是 Kubernetes 中的权限管理机制，它决定了“谁”可以在“哪个命名空间”对“哪些资源”执行“哪些操作”。

🧩 RBAC 的核心概念

  • Role
    👉 在某个命名空间内定义一组权限（例如：可以读取 Pod，但不能删除）。
  • ClusterRole
    👉 集群范围的权限，适用于所有命名空间。
  • RoleBinding
    👉 把某个 Role 绑定到具体的用户或 ServiceAccount。
  • ClusterRoleBinding
    👉 把 ClusterRole 绑定到用户或 ServiceAccount，作用于整个集群。

📌 类比理解

  • RBAC = 公司里的权限系统
    • Role = 部门权限清单：比如“财务部员工可以查看报表，但不能修改预算”。
    • ClusterRole = 公司级权限清单：比如“CEO 可以访问所有部门的资料”。
    • RoleBinding = 部门分配：把某个员工分配到财务部的权限清单。
    • ClusterRoleBinding = 公司分配：把某个员工分配到 CEO 权限清单。

📝 示例配置

创建一个 Role，允许读取 Pod：

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

绑定到用户：

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

👉 用户 alice 在 dev-team 命名空间中就只能读取 Pod。

⚠️ 注意事项

  • RBAC 默认是 最小权限原则：只授予必要的权限。
  • 命名空间隔离：Role/RoleBinding 只在命名空间内生效。
  • 结合命名空间使用：RBAC 常与 Namespace 配合，实现多团队隔离。
  • ServiceAccount：Pod 通常通过 ServiceAccount 来获取 RBAC 权限。

💡 总结

  • RBAC 是 Kubernetes 的 权限系统。
  • 它通过 Role/ClusterRole 定义权限，通过 Binding 分配给用户或 ServiceAccount。
  • 结合命名空间和资源配额，可以实现多租户安全管理。

🧩 Role

Role 是 Kubernetes RBAC 中的一种权限对象，它定义了在某个命名空间内，用户或 ServiceAccount 可以对哪些资源执行哪些操作。

🧩 Role 的作用

  • 命名空间级权限
    👉 Role 只在特定命名空间内生效。
  • 精细化控制
    👉 可以限制用户只能对某些资源（如 Pod、Service）执行特定操作（如 get、list、watch）。
  • 结合 RoleBinding 使用
    👉 Role 本身只是权限清单，必须通过 RoleBinding 绑定到用户或 ServiceAccount 才能生效。

📌 类比理解

  • Role = 部门权限清单
    • 在公司里，财务部的权限清单可能是“可以查看报表，但不能修改预算”。
    • 在 Kubernetes 中，Role 就是某个命名空间的权限清单，规定谁能对哪些资源做什么。
    • 员工（用户/ServiceAccount）只有被绑定到这个清单，才能获得相应权限。

📝 示例配置

创建一个 Role，允许读取 Pod：

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

👉 这个 Role 定义了在 dev-team 命名空间中，拥有它的用户可以读取 Pod，但不能创建或删除。

⚠️ 注意事项

  • Role 只能在 单一命名空间 内生效。
  • 如果需要跨命名空间或集群范围的权限，应使用 ClusterRole。
  • 遵循 最小权限原则：只授予必要的操作，避免过度授权。

💡 总结

  • Role 是 Kubernetes 的 命名空间级权限清单。
  • 它定义了用户或 ServiceAccount 在某个命名空间内能对哪些资源执行哪些操作。
  • 必须结合 RoleBinding 才能赋予实际权限。

🧩 RoleBinding

RoleBinding 是 Kubernetes RBAC 中的对象，用来把某个命名空间内的 Role 权限分配给具体的用户或 ServiceAccount。 它是 RBAC 权限系统中的“桥梁”，让权限清单真正生效。

🧩 RoleBinding 的作用

  • 绑定权限
    👉 RoleBinding 把 Role 中定义的权限授予某个用户或 ServiceAccount。
  • 命名空间范围
    👉 RoleBinding 只在指定的命名空间内生效。
  • 多主体支持
    👉 可以同时绑定多个用户或 ServiceAccount。

📌 类比理解

  • RoleBinding = 部门分配表
    • Role 是部门的权限清单（比如财务部能看报表）。
    • RoleBinding 就是把某个员工（用户/ServiceAccount）分配到这个清单，让他拥有相应权限。
    • 没有 RoleBinding，权限清单只是纸面文件，不会真正生效。

📝 示例配置

创建一个 RoleBinding，把 pod-reader 权限分配给用户 alice：

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

👉 用户 alice 在 dev-team 命名空间中就能读取 Pod。

⚠️ 注意事项

  • RoleBinding 只能绑定 命名空间级的 Role。
  • 如果要绑定 ClusterRole，可以用 RoleBinding（限制在命名空间）或 ClusterRoleBinding（作用于整个集群）。
  • 遵循 最小权限原则：只授予必要的权限。

💡 总结

  • RoleBinding 是 Kubernetes RBAC 的 权限分配表。
  • 它把 Role 的权限授予用户或 ServiceAccount，在命名空间内生效。
  • 与 Role/ClusterRole 配合，实现灵活的权限管理。

🧩 ClusterRole

ClusterRole 是 Kubernetes RBAC 中的一种权限对象，它定义了跨命名空间或整个集群范围的权限。与 Role 不同，ClusterRole 不局限于单一命名空间。

🧩 ClusterRole 的作用

  • 集群范围权限
    👉 可以访问所有命名空间中的资源。
  • 跨命名空间权限
    👉 适合需要管理多个命名空间的用户或系统组件。
  • 系统组件权限
    👉 Kubernetes 内置的许多控制器和插件依赖 ClusterRole 来运行。
  • 结合 Binding 使用
    👉 必须通过 ClusterRoleBinding 或 RoleBinding 才能赋予用户或 ServiceAccount实际权限。

📌 类比理解

  • ClusterRole = 公司级权限清单
    • Role 是部门级权限清单（只能在某个命名空间生效）。
    • ClusterRole 是公司级权限清单，适用于所有部门（命名空间）。
    • 比如 CEO 的权限：可以访问所有部门的资料。

📝 示例配置

创建一个 ClusterRole，允许读取所有命名空间的 Pod：

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

绑定到用户：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-pods-global
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

👉 用户 alice 就能在所有命名空间中读取 Pod。

⚠️ 注意事项

  • ClusterRole 本身只是权限清单，必须通过 Binding 才能生效。
  • 遵循 最小权限原则：避免授予过多权限，尤其是跨命名空间的操作。
  • 常用于集群管理员、系统组件或需要全局访问的工具。

💡 总结

  • ClusterRole 是 Kubernetes 的 公司级权限清单。
  • 它定义跨命名空间或集群范围的权限。
  • 必须结合 ClusterRoleBinding 或 RoleBinding 才能赋予实际权限。

🧩 ClusterRoleBinding

ClusterRoleBinding 是 Kubernetes RBAC 中的对象，用来把一个 ClusterRole 的权限分配给用户或 ServiceAccount，使其在整个集群范围内生效。 它是 RBAC 权限系统的“公司级分配表”。

🧩 ClusterRoleBinding 的作用

  • 全局权限分配
    👉 把 ClusterRole 的权限授予用户或 ServiceAccount，作用于所有命名空间。
  • 跨命名空间支持
    👉 适合需要在多个命名空间中操作资源的用户或系统组件。
  • 系统组件依赖
    👉 Kubernetes 内置的控制器和插件通常依赖 ClusterRoleBinding 来运行。

📌 类比理解

  • ClusterRoleBinding = 公司级分配表
    • ClusterRole 是公司级权限清单（比如 CEO 可以访问所有部门）。
    • ClusterRoleBinding 就是把某个员工（用户/ServiceAccount）分配到这个清单，让他在所有部门（命名空间）都能使用这些权限。
    • 没有 ClusterRoleBinding，ClusterRole 只是纸面文件，不会真正生效。

📝 示例配置

创建一个 ClusterRoleBinding，把 pod-reader 权限分配给用户 alice：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-pods-global
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

👉 用户 alice 就能在所有命名空间中读取 Pod。

⚠️ 注意事项

  • ClusterRoleBinding 只能绑定 ClusterRole，不能直接绑定 Role。
  • 一旦绑定，权限会在整个集群范围内生效，必须谨慎使用。
  • 遵循 最小权限原则：避免授予过多权限，尤其是跨命名空间的操作。

💡 总结

  • ClusterRoleBinding 是 Kubernetes RBAC 的 公司级分配表。
  • 它把 ClusterRole 的权限授予用户或 ServiceAccount，在整个集群范围内生效。
  • 常用于集群管理员、系统组件或需要全局访问的工具。
posted @ 2026-05-29 11:12  Donaver  阅读(38)  评论(0)    收藏  举报