把 Eclipse Dataspace Components（EDC）连接器部署到 AWS，真正困难的部分通常不是启动容器，而是划清信任边界：哪些接口可以暴露、控制流与数据流如何隔离、状态保存在哪里，以及某一层防护失效后还有什么机制可以阻止横向移动。面向生产环境，架构应围绕隔离、托管服务和分层安全做明确取舍。
先拆开控制流与数据流
EDC 连接器通常同时承载协商、策略执行、资产管理和数据传输等职责。生产架构不宜把所有能力塞进一个拥有广泛权限的运行单元。可以按职责拆成两类工作负载：
- 控制平面处理目录、合同协商、策略与传输编排，只开放必要的协议和管理接口。
- 数据平面执行实际的数据读取与传输，只获得访问指定数据源和目标端的权限。
这种拆分的价值不只是扩缩容。控制平面保存业务协议状态，而数据平面接触真实数据；两者的攻击面、资源消耗和 IAM 权限并不相同。数据平面发生流量突增时，可以独立扩容，也不必把控制平面的数据库凭证交给每个传输实例。
在 AWS 上可以这样实践：将两类工作负载部署到不同的 EKS Namespace、节点组或 ECS Service，并分别绑定 IAM Role。对隔离要求更高的场景，可以进一步使用独立 AWS 账户或 VPC，但这会增加网络、可观测性和发布流程的复杂度。
托管服务不是替代架构，而是缩小运维面
生产连接器通常需要持久化状态、保存密钥并访问对象或关系型数据。一个可落地的 AWS 组合可以包括：
- 使用 Amazon RDS for PostgreSQL 保存需要持久化的连接器状态，并启用多可用区、备份和静态加密。
- 使用 AWS Secrets Manager 保存数据库口令、OAuth 客户端密钥等敏感配置。
- 使用 AWS KMS 管理加密密钥，并通过独立密钥策略限制管理者与使用者。
- 使用 Amazon S3 承载适合对象存储的数据资产，通过 bucket policy 和 IAM 限制数据平面只能访问指定前缀。
- 使用 CloudWatch、OpenTelemetry 或现有监控平台收集日志、指标和追踪，但避免记录令牌、合同敏感字段和数据内容。
需要注意，采用托管服务并不会自动形成最小权限。RDS 如果允许整个 VPC 访问、S3 权限写成 s3:*，或者多个连接器共用同一个 Secrets Manager 密钥，隔离仍然只是表面上的。
用多层控制收窄每条访问路径
分层安全应覆盖入口、工作负载、网络、身份和数据，而不是只在公网入口放一个负载均衡器。
入口层可以通过 ALB、WAF、TLS 和访问日志保护公开协议端点；管理 API 则应放在私有网络中，通过 VPN、专线或受控运维入口访问。工作负载层使用非 root 容器、只读根文件系统和镜像扫描。身份层应让 Pod 或 Task 通过短期凭证访问 AWS 服务，避免把长期 Access Key 写入环境变量。
网络层需要同时考虑 Kubernetes NetworkPolicy、安全组和子网路由。它们解决的问题不同：NetworkPolicy 控制 Pod 间通信，安全组控制 ENI 或服务边界，私有子网与路由表决定流量是否能够直接到达互联网。
下面是一个可改造的 EKS 示例。它为控制平面建立默认拒绝规则，只允许入口命名空间访问协议端口，并允许数据平面访问内部编排端口。运行前需要把 Namespace、标签和端口替换为实际部署值，并确认集群网络插件支持 NetworkPolicy。
apiVersion: v1
kind: Namespace
metadata:
name: edc
labels:
purpose: edc
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: control-plane-default-deny
namespace: edc
spec:
podSelector:
matchLabels:
app: edc-control-plane
policyTypes:
- Ingress
ingress: []
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: control-plane-allowed-callers
namespace: edc
spec:
podSelector:
matchLabels:
app: edc-control-plane
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: ingress-system
ports:
- protocol: TCP
port: 8080
- from:
- podSelector:
matchLabels:
app: edc-data-plane
ports:
- protocol: TCP
port: 8181
保存为 edc-network-policy.yaml 后可以执行：
kubectl apply -f edc-network-policy.yaml
kubectl -n edc get networkpolicy
kubectl -n edc describe networkpolicy control-plane-allowed-callers
这段配置只演示入站隔离。生产环境还应设计出站白名单，并验证 DNS、RDS、S3、身份令牌端点和可观测性出口。直接启用默认拒绝出站规则可能中断名称解析或凭证获取，因此应先在预生产环境记录真实依赖，再逐项放行。
把 AWS 身份绑定到单个组件
如果运行在 EKS 上，可以使用面向 ServiceAccount 的 AWS 身份机制，让控制平面和数据平面获得不同角色。数据平面访问 S3 时，应把权限限制到具体 bucket 和前缀。下面是一份可改造的 IAM Policy；请替换账户中的 bucket 名称和数据路径。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListOnlyApprovedPrefix",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::partner-data-prod",
"Condition": {
"StringLike": {
"s3:prefix": ["exports/customer-a/*"]
}
}
},
{
"Sid": "ReadApprovedObjects",
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::partner-data-prod/exports/customer-a/*"
}
]
}
不要把这份策略附加到整个集群节点角色。应将它绑定到数据平面的专用角色，并让对应 ServiceAccount 使用该角色。这样即使控制平面容器被利用，攻击者也不能直接继承读取数据资产的权限。
上线前检查架构是否真的隔离
生产评审可以围绕几条具体问题展开：公开入口是否只有协议必需端点；管理 API 是否保持私有；控制平面与数据平面是否使用不同身份；数据库、对象存储和密钥权限是否限制到单个连接器；网络规则是否经过连通性测试；日志是否会泄露令牌或业务数据；备份能否恢复；密钥和证书是否有轮换流程。
更强的隔离通常意味着更多账户、VPC、角色和部署流水线。不要一开始就追求最复杂的拓扑，而应根据数据敏感度、合作方数量和故障影响范围选择边界。最低要求是让每条访问路径都有明确所有者、最小权限和可审计记录，并确保任意一层失效时，下一层仍能限制影响范围。