HashiCorp Vault多应用多ServiceAccount：防止跨应用盗用ServiceAccount

下面是针对你的场景，防止应用盗用其他应用ServiceAccount访问Vault的具体措施：

1. 严格遵循最小权限原则 #

• 给每个应用的Vault策略精准限定访问范围：比如为application A配置的策略仅允许读取secret/appA/*路径，application B的策略仅开放secret/appB/*，即便ServiceAccount被盗用，攻击者也只能获取对应应用的密钥。
• 限制ServiceAccount在Kubernetes内的权限：通过Role和RoleBinding，仅允许目标ServiceAccount在指定Namespace、指定Pod中被使用，禁止其他Namespace的Pod挂载该ServiceAccount。

2. 配置Vault Kubernetes Auth的细粒度绑定 #

在创建Vault的Kubernetes Auth角色时，明确绑定对应的ServiceAccount名称和Namespace，确保只有指定主体能通过该角色获取Vault令牌：

vault write auth/kubernetes/role/appA-role \
  bound_service_account_names=appA-sa \
  bound_service_account_namespaces=appA-ns \
  policies=appA-policy \
  ttl=1h

这样就算其他应用拿到appA-sa的token，只要不在appA-ns Namespace下，Vault会直接拒绝认证请求。

3. 启用ServiceAccount Token的短期化与自动轮转 #

• 配置Kubernetes使用短期ServiceAccount Token：通过TokenRequest API为Pod生成临时Token，而非使用长期的Secret形式Token，过期后自动失效，缩小被盗用后的影响窗口。
• 设置Vault令牌的短TTL：比如将令牌有效期设为1小时，同时限制续租权限，仅允许合法应用续租，进一步降低风险。

4. 强化监控与审计 #

• 开启Vault审计日志：记录所有认证请求和密钥访问操作，一旦发现非预期来源（如陌生IP、其他Namespace）的访问，立即触发告警。
• 监控Kubernetes中ServiceAccount的挂载情况：跟踪哪些Pod挂载了特定ServiceAccount，发现非授权挂载时及时响应。

5. 用Namespace隔离应用环境 #

• 将application A和application B部署在独立的Namespace中，通过NetworkPolicy限制跨Namespace的通信，降低跨应用的权限泄漏风险。
• 每个Namespace内的ServiceAccount仅在本Namespace生效，避免跨Namespace的权限滥用。

6. 禁止硬编码ServiceAccount凭证 #

• 依赖Kubernetes的自动挂载机制为Pod注入ServiceAccount Token，禁止在镜像或配置文件中硬编码凭证，防止凭证被意外泄露。

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