保留constraints/iam.allowedPolicyMemberDomains策略，为外部用户授予GKE-IAP指定服务访问权限

针对你的场景，核心问题在于constraints/iam.allowedPolicyMemberDomains组织策略会限制IAM策略中的成员域名，因此不能通过常规IAM角色授予域外用户权限。需要结合IAP OAuth客户端独立配置和服务级访问控制来实现需求，具体步骤如下：

1. 为目标GKE服务创建独立的IAP OAuth客户端 #

每个需要开放给外部用户的GKE服务，单独配置一个OAuth客户端，避免权限范围扩散：

• 进入Cloud Console的IAP页面，找到对应GKE服务的条目
• 点击编辑OAuth客户端配置，创建新的专属客户端（不要与内部用户共用同一个客户端）

2. 配置OAuth客户端的外部用户访问权限 #

绕过组织策略的IAM限制，直接在OAuth客户端层面开放外部用户：

• 进入Google Cloud的API控制台，找到刚才创建的OAuth客户端对应的OAuth同意屏幕
• 将同意屏幕类型设置为外部，并添加允许访问的外部用户邮箱/群组（即使域名在组织策略禁止列表中，此配置不受allowedPolicyMemberDomains约束）
• 注：正式环境需完成OAuth同意屏幕的验证流程，测试阶段可先添加测试用户

3. 配置客户端级别的精细化访问规则 #

确保外部用户仅能访问指定GKE服务：

• 回到IAP页面，选中目标GKE服务的OAuth客户端
• 点击添加访问规则，指定允许的外部用户/群组，规则范围仅限当前服务
• 不要在全局IAP策略或其他服务的客户端中添加这些外部用户，避免越权访问

4. 可选：增强GKE后端授权（额外安全层） #

如果需要更严格的控制，可在GKE服务的Ingress或后端服务中添加身份校验：

• 配置Ingress的authz规则，检查用户邮箱域名或身份属性
• 或在应用层添加逻辑，验证用户身份是否属于允许的外部用户列表

为什么之前的方案失败？ #

• 方案1：constraints/iam.allowedPolicyMemberDomains会检查IAM策略中的所有成员，即使外部用户加入内部群组，IAM成员验证仍会触发组织策略的域名限制，导致访问被拒
• 方案2：修改全局OAuth受众为外部后，未针对单个服务的客户端配置访问规则，全局受众设置优先级高于单个客户端的权限限制，因此所有用户能访问全部IAP保护服务

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