如何在Google Compute Engine VM中仅为指定Linux用户开放服务账号访问权限？

推荐方案 #

推荐采用「元数据服务器访问控制+Linux用户权限隔离+临时凭据生成」的组合方案，具体落地步骤如下：

1. 给服务账号配置最小权限
   先给VM关联的服务账号只添加用户B业务必需的IAM权限，遵循最小权限原则，把风险范围压缩到最小。

2. 限制用户A访问元数据服务器
   虽然元数据服务器的IP（169.254.169.254）未被官方承诺永久固定，但可以结合Linux的iptables/nftables和进程级管控工具（比如AppArmor）做双重限制：

• 用iptables直接拦截用户A的UID访问元数据IP：

  iptables -A OUTPUT -m owner --uid-owner <用户A的UID> -d 169.254.169.254 -j DROP
  

• 给用户A的进程配置AppArmor策略，禁止其访问元数据服务器的端口和相关路径，就算IP变更也能有效拦截。

3. 给用户B配置可信的凭据获取方式
   不让用户B直接从元数据服务器获取长期凭据，而是用gcloud生成临时凭据，同时限制只有用户B能执行相关操作：

• 让用户B通过以下命令生成临时凭据并设置环境变量：

  export GOOGLE_APPLICATION_CREDENTIALS=$(gcloud auth application-default print-access-token --impersonate-service-account <服务账号邮箱>)
  

• 修改gcloud工具的权限，仅允许用户B运行这类生成凭据的命令，确保临时凭据只有可信进程能获取。

4. 容器场景额外优化
   如果用户A是容器进程，直接使用GKE的Workload Identity功能：给可信容器（对应用户B的业务）绑定专属服务账号，不可信容器不绑定任何服务账号，彻底隔离凭据访问路径。

对原有思路的点评 #

• 单独拦截元数据IP：确实存在IP变更的风险，但配上进程级管控（比如AppArmor）后可靠性会大幅提升，作为辅助限制手段是可行的。
• 存储服务账号密钥：这个方法弊端太多，密钥手动管理容易引发泄露风险，完全不符合官方安全最佳实践，绝对不推荐。

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