Kubernetes RBAC (基于角色的访问控制) 配置与实践

好嘞，各位看官，今天咱们就来聊聊 Kubernetes RBAC 这位“门卫大爷”。别看名字高大上，其实它就是帮咱们管好 Kubernetes 集群里谁能干啥，谁不能干啥的。想象一下，没有 RBAC，那咱们的集群就成了不设防的后花园，谁都能进来溜达一圈，删个 Pod，改个配置，那还得了？😱

所以说，RBAC 是 Kubernetes 安全体系里至关重要的一环，掌握它，你才能在 Kubernetes 的世界里安心驰骋，不用担心被“熊孩子”乱搞一通。

开场白：RBAC，集群的守护神

大家好！我是你们的老朋友，今天要带大家深入 Kubernetes 的“安全堡垒”—— RBAC (Role-Based Access Control)，也就是基于角色的访问控制。

先别被这长长的名字吓到，其实 RBAC 就像咱们现实世界里的“门卫大爷”，负责把守着 Kubernetes 集群的大门，确保只有拥有相应权限的人才能进入并进行操作。

想象一下，如果你的 Kubernetes 集群没有 RBAC，那会是什么样的场景？ 恐怕会变成一个“无人之境”，任何人都可以在里面随意创建、修改、删除资源，简直就是一场噩梦！🤯

所以，RBAC 的作用至关重要，它能够帮助我们：

• 细粒度权限控制： 精确控制每个用户或服务账户对集群资源的访问权限。
• 提高安全性： 避免未经授权的访问，保护集群资源的安全。
• 简化管理： 通过角色和角色绑定，简化权限的管理和分配。

今天，我就要带大家一起，用最轻松幽默的方式，彻底搞懂 RBAC，让你的 Kubernetes 集群更加安全可靠！

第一幕：RBAC 的三大主角

要理解 RBAC，首先要认识它的三个核心概念，就像电影里的三大主角一样：

1. Subject (主体)： 谁来访问？
2. Role (角色)： 能干什么？
3. RoleBinding (角色绑定)： 谁和角色绑定？

接下来，咱们一个一个来剖析：

1. Subject (主体)：谁来访问？

Subject 指的是要访问 Kubernetes 集群资源的用户或服务账户。 它可以是：

• User (用户)： 真实的人，例如你的同事，或者你自己。
• Group (组)： 一组用户的集合，方便批量管理权限。
• ServiceAccount (服务账户)： Kubernetes 集群内部的服务使用的身份。

你可以把 Subject 想象成一个拿着“通行证”的人，只有拥有有效的通行证，才能进入集群进行操作。

2. Role (角色)：能干什么？

Role 定义了一组权限，例如可以创建 Pod，可以查看 Service，可以删除 Deployment 等等。

Role 就像是一张“权限清单”，上面详细列出了该角色可以执行的操作。

Role 有两种类型：

• Role： 作用于单个 Namespace，只能访问该 Namespace 下的资源。
• ClusterRole： 作用于整个集群，可以访问所有 Namespace 下的资源。

用表格来总结一下：

Role 类型	作用范围	适用场景
Role	单个 Namespace	限制用户或服务账户只能访问特定 Namespace 下的资源，例如开发环境或测试环境。
ClusterRole	整个集群	允许用户或服务账户访问所有 Namespace 下的资源，例如集群管理员。

3. RoleBinding (角色绑定)：谁和角色绑定？

RoleBinding 的作用是将 Role 中定义的权限赋予给 Subject。 简单来说，就是把“权限清单”发给“通行证持有人”，让他们拥有相应的权限。

RoleBinding 也有两种类型：

• RoleBinding： 作用于单个 Namespace，将 Role 绑定到该 Namespace 下的 Subject。
• ClusterRoleBinding： 作用于整个集群，将 ClusterRole 绑定到所有 Namespace 下的 Subject。

同样用表格来总结一下：

RoleBinding 类型	作用范围	适用场景
RoleBinding	单个 Namespace	将 Role 绑定到特定 Namespace 下的 Subject，例如授予某个用户在开发环境 Namespace 下创建 Pod 的权限。
ClusterRoleBinding	整个集群	将 ClusterRole 绑定到所有 Namespace 下的 Subject，例如授予某个用户集群管理员权限，使其能够访问和管理整个集群。

第二幕：RBAC 的实战演练

光说不练假把式，接下来咱们就来动手实践一下，看看如何使用 RBAC 来保护我们的 Kubernetes 集群。

场景设定：

假设我们有一个开发团队，需要让他们能够在 dev Namespace 下创建和管理 Pod，但不能访问其他 Namespace 下的资源。

步骤一：创建 Role

首先，我们需要创建一个 Role，定义开发团队可以执行的操作。

创建一个名为 pod-creator 的 Role，允许在 dev Namespace 下创建 Pod：

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

这个 Role 定义了以下权限：

• apiGroups: [""]：表示核心 API 组。
• resources: ["pods"]：表示可以操作的资源类型为 Pod。
• verbs: ["create", "get", "list", "watch", "update", "patch", "delete"]：表示可以执行的操作，包括创建、查看、列出、监听、更新、修补和删除 Pod。

保存为 pod-creator.yaml 文件，然后执行以下命令创建 Role：

kubectl apply -f pod-creator.yaml

步骤二：创建 ServiceAccount

接下来，我们需要创建一个 ServiceAccount，作为开发团队的身份。

创建一个名为 dev-team 的 ServiceAccount：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dev-team
  namespace: dev

保存为 dev-team.yaml 文件，然后执行以下命令创建 ServiceAccount：

kubectl apply -f dev-team.yaml

步骤三：创建 RoleBinding

