多云混合架构: 网络互通与认证授权
85

前言

在企业多云架构逐步普及的今天，如何实现不同云环境间的 “资源互通” 与 “身份互信”，已成为云基础设施设计中的关键挑战。

传统上，网络打通就意味着“互通”，但在现代云环境下，这只是基础。真正的目标是：

  1. 让不同云的工作负载能安全访问彼此的服务（例如 RDS、MSK、MemoryDB、Redis）；
  2. 在多云环境下实现统一的身份与授权体系（Federated IAM / OIDC / SAML）；
  3. 让 Kubernetes、ECS、EC2 等工作负载在无长期密钥的情况下访问异云资源。

本文将从网络、DNS、身份、授权四个层面系统介绍多云互通架构，并结合 AWS + 阿里云 / 腾讯云 的实际场景，给出落地方案。

一、网络互通：Direct Connect 与 Equinix 的物理基础

1️⃣ Direct Connect 的物理世界

在物理层面，AWS Direct Connect（DX） 是一条专用的物理链路，用于将企业数据中心或其他云环境接入 AWS 网络。
不同于 VPN 或公网传输，DX 链路在数据平面上完全绕过 Internet，提供：

  • 低延迟（通常 < 2ms）
  • 稳定带宽（50Mbps - 100Gbps）
  • 高安全性（物理隔离）

这种连接通常通过 中立运营商的数据中心（Colocation） 实现。企业租用机柜或虚拟连接后，可以与多个云厂商建立专线连接。

2️⃣ Equinix 的角色：云间的物理“中转站”

全球范围内的云厂商（AWS、阿里云、腾讯云、Azure、Google Cloud 等）通常都在 Equinix Fabric 上部署接入节点。

Equinix 提供的服务类似于一个云中枢交换网络（Cloud Exchange Fabric）：

  • AWS 客户可以在 Equinix 上创建 Direct Connect；
  • 腾讯云/阿里云客户可以在同一地点创建专线接入；
  • 两者之间只需在 Equinix 的虚拟交换层“Cross Connect”，即可在私网层完成互通。

这意味着——即使是 AWS 与阿里云 / 腾讯云这样的异构云，也可以在同一物理交换层安全互连。

参考文档

  1. AWS Direct Connect Delivery partners

    可以查看支持交付AWS Direct Connect的供应商，以US East (N. Virginia)为例，China Mobile International可从Equinix MI1, Miami, FL接入AWS Direct Connect服务

  2. AWS Direct Connect

  3. Tencent Cloud Direct Connect

二、服务发现：DNS 分层解析与跨云资源访问

网络连通只是第一步，真正的难点是“如何找到对方的服务”。

问题：PaaS 服务的私有域名不可跨云解析

例如：

  • AWS RDS 的内网端点是 mydb.abcdefghijkl.ap-southeast-1.rds.amazonaws.com；
  • 阿里云 RDS 的端点可能是 mydb.mysql.rds.aliyuncs.com；
  • 腾讯云 PostgreSQL 的端点可能是 pg.qcloud-region.db.tencentcdb.com。

这些域名只能在各自云的私有 DNS 中解析。
一旦跨云访问，就会出现解析失败或错误地解析到公网地址。

解决方案：多层 DNS Resolver + Forwarding Chain

一种可行的架构：

  1. AWS 侧：

    • 启用 Route 53 Resolver Outbound Endpoint；
    • 将解析请求通过 Direct Connect 转发至阿里云。

  2. 阿里云 / 腾讯云 侧：

    • 使用 PrivateZone + DNS Forwarder；
    • 对特定域名（如 *.rds.amazonaws.com）配置转发规则。

  3. 互通逻辑：

    • 阿里云发出的对 AWS 内网服务的解析请求 → 通过 Direct Connect → AWS Route53 解析 → 返回内网 IP；
    • 反向亦然。

这样就实现了跨云的 私网服务发现机制，使得各云上的 PaaS 服务能被其他云内的工作负载访问。

dns.png

三、身份互信：从 Federated Identity 到 IAM Role 信任

网络打通后，安全问题才刚刚开始。

多云下的认证体系不能简单依靠共享密钥（AK/SK），而应该通过 联邦身份（Federated Identity） 实现基于信任的访问控制。

1️⃣ 联邦身份的两种主流协议

协议格式特点典型用途
SAML 2.0XML企业级、成熟、广泛支持与 AD / Okta / Azure AD 集成
OIDC (OpenID Connect)JWT (JSON Web Token)轻量、云原生Kubernetes、Serverless、跨云工作负载

四、AWS IAM 的信任模型

AWS IAM 通过 STS（Security Token Service）签发临时凭证，用于跨云、跨账户访问。

1️⃣ AssumeRole

  • 需要调用方持有 AWS 的长期 AK/SK；
  • 用于 AWS 内部账户间信任；
  • 调用 sts:AssumeRole，换取临时凭证。

2️⃣ AssumeRoleWithWebIdentity

  • 不需要 AK/SK；
  • 使用外部 IdP（OIDC）签发的 JWT 令牌；
  • 典型场景：Kubernetes Pod、阿里云 ECS、腾讯云 CVM。

