HashiCorp Vault OIDC SSO 基于Azure AD组限制命名空间登录问题

配置不生效的核心原因有两点：

• Azure AD默认在OIDC令牌的groups声明中返回用户组的Object ID（GUID格式），而非控制台可见的组显示名VaultAdmins/VaultUsers，当前配置直接用显示名做匹配规则，永远无法命中。
• 现有角色配置未做命名空间级策略绑定，存在跨命名空间权限继承风险。

1. 获取Azure AD组的匹配标识 #

• 登录Azure AD门户，进入VaultAdmins、VaultUsers两个用户组的详情页，分别复制两个组的Object ID备用。
• 若坚持用组显示名做匹配，需要到对应Azure AD应用注册的「令牌配置」页，修改groups声明的返回格式为displayName，该配置在多域混合环境下存在兼容性风险，生产环境优先使用Object ID做匹配，稳定性更高。

2. 修正Root命名空间OIDC角色配置 #

groups为数组类型声明，Vault对数组类型声明的bound_claims匹配逻辑为：只要数组中包含绑定值即判定匹配通过，无需特殊数组写法，直接将绑定值替换为VaultAdmins组的Object ID即可，修正后的配置参考：

resource "vault_jwt_auth_backend_role" "azure" {
  role_name             = var.azure_role_name 
  backend               = vault_jwt_auth_backend.root.path
  user_claim            = "email"
  groups_claim          = "groups" 
  
  # 替换为实际的VaultAdmins组Object ID
  bound_claims          = { "groups": "替换为VaultAdmins组的Object ID" }
  
  role_type             = "oidc"
  oidc_scopes           = var.oidc_scopes 
  allowed_redirect_uris = var.allowed_redirect_uris
  verbose_oidc_logging  = "true" 

  # 绑定Root命名空间专属管理员策略，避免跨命名空间权限泄露
  token_policies          = ["root-vault-admins"] # 替换为实际的Root管理员策略名
  token_no_default_policy = false
}

3. 修正子命名空间OIDC角色配置 #

逻辑和Root命名空间一致：找到子命名空间挂载的OIDC认证方法对应的角色配置，将bound_claims值替换为VaultUsers组的Object ID，同时绑定子命名空间专属的用户权限策略，禁止继承Root命名空间默认策略。

4. 补充权限兜底配置（生产环境必选） #

不要仅依赖bound_claims做访问控制，额外配置Vault外部身份组映射做双重校验：

• Root命名空间下创建外部身份组，关联VaultAdmins组Object ID，绑定Root命名空间管理员策略
• 子命名空间下创建外部身份组，关联VaultUsers组Object ID，绑定子命名空间用户策略
  该配置可实现组权限自动同步，即使角色配置出现误调整，也不会出现越权访问。

5. 配置验证 #

• 保持verbose_oidc_logging开启，使用VaultAdmins组测试账号登录Root命名空间，查看Vault审计日志中返回的groups声明实际值，确认与配置的Object ID一致。
• 分别做权限边界测试：VaultAdmins组用户尝试登录子命名空间应被拒绝，VaultUsers组用户尝试登录Root命名空间应被拒绝。

• 确保Azure AD应用已授予GroupMember.Read.All委托API权限，否则令牌中不会返回完整的用户组列表，导致匹配失败。
• 若使用了嵌套用户组，需要调整groups_recurse_max_depth参数到对应嵌套层级，否则嵌套组内的用户不会返回对应组ID。
• 两个命名空间的OIDC回调地址都需要添加到Azure AD应用的重定向URI列表中，否则会出现回调报错。

内容的提问来源于stack exchange，提问作者hitman126