最后，我们需要创建一个 RoleBinding，将 pod-creator Role 绑定到 dev-team ServiceAccount。

创建一个名为 dev-team-binding 的 RoleBinding：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-team-binding
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-creator
subjects:
- kind: ServiceAccount
  name: dev-team
  namespace: dev

这个 RoleBinding 定义了以下信息：

• roleRef：指定要绑定的 Role，这里是 pod-creator。
• subjects：指定要绑定到的 Subject，这里是 dev-team ServiceAccount。

保存为 dev-team-binding.yaml 文件，然后执行以下命令创建 RoleBinding：

kubectl apply -f dev-team-binding.yaml

大功告成！🎉

现在，开发团队的 ServiceAccount dev-team 就拥有了在 dev Namespace 下创建和管理 Pod 的权限。

第三幕：RBAC 的高级技巧

掌握了 RBAC 的基本概念和用法，接下来咱们再来学习一些高级技巧，让你的 RBAC 配置更加灵活强大。

1. 使用 ClusterRole 和 ClusterRoleBinding

如果我们需要授予用户或服务账户访问整个集群的权限，可以使用 ClusterRole 和 ClusterRoleBinding。

例如，创建一个名为 cluster-admin 的 ClusterRole，拥有管理整个集群的权限：

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

这个 ClusterRole 定义了以下权限：

• apiGroups: ["*"]：表示所有 API 组。
• resources: ["*"]：表示所有资源类型。
• verbs: ["*"]：表示所有操作。

然后，创建一个名为 admin-binding 的 ClusterRoleBinding，将 cluster-admin ClusterRole 绑定到用户 admin：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: User
  name: admin
  apiGroup: rbac.authorization.k8s.io

现在，用户 admin 就拥有了管理整个集群的权限。

注意： 授予用户或服务账户 ClusterRoleBinding 时要谨慎，因为这会赋予他们极高的权限，可能会带来安全风险。

2. 使用聚合 ClusterRole

Kubernetes 1.11 引入了聚合 ClusterRole 的功能，可以将多个 ClusterRole 合并成一个，方便管理。

例如，创建一个名为 monitoring-reader 的 ClusterRole，用于读取监控数据：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-reader
  labels:
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: [""]
  resources: ["pods", "nodes", "services"]
  verbs: ["get", "list", "watch"]

在这个 ClusterRole 中，我们添加了一个 rbac.authorization.k8s.io/aggregate-to-view: "true" 的标签，表示这个 ClusterRole 会被聚合到 view ClusterRole 中。

Kubernetes 默认提供了一些预定义的聚合 ClusterRole，例如 view、edit 和 admin，分别对应只读、编辑和管理权限。

通过聚合 ClusterRole，我们可以将多个细粒度的权限组合成一个更高级别的权限，方便管理和维护。

3. 使用 RBAC 审计

Kubernetes 提供了 RBAC 审计的功能，可以记录所有 RBAC 相关的操作，例如创建、修改、删除 Role 和 RoleBinding 等。

通过 RBAC 审计，我们可以追踪权限的变更，及时发现和解决安全问题。

要启用 RBAC 审计，需要在 Kubernetes API Server 的配置文件中添加以下参数：

--audit-policy-file=/etc/kubernetes/audit-policy.yaml
--audit-log-path=/var/log/kubernetes/audit.log
--audit-log-maxage=30
--audit-log-maxbackup=10
--audit-log-maxsize=100

其中：

• --audit-policy-file：指定审计策略文件的路径。
• --audit-log-path：指定审计日志文件的路径。
• --audit-log-maxage：指定审计日志文件的最大保留天数。
• --audit-log-maxbackup：指定审计日志文件的最大备份数量。
• --audit-log-maxsize：指定审计日志文件的最大大小（MB）。

审计策略文件定义了要审计的事件类型和级别。

总结：RBAC，安全之基石

今天，我们一起学习了 Kubernetes RBAC 的基本概念、实战演练和高级技巧。 希望通过今天的学习，大家能够更加深入地理解 RBAC，并能够灵活运用 RBAC 来保护自己的 Kubernetes 集群。

记住，RBAC 是 Kubernetes 安全体系中至关重要的一环，只有掌握了 RBAC，才能在 Kubernetes 的世界里安心驰骋，不用担心被“熊孩子”乱搞一通。 🛡️

最后，送给大家一句“安全箴言”：

“RBAC 在手，天下我有！”😎

希望这篇文章对你有所帮助！ 如果你有任何问题或建议，欢迎在评论区留言交流。

补充：一些常见问题

1. 如何查看当前用户的权限？

   可以使用 kubectl auth can-i 命令来查看当前用户的权限。

   例如，查看当前用户是否有创建 Pod 的权限：

   kubectl auth can-i create pods

2. 如何模拟其他用户的权限？

   可以使用 kubectl impersonate 命令来模拟其他用户的权限。

   例如，模拟用户 admin 的权限：

   kubectl auth can-i create pods --as=admin

3. 如何管理大量的 RBAC 资源？

   可以使用 Kubernetes Operators 或其他自动化工具来管理大量的 RBAC 资源。

4. RBAC 最佳实践？

   • 最小权限原则：只授予用户或服务账户所需的最小权限。
   • 使用 Role 和 RoleBinding 来管理 Namespace 级别的权限。
   • 使用 ClusterRole 和 ClusterRoleBinding 来管理集群级别的权限。
   • 定期审查 RBAC 配置，及时发现和解决安全问题。
   • 启用 RBAC 审计，记录所有 RBAC 相关的操作。

希望这些补充能够帮助大家更好地理解和使用 RBAC！ 感谢大家的阅读！ 🙏