与任何其他安全系统一样,Kubernetes 支持以下概念:

  • 用户认证(authentication):验证和证明用户和组以及服务帐户的身份。
  • 授权(authorization):允许用户使用 Kubernetes 资源执行特定操作。
  • accounting:存储操作,通常用于审计。

授权用户对资源访问的过程始终是一个挑战,特别是在通过团队成员或项目成员身份来控制访问权限时。

由于 Kubernetes 组成员身份是由身份服务(Identity Provider,IdP)在 API 外部进行处理,因此集群管理员需要与身份服务管理员进行交互以设置这些组成员身份,这样一来工作流就非常繁琐。身份服务可能无法提供组成员身份所有 Kubernetes 角色绑定(RoleBindings)包含的终端用户“完整”列表,迫使集群管理员要处理每个用户访问。

本文介绍了一种使用 Kubernetes 授权功能来“模仿”组成员身份的方法,希望对大家有所帮助。

Kubernetes 用户认证概述

用户认证(authentication)是任何集群管理员都应遵循的策略关键部分,它可以确保 Kubernetes 集群基础结构的安全,只有经过允许的用户才能访问。

这里简单介绍 Kubernetes 是如何进行用户认证的。用户主要分为两类:

  • 服务帐户(ServiceAccount,SA)
    • 这类 ID 由 Kubernetes 本身在集群中管理。
    • 每个服务账户都有一个用户认证令牌(JWT)作为其凭证。
  • 普通用户(外部角色或 Bot 用户)
    • x509 证书。
    • 静态令牌或包含用户名和密码列表的文件。
    • 通过外部身份服务(IdP)的 OpenID Connect(OIDC)令牌
    • Webhook 令牌
    • 与云用户认证机制集成的 Kubernetes 托管程序

用户 ID 包含在每次 Kubernetes API 的调用中,而后者又由 RBAC 授权。

使用 OIDC 进行用户认证很常见,它提供了单点登录(SSO)功能。某些组织还会使用最终用户 x509 证书,这些证书无需任何外部 IdP 干预即可颁发。不过,这些常见方法也有些问题:

  • x509 证书:虽然易于设置,但用户最终会有无法撤销的 x509 捆绑包(密钥和证书),这迫使集群所有者指定较低的到期时间。此外,用户组本身被写入 x509 证书后,集群管理员在每次更改成员资格时都要重新颁发证书,但又无法撤消先前的证书,这样用户将继续保持旧的组成员身份,直到先前的证书过期为止。
  • OIDC 用户认证:此方法使用组织的 IdP 提供 SSO。当所提供的身份缺乏组成员身份,或者组成员身份(由组织设置)没有被 Kubernetes 工作负载需求映射到用户团队或项目成员身份时,就会出现问题。

在对用户进行用户认证之后,我们再看看如何授权他们使用 Kubernetes 集群。

Kubernetes 授权和 RBAC 概述

可以通过下图了解 Kubernetes RBAC:

使用伪装的“虚拟用户”控制访问

Kubernetes RBAC 有一个特殊的“伪装”方法,可允许对象(即用户、组、服务账户)获取其他 Kubernetes 用户或组的身份。

这些伪装来的身份不一定必须存在,因为 Kubernetes 控制平面可能本身就没有这些用户或组,在本文中我们将其称为“虚拟用户(virtual-users)”。通过此功能,我们可以将“虚拟用户”设置为“角色帐户(role account)”安全主体。例如:

  • alice@example.com,作为应用程序前端(Application Frontend,app-fe)团队的成员可以伪装 app-fe-user 虚拟用户
  • bob@example.com,作为应用程序后端(Application Backend,app-be)团队的成员可以伪装 app-be-user 虚拟用户

创建 RBAC 规则以允许此类“虚拟用户”访问其所需的 Kubernetes 资源,如下图所示:

如上所示,使用 Kubernetes RBAC 功能,授权处理分为:

  • 团队成员(membership):RBAC ClusterRole 和 ClusterroleBinding,声明允许伪装其团队虚拟用户的用户。
  • 团队职责(duty):RBAC Role 和 RoleBinding,指出团队的虚拟用户可以访问哪些实际 Kubernetes 资源。

实际的伪装操作是通过 Kubernetes API 调用的头部字段指定的,用 kubectl 以实现:

按照上图所示的示例,用户“alice@example.com”可以通过使用以下命令重载 kubectl CLI 来轻松伪装成虚拟团队用户 “app-fe-user” :

RBAC 规则的工作示例

现在已经“创建”了虚拟用户,让我们看看实际中 RBAC 规则的有效示例。对于该例子,假定以下情形:

  • 用户 alice@example.com 和 alanis@example.com 已通过某种形式的 SSO 进行了用户认证。
  • 他们是 app-fe(Application Frontend)团队的成员。
  • Kubernetes 集群具有与 app-fe 工作负载相关的三个命名空间(NS):开发、模拟和生产。
  • 将创建一个名为 app-fe-user 的虚拟用户,允许 Alice 和 Alanis 伪装。
  • 该 app-fe-user 将被授予以下访问:
    • dev-app-fe NS:管理员权限。
    • staging-app-fe NS:编辑权限。
    • prod-app-fe NS:仅查看访问权限。
为了简单起见,我们使用 Kubernetes ClusterRoles(可用于命名空间范围的 RoleBindings)来实现上述访问规则。

步骤 1:准备 RBAC 清单文件下面的示例使用 k14s/ytt 来实现: