已部署在VNET中的Azure Container Instance绕开托管身份限制访问Key Vault方案咨询

我懂你现在的痛点——ACI部署在VNET里没法用托管身份，还不想用环境变量或机密卷（毕竟定时运行的脚本要是能拿到所有机密，泄露风险太高了）。下面几个方案既能绕开限制，又符合你的安全需求：

1. 用Azure Functions做安全中间层（最推荐，适配最小权限原则） #

这个方案通过一个隔离的中间层来处理Key Vault的身份验证和机密获取，ACI只需要调用中间层的API获取当前任务需要的特定机密，完全不用碰Key Vault的凭证，也不会拿到所有机密：

• 第一步：在同一个VNET里部署Azure Functions（或者给Functions配置VNET集成，让ACI所在的子网能访问它）
• 第二步：给Functions启用系统分配的托管身份，在Key Vault的访问策略里给这个身份分配仅所需机密的读取权限（一定要遵循最小权限，别给全量机密权限）
• 第三步：在Functions里写个简单的API接口，比如/get-secret?name=xxx，接口内部用托管身份调用Key Vault API拿到指定机密再返回
• 第四步：ACI的脚本里只需要调用这个接口拿当前要用的单个机密，不需要存任何身份凭证
• 额外加固：可以给Functions配置VNET访问限制，只允许ACI所在的子网访问；或者启用API密钥认证，密钥可以通过一次性安全方式（比如首次部署临时传入，之后脚本不存储）配置，甚至靠VNET隔离就能免密钥

这个方案的好处是：ACI完全不接触Key Vault的身份信息，每次只拿需要的机密，就算脚本泄露，攻击者也只能拿到单个机密（不是所有），而且中间层的身份由Azure托管，不用手动管凭证。

2. 服务主体证书认证 + VNET隔离 #

要是不想加中间层，可以用服务主体的证书做无密码认证，再结合VNET限制Key Vault的访问范围：

• 第一步：创建一个服务主体，给它分配Key Vault里仅所需机密的读取权限
• 第二步：生成服务主体的自签名证书（或者用Azure Key Vault生成），把公钥上传到服务主体，私钥存成PEM文件
• 第三步：配置Key Vault的虚拟网络访问规则，只允许ACI所在的VNET/子网访问，拒绝公共网络请求
• 第四步：通过一次性安全方式把证书私钥部署到ACI里（比如首次部署用临时机密卷，部署完立刻移除；或者用Azure CLI在容器启动时从安全存储拉取，别留痕迹）
• 第五步：ACI脚本里用证书给服务主体认证（比如Azure CLI命令az login --service-principal --username <客户端ID> --tenant <租户ID> --password <证书路径>），然后只获取当前需要的机密

这里要注意证书私钥的安全传递，别让它长期存在容器里，而且服务主体的权限一定要最小化，避免泄露后影响所有机密。

3. 私有链接 + 短期访问令牌 #

如果你的ACI脚本能调用Azure AD的令牌服务，也可以用短期访问令牌访问Key Vault：

• 第一步：给Key Vault配置私有链接，接入ACI所在的VNET，确保流量全在VNET内走
• 第二步：创建一个服务主体（不推荐用用户账户，毕竟是无人值守场景），分配最小权限的Key Vault访问策略
• 第三步：脚本里通过Azure AD的令牌端点获取短期（默认1小时）的Key Vault访问令牌，然后直接调用Key Vault的REST API拿特定机密
• 优势：令牌有效期短，就算泄露也很快失效；而且每次只拿需要的机密，暴露面小

关键注意事项 #

不管用哪个方案，一定要遵循最小权限原则：别给任何身份开Key Vault的全量机密访问权限，只分配当前任务必须的单个/少数机密的读取权限，这样就算凭证泄露，影响范围也能降到最小。

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