身份(Identity)

本篇包含有关身份的概念信息以及各种术语及其概念的概述。身份在 Vault 中代表经过识别的客户端。因此,Vault 通过身份机密引擎提供身份管理解决方案。有关识别机密引擎及其使用方式的更多信息,请参阅识别机密章节中的机密引擎文档。

实体(Entity)与别名(Alias)

每个用户可能有多个不同的身份提供者提供的账户,并且 Vault 支持其中多种身份提供者使用 Vault 进行身份验证。 Vault 身份机制可以将多种身份验证方法的验证的身份绑定到同一个对象上,这种统一身份的表示称为实体,而与之对应的身份验证提供者的对应帐户可以映射为实体的别名。本质上,每个实体由零个或多个别名组成。一个实体在特定身份验证后端上不能拥有多个别名。

例如,同时在 GitHub 和 LDAP 中有帐户的用户可以映射到 Vault 中具有两个别名的同一个实体,一个是 GitHub 类型,一个是 LDAP 类型。

映射到同一个实体的两个别名,类型分别是 LDAP 和 Github
图 1.3.7/1 - 映射到同一个实体的两个别名,类型分别是 LDAP 和 Github

然而,如果两个别名都是在同一个身份验证方法挂载点上创建的,例如 Github 挂载点,则两个别名不能映射到同一个实体。别名可以具有相同的身份验证类型,只要身份验证挂载的路径不同,就可以与同一实体相关联。下图说明了有效和无效的情况。

有效的同类型别名映射
图 1.3.7/2 - 有效的同类型别名映射
无效的同类型别名映射
图 1.3.7/3 - 无效的同类型别名映射

当客户端通过任何方式(直接使用令牌除外)进行身份验证时,Vault 会创建一个新实体。如果相应实体没有别名,它会为其附加一个新别名。实体标识符会被绑定到经过身份验证的令牌上。当使用此类令牌时,它们的实体标识符会被审计记录,用以标记特定用户执行的操作踪迹。

实体管理

Vault 中的实体不会从任何地方自动提取身份信息。它需要由系统操作员显式进行管理。这样,就可以灵活地管理控制要与 Vault 同步的实体数量。从某种意义上说,Vault 将充当身份的缓存,而不是身份的来源。

实体策略

Vault 策略可以分派给实体,这将在令牌上的现有策略之上授予令牌额外的权限。如果 API 请求中显示的令牌包含实体的标识符,并且该实体具有一组策略,则该令牌也将能够执行该实体的策略允许的操作。

实体策略被添加到令牌上的过程
图 1.3.7/4 - 实体策略被添加到令牌上的过程

这对计算令牌所拥有的策略是一种范式转变。在引入身份之前,令牌上附加的策略名称是不可变的(但策略的内容可以修改)。但是由于引入了实体策略,配合令牌上的一组不可变的策略名称,令牌所拥有的策略将在请求发送到 Vault 时根据身份动态计算得出。这大大增强了已签发令牌行为控制流程的灵活性。

需要注意的是,实体上的策略只是一种授予额外权限的手段,而不是令牌上附加的策略的替代品。要计算出关联了实体标识符的令牌的完整权限集合,要把令牌上附加的策略一起考虑进来。

注意:向身份端点授予非只读权限时要小心。如果用户可以修改实体,他们可以通过策略授予它额外的权限。如果用户可以修改他们可以登录的别名,他们可以将该别名绑定到具有更高权限的实体上。如果用户可以修改组成员身份,则他们可以将其实体添加到具有更高权限的组中。

挂载点绑定别名

Vault 支持多种身份验证方式,也允许在不同的挂载路径上启用相同类型的身份验证方式。用户的别名在某一身份验证方式的挂载点上是唯一的。但是身份存储需要区分这些身份提供者的不同挂载点上彼此冲突的别名。因此,别名与身份验证后端挂载点的访问器结合起来就成了区分别名的唯一标识符。

下表显示了每种受支持的身份验证方法用于构造别名所使用的信息。这些识别信息被用于匹配或创建实体。如果没有显式创建或合并任何实体,则在特定身份验证挂载点上进行身份验证时,表中右侧的对象会被用于隐式创建一个对应的实体:

验证方法 验证方法返回的名称
AliCloud Principal ID
AppRole Role ID
AWS IAM 可以通过 iam_alias 配置项将其设定为 Role ID(默认情况)或是 IAM 的唯一 ID,又或者是 完整的 ARN
AWS EC2 可以通过 ec2_alias 配置项将其设定为 Role ID(默认情况)或是 EC2 实例 ID,又或者是 AMI 镜像 ID
Azure JWT 中的 Subject 项
Cloud Foundry App ID
GitHub 用户 Token 对应的登录名
Google Cloud 可以通过 iam_alias 配置项将其设定为 Role ID(默认情况),或是服务账号的唯一 ID
JWT/OIDC 可以通过 user_claim 配置项将其设定为某个属性(没有默认值)
Kerberos 用户名
Kubernetes 服务账号 UID
LDAP 用户名
OCI 角色名
Okta 用户名
RADIUS 用户名
TLS 证书 Subject CommonName
令牌 entity_alias,如果有的话
用户名(userpass 验证) 用户名

隐式实体

操作员可以为某个身份验证挂载点上的所有用户预先创建对应实体并为其分配策略,以便在用户登录时,通过实体为令牌分配所需的权限。但如果没有这样设置,当用户从任何身份验证方法成功登录后,Vault 将创建一个新实体并之分配一个别名。

请注意,使用令牌身份验证后端创建的令牌通常不会具有任何关联的身份信息。使用配置了 allowed_entity_aliases 列表参数的令牌角色创建令牌时,可以使用 entity_alias 参数分配一个现有实体,或是隐式创建一个新实体。

身份审计

如果关联了实体标识符的令牌被用于进行 API 调用,那么 Vault 会将之记录到审计记录里,这会留下特定用户执行操作的踪迹记录。

身份组

Vault 身份支持组。一个组可以包含多个实体作为其成员。一个组可以有子组。在组上设置的策略会被授予组内所有成员。在 Vault 处理请求时,当计算令牌对应的实体所拥有的策略时,因组成员身份而继承的策略会与实体本身的策略一起被附加到令牌上。

包含身份组策略的实体策略计算结果
图 1.3.7/5 - 包含身份组策略的实体策略计算结果

组策略的继承

一个实体可以是一个组的直接成员,这时它将继承所有附加在该组上的策略。实体也可以是组的间接成员。例如,如果 GroupB 是 GroupA 的子组,则 GroupB 的成员是 GroupA 的间接成员。因此,GroupB 的成员将同时拥有附加在 GroupA 和 GroupB 上的策略。

外部组与内部组

默认情况下,在身份存储中创建的组称为内部组。这些组的成员资格是手动管理的。也可以创建外部组,在这种情况下,组中的实体成员的资格是半自动管理的。外部组就像是身份存储之外的组在 Vault 内的一个映射。外部组可以拥有一个(并且只能有一个)别名。此别名应映射到身份存储之外的组的概念,比如说,LDAP 中的组和 GitHub 中的团队。属于某个 LDAP 组的 LDAP 用户名可以在登录和令牌续期时自动将其实体 ID 添加为 Vault 中的组的成员。这种机制只有在 Vault 中的组是外部组并且有一个映射到了 LDAP 中的组的别名时才有效。如果用户被从 LDAP 中的组中删除,则该更改只有在后续执行登录或续约操作时才会被反映在 Vault 中。

results matching ""

    No results matching ""