Kubernetes权限RBAC的基础和高级模式 - loft


Kubernetes 使组织构建、测试和部署其软件的方式现代化。由于其模块化、开源框架和基于角色的访问控制 (RBAC)，公司可以创建高度可扩展且可靠的企业级集群，同时满足严格的安全和治理要求。
RBAC 框架对不同成员实施访问控制，以确保每个用户根据他们在组织中的职责，拥有对宝贵资源的正确访问权限。
虽然 RBAC 内置于 Kubernetes 中，但它的实现可能很棘手且令人困惑。在本文中，我们将介绍 RBAC 的基础知识、它的工作原理以及如何在 Kubernetes 集群中实现它。
 
什么是 Kubernetes RBAC？
RBAC 是一种授权机制，可为与集群中 Kubernetes 对象交互的用户和应用程序启用细粒度访问。有多种管理 Kubernetes 授权请求的方法，例如基于属性的访问控制 (ABAC) 或 webhooks，但 RBAC 主要用于生产级部署。
使用 RBAC，集群管理员可以根据他们在层次结构中的角色指定应用程序访问权限、添加/删除权限和限制资源可见性。默认情况下启用 Kubernetes RBAC（在 Kubernetes 1.6 及更高版本中）。权限通过手动声明定义授予用户，这些定义在集群中作为角色进行存储和管理。
角色可以代表对某些 API 对象（如 Pod、节点、部署和 ConfigMap）的一组权限，并通过API 组识别用户和进程对它们执行的操作。RBAC 授权使用 rbac.authorization.k8s.io API 组，该组确定 API 授权以简化身份验证并允许动态动态配置策略。
 
RBAC 如何工作？
RBAC 涉及三个主要元素：

  • #1. Subject主角

客户端、进程和用户调用 Kubernetes API 对集群对象进行操作。它们分为三类：用户、组和服务帐户。
  • 用户和组：这些主题不存储在 Kubernetes 数据库中，而是用于集群外的进程。
  • ServiceAccounts：这些主题在 Kubernetes 集群中作为 API 对象存在，用于集群内进程。
  • #2. 动词

在 Kubernetes 集群中的可用部署、服务和 Pod 上执行的操作称为动词。示例是创建、读取、更新或删除 (CRUD) 操作。动词通过 HTTP 发送到 API，Kubernetes 根据 REST API URL 进行翻译。
  • #3. 资源

这些是 Kubernetes 集群中可用的 API 对象，例如 Deployments、Services、Pods 和 PersistentVolumes。这些 API 对象上的规则表示为 ClusterRoles/Roles，可以通过 RoleBinding 和 ClusterRoleBinding 将其定义为 Kubernetes 主体（用户、组或服务帐户）。
角色是一组可以跨不同主题使用的权限。角色通常绑定到一个命名空间，但可用于通过通配符表示多个。
  
Kubernetes 中的默认角色
虽然 Kubernetes 允许您配置自定义角色，但这些角色默认可用：
* cluster-admin：此角色允许超级用户访问以对任何集群资源执行操作。它可以完全控制所有命名空间。
  • admin：此角色允许管理员访问，允许在命名空间内进行无限制的读/写权限。
  • edit：此角色允许对命名空间中的某些对象进行读/写访问。
  • view：此角色允许只读访问命名空间中的视图对象。

这些是不同的权限集：
  • ClusterRole：这是一个在集群范围内应用的角色对象。授予用户 ClusterRole 可提供跨所有命名空间、资源配额和集群节点的查看和编辑访问权限。
  • RoleBinding：RoleBinding 绑定 API 对象和可由主体对其执行的操作。它还处理特定命名空间的操作。
  • ClusterRoleBinding：ClusterRoleBinding 管理整个集群中主体的操作执行。

 
在 Kubernetes 集群中实现 RBAC
以下是实现基本 Kubernetes RBAC 的分步说明。您将能够在 Kubernetes 集群中实现用户、服务帐户、角色和角色绑定。
这些步骤已经在 minikube 中进行了测试，但它们可以应用于任何 Kubernetes 集群。
以下是您需要开始的内容：

详情点击标题