在 Kubernetes (K8s) 中，ClusterRole 是一种用于定义集群范围的权限的资源对象。它定义了特定的权限集合，能够应用到整个 Kubernetes 集群中的资源，而不仅仅是特定命名空间内的资源。ClusterRole 是 Kubernetes RBAC（角色访问控制）机制中的重要组成部分，用于确保不同用户和服务能够获得适当的访问权限。
- ClusterRole 的作用
ClusterRole 用于定义可以访问的资源类型、具体的操作（如：get、list、create、delete 等），并且作用范围可以覆盖到整个集群。例如，可以创建一个 ClusterRole，授予用户在集群范围内查看所有命名空间的 Pod 列表的权限。
- 使用场景
一些典型的 ClusterRole 使用场景包括：
• 集群管理员权限：为用户或服务帐户提供集群级别的完全访问权限。
• 集群监控：提供跨命名空间的资源查看权限，通常用于监控工具。
• 集群级操作：对集群范围资源的管理权限（如节点 Node、存储 PersistentVolume 等），这些资源是不依赖于具体命名空间的。
• 特定应用程序的角色权限：某些应用需要访问集群级别的资源，比如调度器、控制器等。
- 如何使用 ClusterRole
使用 ClusterRole 主要分为两个步骤：
• 创建 ClusterRole：定义一个 ClusterRole，指定具体的资源和操作权限。
• 绑定 ClusterRole 到用户、组或服务帐户：通过 ClusterRoleBinding 资源将 ClusterRole 绑定到具体的用户、组或服务帐户上，从而授予他们对应的权限。
- 使用示例
1）定义 ClusterRole
以下是一个简单的 ClusterRole 示例，它允许在所有命名空间中查看 Pods：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: view-pods
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
在上面的例子中：
• apiGroups 定义了资源所在的 API 组，"" 表示核心 API 组。
• resources 定义了资源类型（这里是 pods）。
• verbs 定义了允许的操作，包括 get、list 和 watch。
2）绑定 ClusterRole
接下来，将 ClusterRole 绑定到具体的用户或服务帐户。通过以下 ClusterRoleBinding 将 view-pods 角色授予给某个用户：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: view-pods-binding
subjects:
- kind: User
name: "example-user" # 替换为实际的用户名
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: view-pods
apiGroup: rbac.authorization.k8s.io
在这个绑定中：
• subjects 指定了授予权限的用户或服务帐户。
• roleRef 指定了要绑定的 ClusterRole。
总结
通过 ClusterRole 和 ClusterRoleBinding，可以灵活地为用户、组或服务帐户分配跨命名空间和集群级别的权限，确保集群的安全和权限管理的灵活性。这种机制适用于对资源访问要求较高的场景，比如集群管理、监控和集群范围的操作等。
这个用户是系统用户吗？ 比如说linux 系统中有个用户叫 Tom, 我要给他get, list, watch 的权限，创建一个 clusterRole 名字为 normal-user, 把这个用户绑定到这个 clusterRole：normal-user 中，要怎么实现？
在 Kubernetes 中，用户与操作系统（如 Linux）的系统用户并不直接关联。Kubernetes 本身并不会管理用户的身份验证，而是通过外部身份验证机制（如客户端证书、OIDC、服务帐户等）来识别用户。因此，Kubernetes 并不知道 Linux 系统中的 Tom 用户，除非通过特定的身份验证机制使 Tom 的身份被 Kubernetes 识别。
下面是实现这种场景的步骤：
- 创建 ClusterRole
首先，定义一个名为 normal-user 的 ClusterRole，并给它 get、list 和 watch 的权限：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: normal-user
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
在这个 ClusterRole 中，我们授予了集群中所有命名空间内查看 Pods 的权限。
- 配置用户身份认证
假设要将 Linux 系统用户 Tom 作为 Kubernetes 中的一个用户来授权，最常见的方法是通过客户端证书的方式进行身份认证。
生成客户端证书
1. 生成用户 Tom 的私钥和证书签名请求（CSR）：
openssl genpkey -algorithm RSA -out tom.key
openssl req -new -key tom.key -out tom.csr -subj "/CN=Tom/O=dev-group"
这里的 /CN=Tom 指定了用户名为 Tom，/O=dev-group 指定了用户组为 dev-group。这些信息会被 Kubernetes 用于身份认证。
2. 使用 Kubernetes 集群的证书颁发机构 (CA) 签署证书请求（CSR）：
openssl x509 -req -in tom.csr -CA /path/to/ca.crt -CAkey /path/to/ca.key -CAcreateserial -out tom.crt -days 365
这样会生成一个有效期为 365 天的 tom.crt 证书。
3. 将生成的证书（tom.crt）和私钥（tom.key）分发给用户 Tom。他可以使用这些证书通过 kubectl 访问集群。
配置 kubectl 使用客户端证书
用户 Tom 可以在他的本地配置文件中添加一个 kubectl 上下文：
kubectl config set-credentials tom –client-certificate=/path/to/tom.crt –client-key=/path/to/tom.key
kubectl config set-context tom-context –cluster=my-cluster –user=tom
这里的 my-cluster 需要替换为实际集群的名称。
- 绑定 ClusterRole 到用户
最后，创建一个 ClusterRoleBinding，将 normal-user 角色绑定到 Tom 用户：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: tom-binding
subjects:
- kind: User
name: "Tom" # 这个名字必须和证书中的 CN 一致
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: normal-user
apiGroup: rbac.authorization.k8s.io
在这个 ClusterRoleBinding 中，subjects 的 name 字段必须与证书中指定的 CN 值（即 Tom）一致，roleRef 中的 name 必须与之前创建的 ClusterRole 名称 normal-user 一致。
总结
1. 创建 ClusterRole 来定义权限。
2. 生成客户端证书，并确保 CN 值对应用户的身份。
3. 使用 ClusterRoleBinding 将用户 Tom 绑定到 ClusterRole 上，从而授予他在集群中的访问权限。
通过这些步骤，Linux 用户 Tom 就能通过客户端证书认证的方式，在 Kubernetes 集群中使用 get、list 和 watch 操作访问 Pods。
我还是不理解 subjects 的定义中指定的用户指的是什么？ 如果不是系统用户，那么这个用户指的是 k8s中定义的用户吗？这个用户怎么定义呢？subjects:
-
kind: User
name: "example-user" # 替换为实际的用户名在 Kubernetes 中，subjects 中定义的用户指的是Kubernetes 认证系统能够识别的用户。但 Kubernetes 本身并不管理或存储用户。相反，它通过外部的身份认证机制来识别用户，比如客户端证书、令牌、OIDC（OpenID Connect）等。这意味着 Kubernetes 中的用户并不是“系统用户”或 K8s 中定义的用户，而是通过认证机制定义和识别的用户身份。
下面详细解释 Kubernetes 中的用户概念和定义方式。
- Kubernetes 中的用户定义
Kubernetes 通过身份认证机制来识别用户的身份，并没有在集群内维护用户的记录。常见的认证方式有：
• 客户端证书：每个客户端证书包含一个 CN（Common Name）字段，表示用户的名字。当用户使用证书访问集群时，Kubernetes 会将证书中的 CN 字段值作为用户的身份。上文中我们提到的 Tom 就是一个例子，通过生成的客户端证书来识别 Tom。
• 令牌认证：例如使用 JWT（JSON Web Token）或 Bearer Token 等，很多身份提供者（如 Google、GitHub、企业自有认证系统）可以生成令牌。通过 API 服务器配置，Kubernetes 可以验证这些令牌，认证通过后，令牌中的用户名被视为 Kubernetes 中的用户。
• OpenID Connect (OIDC)：如果集群配置了 OIDC，用户可以通过 OIDC 提供的身份信息进行认证。OIDC 是一种基于 OAuth2 的认证标准，广泛用于集成外部身份提供者（如 Google、Azure AD 等）。
• 服务账户：这是 Kubernetes 原生的认证方式，通常用于 Pod 访问集群资源。ServiceAccount 是一种 Kubernetes 中内置的用户类型，但不适用于人工用户登录。
注意：Kubernetes 没有在集群内定义“用户”的功能，所有用户身份信息都由外部认证系统提供。因此，Kubernetes 无法直接使用 Linux 系统用户（如 /etc/passwd 中的用户）进行认证。
- ClusterRoleBinding 中的 subjects
在 ClusterRoleBinding 中，subjects 定义了将角色绑定到哪些实体（用户、组或服务账户），kind 字段可以为以下几种类型：
• User：指定为用户。这种用户需要通过认证机制识别，不能在 Kubernetes 集群内部直接定义。name 应该是认证系统（如客户端证书的 CN 字段、令牌中的用户名）所识别的名称。
• Group：指定为用户组，用于将角色绑定到用户组。用户组也需要通过认证机制识别。name 对应组的名称。
• ServiceAccount：指定为 Kubernetes 内置的服务账户，通常用于应用程序的权限控制，而不是人工用户。
例如：
subjects:
- kind: User
name: "Tom" # 通过客户端证书中的 CN 来识别这个用户
apiGroup: rbac.authorization.k8s.io
在这里，name: "Tom" 是 Kubernetes 认证系统识别的用户名，它可能来自客户端证书的 CN 字段、令牌的用户名字段等。
- 如何定义 Kubernetes 用户
如果你想让用户 Tom 能够使用 kubectl 访问集群资源，并应用 ClusterRole 权限，常用方法是生成客户端证书。下面是完整的步骤：
使用客户端证书创建 Kubernetes 用户
1. 生成私钥和 CSR（证书请求）：
openssl genpkey -algorithm RSA -out tom.key
openssl req -new -key tom.key -out tom.csr -subj "/CN=Tom/O=dev-group"
这里 /CN=Tom 定义了 Kubernetes 识别的用户名，/O=dev-group 定义了用户组 dev-group。这个 CN=Tom 就是 ClusterRoleBinding 中 name 的值。
2. 使用 Kubernetes CA 签署 CSR：
openssl x509 -req -in tom.csr -CA /path/to/ca.crt -CAkey /path/to/ca.key -CAcreateserial -out tom.crt -days 365
生成的 tom.crt 是 Tom 用户的客户端证书。
3. 为用户配置 kubectl 访问集群：
用户可以在 kubectl 的配置文件中添加新的上下文，以便使用客户端证书认证集群：
kubectl config set-credentials tom --client-certificate=/path/to/tom.crt --client-key=/path/to/tom.key
kubectl config set-context tom-context --cluster=my-cluster --user=tom
用户现在可以使用 kubectl 访问集群，并使用 kubectl config use-context tom-context 切换到该上下文。
4. 创建 ClusterRoleBinding：
最后，将 ClusterRole 绑定到 Tom：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: tom-binding
subjects:
- kind: User
name: "Tom" # 必须与证书中的 CN 匹配
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: normal-user
apiGroup: rbac.authorization.k8s.io
通过这些步骤，用户 Tom 将能够使用客户端证书访问集群，Kubernetes 通过 CN=Tom 来识别 Tom，并根据 ClusterRoleBinding 授予的权限来控制他的访问。
clusterrole 有哪些权限可以分配？
在 Kubernetes 中，ClusterRole 可以分配的权限主要取决于所涉及的API 资源类型及其操作（verbs）。以下是 ClusterRole 中常见的资源类型和操作。
- 资源类型（Resources）
资源类型分为两类：核心资源（Core Resources）和扩展资源（Extended Resources）。核心资源是 Kubernetes 内置的 API 资源，如 Pod、Service、ConfigMap 等。扩展资源是通过其他 API 组提供的资源，例如 apps、batch 等组中的资源。
• Core API Resources：
• pods：Pod 资源
• services：服务资源
• configmaps：配置映射
• secrets：密钥
• namespaces：命名空间
• nodes：节点
• persistentvolumes：持久卷
• persistentvolumeclaims：持久卷声明
• events：事件
• endpoints：端点
• resourcequotas：资源配额
• limitranges：资源限制
• Extended API Resources：
• deployments、replicasets、daemonsets 等（在 apps API 组中）
• cronjobs、jobs 等（在 batch API 组中）
• networkpolicies（在 networking.k8s.io API 组中）
• roles、clusterroles、rolebindings、clusterrolebindings（在 rbac.authorization.k8s.io API 组中）
• customresourcedefinitions（在 apiextensions.k8s.io API 组中，用于定义自定义资源）
• storageclasses（在 storage.k8s.io API 组中，用于管理存储类）
- 操作类型（Verbs）
操作类型定义了在资源上允许执行的操作，常见的操作有以下几种：
• 读操作：
• get：获取单个资源对象
• list：列出某种类型的所有资源对象
• watch：监听资源对象的变化
• 写操作：
• create：创建资源对象
• update：更新资源对象
• patch：部分更新资源对象
• delete：删除单个资源对象
• deletecollection：删除所有资源对象
• 其他操作：
• proxy：通过代理访问资源
• impersonate：模拟另一个用户、组或服务账户的身份
• bind：绑定资源（例如将 Pod 绑定到 Node 上）
- ClusterRole 示例
下面是一些常见权限的示例，展示如何在 ClusterRole 中定义不同的资源和操作：
- 允许查看所有命名空间的 Pods
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: view-pods
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
- 允许在集群范围内创建和删除 ConfigMaps 和 Secrets
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: manage-configs-secrets
rules:
- apiGroups: [""]
resources: ["configmaps", "secrets"]
verbs: ["get", "list", "create", "update", "delete"]
- 允许管理 Deployments 和 StatefulSets
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: manage-deployments-statefulsets
rules:
- apiGroups: ["apps"]
resources: ["deployments", "statefulsets"]
verbs: ["get", "list", "create", "update", "delete"]
- 允许管理命名空间和节点资源
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: manage-namespaces-nodes
rules:
- apiGroups: [""]
resources: ["namespaces", "nodes"]
verbs: ["get", "list", "create", "update", "delete"]
- 特殊权限：* 通配符
在某些情况下，可以使用 * 通配符来表示所有资源或所有操作，例如：
• resources: [""]：表示所有资源类型。
• verbs: [""]：表示所有操作。
例如，下面的 ClusterRole 定义了一个超级用户角色，可以访问所有资源的所有操作：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: super-user
rules:
- apiGroups: [""]
resources: [""]
verbs: ["*"]
这种配置适用于集群管理员，谨慎使用。
总结
Kubernetes 中 ClusterRole 的权限通过指定资源类型和操作类型来控制。可以根据需求灵活地组合资源和操作，以满足不同的角色需求。
