google_project_iam_*与其他GCP IAM资源的区别及使用疑问

关于google_project_iam_*的权限范围 #

你推测的没错，google_project_iam_*是项目级的IAM绑定，权限范围最宽泛——项目作为GCP多数资源的父级，给项目绑定IAM角色后，该角色的权限会覆盖项目下所有符合权限范围的资源（包括服务账号、实例、存储桶等），所以替换后能正常工作是合理的。

如何判断是否存在对应资源的专属IAM资源（优先使用细粒度资源） #

要找针对特定资源的IAM Terraform资源，通用方法有这几个：

• 按Terraform资源命名规律查找：GCP Provider的IAM资源命名基本遵循google_<资源类型>_iam_<member/binding>的格式，比如服务账号对应google_service_account_iam_member，云存储桶对应google_storage_bucket_iam_member，Compute实例对应google_compute_instance_iam_member。直接按这个规律搜就能快速定位。
• 查看GCP IAM角色的可授权资源类型：每个IAM角色的官方文档会明确标注「可授予的资源」，比如某个角色只能在项目、实例层级授权，那对应的Terraform就会有这两类资源的IAM绑定资源。
• 验证gcloud命令是否存在：如果gcloud有针对该资源的IAM绑定命令（比如gcloud compute instances add-iam-policy-binding），那Terraform大概率会有对应的资源，因为Terraform的GCP Provider基本对齐了gcloud的操作能力。
• 查Terraform GCP Provider文档：每个资源的详情页会列出对应的IAM相关资源，比如Compute Instance的文档里会专门说明google_compute_instance_iam_member的用法。

关于roles/compute.osAdminLogin实例级IAM绑定不生效的问题 #

这个问题是因为OS Login的权限逻辑比较特殊，不是单纯绑定实例级IAM就可以：

1. 必须先启用实例的OS Login：实例的元数据必须设置enable-oslogin=true，否则即使绑定了角色也无法通过OS Login登录。
2. 用户/服务账号的OS Login配置要到位：如果是普通用户，需要先上传SSH密钥到OS Login（比如通过gcloud compute os-login ssh-keys add）；如果是服务账号，需要确保服务账号已经关联了OS Login的权限基础。
3. IAM成员格式必须正确：比如用户要写成user:xxx@example.com，服务账号要写成serviceAccount:xxx@project-id.iam.gserviceaccount.com，格式错误会导致绑定不生效。
4. 项目级的基础权限可能是前提：OS Login本身依赖项目级的compute.osLogin API权限，部分场景下需要先给用户绑定项目级的roles/compute.osLogin，再结合实例级的osAdminLogin才能生效——虽然文档说最低资源是实例，但实际场景中需要配套项目级的基础权限支持。

内容的提问来源于stack exchange，提问作者x-yuri