k8s 之 Role-Based Access Control

🕗 发布于 2024-12-05 13:02 kubernetes 容器云原生

在 Kubernetes 中，RBAC（Role-Based Access Control）是一个用来控制对 Kubernetes 资源访问的授权机制。它通过定义不同角色（Role）和这些角色可以访问的权限，确保只有被授权的用户或服务能够执行特定的操作。RBAC 提供了灵活的权限管理功能，适用于不同的用户、服务账户以及应用程序。

RBAC 的基本概念

Kubernetes 的 RBAC 主要包括以下几个基本概念：

Role 和 ClusterRole
RoleBinding 和 ClusterRoleBinding
ServiceAccount
PolicyRules

1. Role 和 ClusterRole

Role：定义了在某个特定命名空间内的权限。它描述了某个用户或服务账户可以对哪些资源进行哪些操作。例如，Role 可以授予用户在 default 命名空间中列出 Pods 和创建 Deployments 的权限。
- 示例 Role：
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default  # 指定 Role 的命名空间
  name: pod-reader    # Role 的名称
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
```
  上述示例中，pod-reader 角色授予用户对 default 命名空间下的 Pods 资源的 get 和 list 权限。
ClusterRole：定义了集群范围内的权限，不依赖于命名空间。ClusterRole 可以用于跨命名空间访问资源，或者在集群级别执行操作（例如管理节点、查看集群的状态等）。
- 示例 ClusterRole：
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # ClusterRole 没有命名空间字段
  name: cluster-admin
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "create", "delete"]
```
  上述示例中的 cluster-admin ClusterRole 赋予用户对集群内所有 Pods 资源的管理权限。

2. RoleBinding 和 ClusterRoleBinding

RoleBinding：将一个 Role（命名空间级别）或 ClusterRole（集群级别）绑定到一个或多个用户、组或者服务账户上。RoleBinding 只在特定的命名空间内有效。

示例 RoleBinding：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: "jane"  # 绑定的主体是用户 "jane"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader  # 绑定到名为 pod-reader 的 Role
  apiGroup: rbac.authorization.k8s.io

在这个例子中，用户 jane 被授权使用 default 命名空间中的 pod-reader Role，从而可以列出和查看该命名空间中的 Pods。

ClusterRoleBinding：将一个 ClusterRole 绑定到一个或多个用户、组或者服务账户上，作用范围是整个集群。

示例 ClusterRoleBinding：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-binding
subjects:
- kind: User
  name: "jane"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin  # 绑定到集群管理员权限
  apiGroup: rbac.authorization.k8s.io

这意味着 jane 用户将会获得集群管理员的权限，能够在整个集群中执行任何操作。

3. 使用 kubectl impersonate 命令模拟 `jane` 用户

Kubernetes 提供了 kubectl auth can-i 命令来模拟某个用户的权限。你可以使用 kubectl impersonate 来临时以 jane 用户的身份运行命令，检查她是否具有某些操作的权限。

步骤：

模拟 jane 用户执行 kubectl 命令

使用 kubectl auth can-i 命令来检查 jane 是否有执行某个操作的权限。例如，检查她是否可以在 default 命名空间下列出 Pods：
```
kubectl auth can-i list pods --namespace=default --as=jane
```
解释：
- --as=jane：指定以 jane 用户身份进行操作。
- list pods --namespace=default：测试 jane 是否可以列出 default 命名空间中的 Pods。
如果命令返回 yes，说明 jane 拥有该操作的权限；如果返回 no，说明 jane 不具有该权限。

示例输出：

$ kubectl auth can-i list pods --namespace=default --as=jane
yes

如果返回 yes，那么 jane 就能够列出 Pods，说明她有 pod-reader 角色授予的权限。

4. 检查 RoleBinding 是否生效

你还可以检查 RoleBinding 是否正确配置，确认是否已将正确的角色和主体绑定在一起。

步骤：

查看 RoleBinding

使用以下命令检查 RoleBinding 是否正确绑定了角色：

kubectl get rolebinding read-pods --namespace=default -o yaml

输出应类似于：

kind: RoleBinding
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"RoleBinding","metadata":{"annotations":{},"name":"read-pods","namespace":"default"},"roleRef":{"apiGroup":"rbac.authorization.k8s.io","kind":"Role","name":"pod-reader"},"subjects":[{"apiGroup":"rbac.authorization.k8s.io","kind":"User","name":"jane"}]}
  creationTimestamp: "2024-12-04T06:31:39Z"
  name: read-pods
  namespace: default
  resourceVersion: "188345"
  uid: 283615ff-8e9b-4e25-a6e8-7e5bcbbd582f
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: jane

