曾经云 API 访问的默认模式是：

• Access Key / Secret Key
• Service Account JSON
• Client Secret

而今天，国外的几大云厂商：

• Amazon Web Services
• Google Cloud
• Microsoft Azure

都在推动同一个方向：

弱化长期密钥 → 默认短期令牌 → 最终 Keyless

一、云安全范式变化：从“密钥”到“身份”

传统模型：

1

应用 → 存储密钥 → 调用 API

新模型：

1

应用 → 证明身份 → 换取临时令牌 → 调用 API

本质变化是：

这就是：Identity-first security

二、云内访问：环境即身份

核心思想：运行环境 = 身份提供者

应用无需保存任何密钥

Google Cloud

• Service Account 绑定到 VM / Pod
• 通过 Metadata Server 获取 Token
• Token 默认 1 小时过期

Azure

• Managed Identity 自动注入
• 支持系统分配与用户分配
• 可以直接访问数据库、Key Vault 等服务

AWS

• IAM Role 绑定 EC2 / Lambda
• 通过 IMDSv2 获取临时凭据
• 实际上是 STS AssumeRole 的自动化版本

云内访问统一架构

1
2
3
4
5
6
7

Compute Instance
    ↓
Metadata Service
    ↓
STS Token
    ↓
Cloud API

这意味着：云内访问已经全面 Keyless

三、云外访问：身份联合成为主流

真正的革命发生在 云外访问 场景。

例如：

• CI/CD 系统
• Kubernetes 集群
• 本地数据中心
• 多云调用

过去做法：

1

下载密钥 → 写进配置 → 调 API

现在做法：

1

外部身份 → 联合信任 → STS → 临时 Token

OIDC 联合（最常见）

典型流程：

1
2
3
4
5
6
7

CI / Pod / 服务
    ↓
OIDC Token
    ↓
Cloud STS
    ↓
短期访问令牌

最常见场景：

• GitHub Actions
• Kubernetes Pod Identity
• 多云服务互调

三家云都支持：

X.509 联合（企业数据中心）

AWS 的做法较特殊：

IAM Roles Anywhere

流程：

1
2
3
4
5
6
7

本地服务器
    ↓
X.509 私钥签名
    ↓
STS AssumeRole
    ↓
临时 AK/SK

本质仍然是：

证书 → STS → 短期凭据

只是身份凭据从 OIDC 换成 PKI。

四、静态密钥正在被淘汰

虽然仍存在：

但趋势非常明确：

Google

• 支持组织级禁止创建 SA Key
• 默认推荐 Keyless impersonation

Azure

• Client Secret 被标记为 legacy
• 推荐 Certificate 或 Federation

AWS

• Access Key 仍存在
• 但官方最佳实践已明确：避免长期密钥

五、三云已经形成统一身份模型

其实三家云的安全架构已经收敛成同一模式：

1
2
3
4
5
6
7

Identity Proof
     ↓
Federation Trust
     ↓
STS Exchange
     ↓
Short-lived Token

区别只在：

• 身份证明方式（OIDC / X509 / Metadata）
• Token 格式（JWT / OAuth / AWS STS）

但核心流程完全一致。

六、多云架构的最佳实践

永远优先 Keyless

如果能使用：

• Pod Identity
• Managed Identity
• Workload Federation

就不要使用静态密钥。

多云访问统一走 OIDC

推荐模式：

1
2
3
4
5

统一 IdP（如 Kubernetes OIDC）
      ↓
信任各云 STS
      ↓
获取各云短期 Token

这样：

• 不需要保存任何密钥
• 统一身份治理
• 审计清晰

本地数据中心优先证书联合

如果没有 OIDC：

• 使用企业 CA
• 通过证书换 STS Token
• 避免长期 AK/SK