AWS 通过 OIDC Provider 验证外部 IdP 的签名后，允许临时访问指定资源。
两者的主要区别如下：

对比项AssumeRoleAssumeRoleWithWebIdentity
凭证类型AK/SKOIDC Token
典型场景AWS 内部跨账户外部云或 K8s 工作负载
身份来源IAM User / RoleOIDC Provider
安全特性长期密钥临时短期凭证（15min - 1h）

五、实操：让阿里云 / 腾讯云工作负载访问 AWS IAM 资源

🧩 步骤 1：在阿里云或腾讯云创建 OIDC Provider

在阿里云上：

  • OIDC Issuer URL 通常为 https://sts.aliyun.com/oidc/
  • 支持签发符合 OIDC 标准的 JWT

🧩 步骤 2：在 AWS IAM 中注册外部 IdP

aws iam create-open-id-connect-provider \
  --url https://sts.aliyun.com/oidc/ \
  --client-id-list 1234567890123456 \
  --thumbprint-list <aliyun-cert-thumbprint>

🧩 步骤 3：创建信任外部 OIDC 的 IAM Role

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/sts.aliyun.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "sts.aliyun.com:aud": "1234567890123456",
          "sts.aliyun.com:sub": "ecs-instance-id:i-abc123xyz"
        }
      }
    }
  ]
}

🧩 步骤 4：在阿里云 ECS 内请求 AWS STS 临时凭证

aws sts assume-role-with-web-identity \
  --role-arn arn:aws:iam::<AWS_ACCOUNT_ID>:role/AliyunFederatedAccess \
  --role-session-name ecs-demo \
  --web-identity-token file://token.jwt

输出中包含 AccessKeyId、SecretAccessKey、SessionToken，可直接用于访问 AWS RDS、S3、DynamoDB 等资源。

六、Kubernetes 工作负载：使用 ServiceAccount + IAM OIDC

Kubernetes 集群进一步抽象了计算节点与服务身份，推荐使用 ServiceAccount + OIDC 模式：

  1. 在集群中启用 --service-account-issuer 与 --service-account-signing-key-file；
  2. 在 AWS IAM 注册该 OIDC Provider；
  3. 创建信任该 Provider 的 IAM Role；
  4. 为特定 ServiceAccount 添加注解：
apiVersion: v1
kind: ServiceAccount
metadata:
  name: aws-access
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNT_ID>:role/K8sWebIdentityRole

运行在该 ServiceAccount 下的 Pod 会自动使用 IRSA (IAM Roles for Service Accounts) 机制，与 AWS STS 完成身份交换。

七、全景描述

TODO

🏗️ 层次结构

  1. 物理互联层（Equinix / DX）

    • 阿里云专线接入 Equinix；
    • 腾讯云专线接入 Equinix；
    • AWS Direct Connect 接入同一 Fabric；
    • Equinix Fabric 负责云间 VLAN 打通。

  2. DNS 分层解析层

    • 各云内部部署 DNS Forwarder；
    • AWS 启用 Route53 Outbound Resolver；
    • 阿里云 PrivateZone 将 *.amazonaws.com 转发至 AWS；
    • 腾讯云 Private DNS 将 *.aliyuncs.com 转发至阿里云。

  3. 身份互信层

    • 阿里云 STS、腾讯云 CAM 作为外部 OIDC IdP；
    • AWS IAM 注册对应 OIDC Provider；
    • 各云 IAM Role 之间通过 AssumeRoleWithWebIdentity 信任关系互通。

  4. 工作负载层

    • EC2 / ECS / CVM：使用 OIDC Token 访问 AWS 资源；
    • Kubernetes 集群：ServiceAccount 通过 IRSA 自动交换凭证；
    • PaaS 服务（RDS、MSK、Redis）：通过私网域名解析访问。

  5. 控制平面层

    • 可选使用统一的身份网关（Auth0、Dex、Keycloak）集中管理 IdP；
    • 结合 GitOps 平台（Argo CD / KubeVela）实现统一身份上下文注入。

八、总结

维度技术方案核心组件关键收益
网络互通Direct Connect + Equinix FabricDX Gateway, Cross Connect安全、稳定、低延迟
服务发现DNS Forwarder + Resolver ChainRoute53 Resolver, PrivateZone私网 PaaS 访问
身份认证OIDC / SAML 联邦IAM, STS, IdP (Aliyun/Tencent)无需共享长期凭证
授权模型AssumeRole / AssumeRoleWithWebIdentityIAM Policy, Role Trust精细化权限控制
K8s 访问SA + OIDC (IRSA)ServiceAccount, IAM Role无密钥、自动凭证交换

多云互联的本质不在于“线路连通”，而在于 “服务与身份的安全互信”。
必须在网络、DNS、身份、授权四层均建立互信链路

多云混合架构: 网络互通与认证授权
https://georgeji.com/archives/duo-yun-hun-he-jia-gou-wang-luo-hu-tong-yu-ren-zheng-shou-quan
作者
George.Ji
发布于
更新于
许可