检查 Role 配置

确保 pod-reader 角色已正确配置，并且具有正确的权限。使用以下命令检查 pod-reader 角色：

kubectl get role pod-reader --namespace=default -o yaml

输出应类似于：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"Role","metadata":{"annotations":{},"name":"pod-reader","namespace":"default"},"rules":[{"apiGroups":[""],"resources":["pods"],"verbs":["get","list"]}]}
  creationTimestamp: "2024-12-04T06:31:33Z"
  name: pod-reader
  namespace: default
  resourceVersion: "188338"
  uid: 78e25dfb-4bd2-41da-af5f-4b812caa7cbf
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list

确保角色 pod-reader 确实有对 pods 资源的 get 和 list 权限。

5. ServiceAccount

ServiceAccount：通常用于为 Kubernetes 中运行的 Pod 提供身份验证。通过给 Pod 分配一个 ServiceAccount，可以控制 Pod 对 API 服务器的访问权限。例如，Pod 可以被配置为使用一个特定的 ServiceAccount，该账户可能拥有对某些资源的特定权限。
- 示例 ServiceAccount：
```
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-service-account
  namespace: default
```
  你可以为 Pod 分配这个 ServiceAccount，从而使 Pod 拥有该账户的权限。

5. 测试 Pod 的 ServiceAccount 权限

在 Kubernetes 中，ServiceAccount 是一种用于为 Pod 或应用程序提供身份认证的机制。当一个 Pod 被分配一个 ServiceAccount 时，Kubernetes 会将与该账户关联的权限授予该 Pod，从而允许它与 Kubernetes API 进行交互。

要测试一个 Pod 的 ServiceAccount 权限，通常是通过以下几个步骤来检查它是否有正确的权限来执行某些操作（如查看、创建或删除资源等）。我们可以通过以下步骤测试 ServiceAccount 的权限：

确保 Pod 使用了正确的 ServiceAccount

首先，确保 Pod 使用了您所创建的 ServiceAccount。可以在 Pod 的 YAML 文件中指定 serviceAccountName 来确保 Pod 使用该账户。

例如，假设您有一个 ServiceAccount 名为 my-app-service-account，然后在 Pod 配置中引用它：
```
apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  serviceAccountName: my-app-service-account  # 绑定 ServiceAccount
  containers:
  - name: my-app-container
    image: nginx
```
为 ServiceAccount 配置适当的 RBAC 权限

为了让 my-app-service-account 拥有访问权限，您需要使用 RBAC 配置为其授予特定的角色（Role 或 ClusterRole）和操作权限（如 get、list、create 等）。以下是一个示例，假设您希望 my-app-service-account 有权限列出 Pods 资源：
- Role（命名空间级别权限）：
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
```
- RoleBinding（将 Role 绑定到 ServiceAccount）：
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: ServiceAccount
  name: my-app-service-account
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```
在这个示例中，pod-reader 角色允许 my-app-service-account 列出和获取 default 命名空间中的 Pods 资源。
测试 ServiceAccount 权限

现在，您可以通过以下方式来测试 my-app-service-account 是否具有足够的权限：
- 使用 kubectl auth can-i 命令：
  
  使用 kubectl auth can-i 命令模拟 ServiceAccount 执行操作。这个命令会帮助您测试 ServiceAccount 是否有权限执行某个操作。
```
kubectl auth can-i list pods --namespace=default --as=system:serviceaccount:default:my-app-service-account
```
  这里：
  - list pods --namespace=default：检查 my-app-service-account 是否有权限列出 default 命名空间下的 Pods。
  - --as=system:serviceaccount:default:my-app-service-account：模拟以 my-app-service-account 身份执行操作。
  如果返回 yes，则说明 ServiceAccount 有权限列出 Pods。如果返回 no，则说明没有该权限。
  
  示例输出：
```
$ kubectl auth can-i list pods --namespace=default --as=system:serviceaccount:default:my-app-service-account
yes
```
- 直接在 Pod 中测试权限
  
  你可以手动为该 Pod 指定一个 ServiceAccount。创建一个 YAML 文件，修改 ServiceAccount 后再应用
```
apiVersion: v1
kind: Pod
metadata:
  name: debug
spec:
  serviceAccountName: my-app-service-account
  containers:
  - name: debug
    image: bitnami/kubectl:latest
    command: ["/bin/sh"]
    stdin: true
    tty: true
```
```
kubectl exec -it debug -n default -- /bin/sh
```

