权限管理 RBAC --Role和ClusterRole、RoleBinding和ClusterRoleBinding、对集群资源的权限控制、聚合ClusterRole、Role常用示例、RoleBinding常用示例、命令行的使用、K8S多租户管理
在Kubernetes（k8s）中，RBAC（Role-Based Access Control，基于角色的访问控制）是用于管理集群资源访问权限的核心机制。以下将详细说明各个组成部分及其用法：
- Role 和 ClusterRole
•Role：定义了一组针对特定命名空间内资源的操作权限集合。例如，在 development 命名空间创建一个 Role 可以允许用户或服务账户仅在这个命名空间内执行某些操作。
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: development
name: dev-readonly
rules:
- apiGroups: [""] # "" 表示核心API组
resources: ["pods", "deployments"]
verbs: ["get", "list", "watch"]
•ClusterRole：与 Role 类似，但作用范围是整个集群，包括所有命名空间以及那些不隶属于任何命名空间的集群级别资源。例如，可以创建一个 ClusterRole 来赋予用户查看集群节点信息的能力。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-viewer
rules:
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "list", "watch"]
- RoleBinding 和 ClusterRoleBinding
•RoleBinding：将 Role 与一组用户、组或者服务账户关联起来，并且限制在某个特定命名空间内生效。例如，将上面创建的 dev-readonly 角色绑定到一个用户。
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: dev-user-binding
namespace: development
subjects:
- kind: User
name: alice
roleRef:
kind: Role
name: dev-readonly
apiGroup: rbac.authorization.k8s.io
•ClusterRoleBinding：类似于 RoleBinding，但它将 ClusterRole 绑定到用户、组或服务账户上，并在整个集群范围内生效。例如，让 alice 用户拥有对集群级别的 cluster-viewer 角色的访问权。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-viewer-binding
subjects:
- kind: User
name: alice
roleRef:
kind: ClusterRole
name: cluster-viewer
apiGroup: rbac.authorization.k8s.io
3. 聚合 ClusterRole•聚合 ClusterRole 允许将多个 ClusterRole 的权限合并到一个新的 ClusterRole 中。这有助于简化管理和重用已有的权限规则。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: admin-aggregate
aggregateTo: ["admin"] # 这个字段声明这个角色被“聚合”到了“admin”角色
# 此处无需写入具体的rules，因为它会自动继承所有名为“admin”的ClusterRole的规则
4. 命令行使用
创建、查看和修改 RBAC 对象可以通过 kubectl 命令行工具完成：
#创建 Role
kubectl create -f path/to/role.yaml
# 查看 Role
kubectl get roles
# 创建 RoleBinding
kubectl create -f path/to/rolebinding.yaml
# 查看 RoleBinding
kubectl get rolebindings
# 同理，对 ClusterRole 和 ClusterRoleBinding 也可以进行类似的操作
5. K8S多租户权限管理
在一个多租户环境中，Kubernetes RBAC 可以通过不同命名空间下的 Role 和 RoleBinding 实现租户隔离。每个租户可以拥有自己的命名空间，并在其内部创建专属的角色和角色绑定，从而确保不同的团队或项目只能够访问并管理他们所拥有的资源。例如，为每一个租户创建独立的命名空间，然后在每个命名空间中分别配置合适的 Role 和 RoleBinding，确保各租户只能对其自身命名空间内的资源进行操作。同时，可以利用 ServiceAccount 结合 Namespace 和 RoleBinding 来实现自动化部署中的权限控制。每个 Pod 都可以关联到一个 ServiceAccount，这样Pod内的进程就可以获取到该 ServiceAccount 所关联的 Role 授予的权限
在Kubernetes（K8S）中，多租户权限管理可以通过RBAC（Role-Based Access Control，基于角色的访问控制）机制实现。以下是如何利用RBAC来实现在Kubernetes集群中的多租户权限隔离和管理的详细说明及示例： 1. 基本概念 •命名空间（Namespace）：Kubernetes提供了一种资源组织方式，通过命名空间可以将系统划分为多个独立的工作环境，每个租户或团队可以拥有自己的命名空间。
•ServiceAccount：在Kubernetes中，默认为每个Pod创建一个ServiceAccount对象，用于标识Pod内的进程在Kubernetes API服务器上的身份，并关联相应的权限。
•Role/ClusterRole：
•Role：定义了一组针对特定命名空间内资源的操作权限集合。
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: tenant-a
name: tenant-a-developer
rules:
- apiGroups: ["", "apps"]
resources: ["pods", "deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
•ClusterRole：类似于Role，但其作用范围是整个集群，包括所有命名空间以及非命名空间级别的资源。
•RoleBinding/ClusterRoleBinding：
•RoleBinding：将Role与ServiceAccount或者用户、组关联起来，在指定的命名空间内生效。
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: tenant-a-developer-binding
namespace: tenant-a
subjects:
- kind: ServiceAccount
name: developer-sa
namespace: tenant-a
roleRef:
kind: Role
name: tenant-a-developer
apiGroup: rbac.authorization.k8s.io
•ClusterRoleBinding：与RoleBinding类似，但绑定的是ClusterRole，并且在整个集群范围内生效。
示例场景
假设我们有一个Kubernetes集群，需要为两个不同的租户A和B分别提供权限隔离。
租户A的配置
首先，为租户A创建一个命名空间tenant-a和一个ServiceAccount developer-sa-a。
apiVersion: v1
kind: Namespace
metadata:
name: tenant-a
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: developer-sa-a
namespace: tenant-a
然后，为租户A的开发者创建一个具有操作Pods和Deployments权限的Role。
# Role for developers in tenant A
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: tenant-a-developer
namespace: tenant-a
rules:
...
接着，使用RoleBinding将这个Role绑定到租户A的ServiceAccount上。
# RoleBinding for developers in tenant A
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: tenant-a-developer-binding
namespace: tenant-a
subjects:
- kind: ServiceAccount
name: developer-sa-a
namespace: tenant-a
roleRef:
kind: Role
name: tenant-a-developer
apiGroup: rbac.authorization.k8s.io
租户B的配置
重复上述步骤，为租户B创建另一个命名空间、ServiceAccount、Role和RoleBinding，确保权限限制在租户B的命名空间内。通过这种方式，每个租户及其成员仅能对其所在命名空间内的资源进行操作，实现了多租户间的权限隔离。同时，根据实际需求，还可以创建不同级别的权限角色，如管理员角色、只读角色等，以便更细致地管理租户内部的角色分工。