6. PolicyRules

PolicyRules：在 Role 和 ClusterRole 中定义的一组规则，用来描述哪些资源、哪些操作是允许的。PolicyRules 使用 apiGroups、resources 和 verbs 来定义具体的权限。
- apiGroups：指定资源属于哪个 API 组。例如，"" 代表 Core API 组，apps 代表部署等资源。
- resources：指定资源类型，如 pods、deployments、services 等。
- verbs：指定允许的操作，如 get（获取）、list（列出）、create（创建）、delete（删除）等。
- 示例 PolicyRules：
```
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create", "delete"]
```
  在这个示例中，定义了两条规则：
  - 对 pods 资源，允许 get 和 list 操作。
  - 对 deployments 资源，允许 create 和 delete 操作。

RBAC 使用场景

控制集群资源访问：通过 Role 和 ClusterRole 控制用户或服务账户对 Kubernetes 资源的访问权限。例如，限制某个用户只能查看 Pods，而不能修改或删除。
服务账户：为不同的应用程序、服务或者 Pod 创建专用的服务账户，并绑定适当的角色，确保它们只有执行任务所需的最小权限。
权限最小化：通过精细的权限控制，遵循 最小权限原则，使得用户、服务账户或者应用程序只能访问它们执行任务所需的资源。

常见命令

查看角色和角色绑定：

kubectl get roles
kubectl get rolebindings
kubectl get clusterroles
kubectl get clusterrolebindings

创建和应用 RBAC 资源：

kubectl apply -f role.yaml
kubectl apply -f rolebinding.yaml

总结

Kubernetes 的 RBAC 通过 Role 和 ClusterRole 来定义不同的权限，并通过 RoleBinding 和 ClusterRoleBinding 来将这些权限绑定到特定的用户、组或服务账户。RBAC 提供了一种细粒度的访问控制机制，帮助管理员确保集群资源的安全性，并且根据不同的需求授予相应的权限。

原文地址：https://blog.csdn.net/qq_37362891/article/details/144247846

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！

上一篇：Scala的条件匹配
下一篇：四、自然语言处理_01时序信号与文本向量化

.NET(C#) 如何配置用户首选项及保存用户设置
.NET(C#) 如何配置用户首选项及保存用户设置
阅读更多2024-12-14
【最新】北大数字普惠金融指数数据集-省市县（2011-2023年）
郭峰,王靖一,王芳,孔涛,张勋,程志云.测度中国数字普惠金融发展:指数编制与空间特征[J].经济学(季刊),2020,19(04):1401-1418.时间跨度：省级和城市级指数时间跨度为2011-2
阅读更多2024-12-14
GESP202412 四级【Recamán】题解（AC）
a11ak−1−kkakak−1−kak−1k小杨想知道 Recamán 数列的前n项从小到大排序后的结果。手动计算非常困难，小杨希望你能帮他解决这个问题。
阅读更多2024-12-14
IDEA遇到EasyConnect中的网络资源无法访问的问题
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。原文链接：https://blog.csdn.net/wanshanyu_/article/de
阅读更多2024-12-14
双目摄像头标定方法
此时已经完成标定，左下角为反投影误差，右边为外参可视化。将双目左右目拍的图像上传（左右目最好不少于20张）此时回到主页面，即可看到成功导出。把这些误差大的删除即可。
阅读更多2024-12-14
Servlet、omcat服务器架构与工作原理
Servlet是运行在服务器端的Java程序，它的主要职责之一是接收并处理来自客户端（如浏览器）的HTTP请求。当客户端发送一个请求到服务器时，Servlet可以解析请求中的信息，例如请求的URL路径
阅读更多2024-12-14
Vue生命周期钩子函数：深入解析与实践
作为高级Vue前端开发人员，对Vue组件的生命周期钩子函数有着深刻的理解是至关重要的。生命周期钩子函数是指在Vue组件的创建、更新、销毁等过程中，Vue自动调用的一系列方法。通过这些钩子函数，我们可以
阅读更多2024-12-14
安卓开发--使用android studio发布APP
app发布
阅读更多2024-12-14
数据结构与算法学习笔记----拓扑排序
@ author: 明月清了个风。
阅读更多2024-12-14
python 将数据保存到现有的Excel文件的新工作表
out_file = ‘query.xlsx’df1 = pd.DataFrame(out_data)若直接写入：df1.to_excel(out_file, index=False, sheet_n
阅读更多2024-12-14