使用AWS Workload Credentials Provider在EKS中管理应用密钥的实践

本文档完整记录了在中国区 EKS 集群上部署 AWS Workload Credentials Provider 的全过程。通过 Sidecar 模式，应用可以无感知地获取 AWS Secrets Manager 中的敏感配置，无需在代码中处理复杂的 AWS 认证逻辑。

在 Kubernetes 中管理 Secret 始终是个让人头疼的问题。传统的工作流中，每个开发团队都要自己实现一套从 AWS 获取 Secret 的逻辑——有的用 SDK，有的用 init container，有的干脆写死在配置文件里。这不仅重复造轮子，还带来了严重的安全隐患。

AWS Workload Credentials Provider（WCP）的出现改变了这一切。作为 AWS Secrets Manager Agent 的演进版本，它采用了 Sidecar 代理模式——你在 Pod 中描述想要的 Secret，WCP 负责获取、缓存和提供。

在我们的实践中，整个系统体现了优雅的分层思想。这种分层设计让每个组件职责单一，便于独立演进和故障隔离。具体来说，我们将整个架构划分为四个层次：

系统分层架构

一个典型的 Pod 包含两个容器协同工作：

• Agent 容器（业务应用）：运行 LLM 代理服务，通过 localhost 访问 Secret
• WCP 容器（Sidecar）：提供本地 HTTP 服务，缓存来自 Secrets Manager 的 API Key

WCP 网络架构与通信模型

在深入部署之前，理解 WCP 的通信模型至关重要。WCP 的设计哲学是将 Secret 管理下沉到基础设施层，让应用容器无感知地使用。下图展示了 Pod 内部的网络拓扑

通信时序（Agent 调用 LLM 的完整流程）

在整个通信过程中，WCP 的性能表现是我们最关心的指标。基于实际测试，我们收集了以下关键性能数据：

在决定使用 Sidecar 模式之前，我们对比了三种不同的部署方案。每种方案都有其特定的适用场景和权衡。建议生产环境使用 Sidecar 模式。WCP 的设计初衷就是 per-Pod 代理，每个应用有自己的缓存实例，故障域隔离。

配置详解

以下是完整的 Dockerfile，包含了 Rust 依赖的中国区镜像加速配置：

#============================================================================== # Stage 1: Builder #============================================================================== FROM public.ecr.aws/docker/library/rust:1.92-bookworm AS builder # 配置中国镜像加速 (Rust crates) RUN mkdir -p /usr/local/cargo && \ echo '[source.crates-io]' > /usr/local/cargo/config.toml && \ echo 'replace-with = "rsproxy-sparse"' >> /usr/local/cargo/config.toml && \ echo '[source.rsproxy-sparse]' >> /usr/local/cargo/config.toml && \ echo 'registry = "sparse+https://rsproxy.cn/index/"' >> /usr/local/cargo/config.toml && \ echo '[net]' >> /usr/local/cargo/config.toml && \ echo 'git-fetch-with-cli = true' >> /usr/local/cargo/config.toml WORKDIR /src COPY . . RUN CARGO_HOME=/usr/local/cargo cargo build --release && \ cp /src/target/release/aws-workload-credentials-provider /aws-workload-credentials-provider #============================================================================== # Stage 2: Runtime #============================================================================== FROM public.ecr.aws/docker/library/debian:bookworm-slim RUN apt-get update && \ apt-get install -y --no-install-recommends ca-certificates && \ rm -rf /var/lib/apt/lists/* WORKDIR /app COPY --from=builder /aws-workload-credentials-provider /app/aws-workload-credentials-provider RUN chmod 0755 /app/aws-workload-credentials-provider ENTRYPOINT ["/app/aws-workload-credentials-provider"] CMD ["sm", "start", "--config", "/etc/wcp/config.toml"]

在这个 Dockerfile 中，有几个关键配置需要特别注意：

ConfigMap

WCP 采用 TOML 格式配置。核心参数说明：

apiVersion:v1kind:ConfigMapmetadata:name:wcp-confignamespace:<namespace>data:config.toml:|[logging] log_level = "INFO" log_to_file = false[capabilities.secrets_manager]enabled = true http_port = 2773 region = "<region>" max_conn = 800[capabilities.secrets_manager.cache]ttl_seconds = 300 cache_size = 1000[capabilities.secrets_manager.security]ssrf_headers =["X-Aws-Parameters-Secrets-Token"]ssrf_env_variables =["AWS_TOKEN"][capabilities.secrets_manager.prefetch]cache_buffer_ratio = 0.8 max_jitter_seconds = 5[[capabilities.secrets_manager.prefetch.secrets]]secret_id = "llm/api/config"

Deployment

Sidecar 模式 Deployment 关键配置：

apiVersion:apps/v1kind:Deploymentmetadata:name:agent-appnamespace:<namespace>spec:replicas:1template:spec:serviceAccountName:wcp-app-sacontainers:-name:agentimage:<account-id>.dkr.ecr.<region>.amazonaws.com.cn/agent-app:latestports:-containerPort:8080env:-name:WCP_HOSTvalue:"localhost"-name:WCP_PORTvalue:"2773"-name:WCP_TOKENvalue:"<namespace>-token-12345"-name:SECRET_NAMEvalue:"llm/api/config"readinessProbe:httpGet:path:/healthport:8080-name:wcp-providerimage:<account-id>.dkr.ecr.<region>.amazonaws.com.cn/wcp:latestargs:-sm-start---config-/etc/wcp/config.tomlenv:-name:AWS_REGIONvalue:<region>-name:AWS_TOKENvalue:"<namespace>-token-12345"volumeMounts:-name:wcp-configmountPath:/etc/wcpreadOnly:true-name:wcp-tmpmountPath:/tmpvolumes:-name:wcp-configconfigMap:name:wcp-config-name:wcp-tmpemptyDir:medium:Memory

Agent 应用代码

Agent 应用通过localhost:2773访问 WCP 获取 Secret，必须携带 SSRF Token：

funcgetEnv(key,defaultValuestring)string{ifvalue:=os.Getenv(key);value!=""{returnvalue}returndefaultValue}funcgetSecretFromWCP()(*LLMConfig,error){url:=fmt.Sprintf("http://%s:%s/secretsmanager/get?secretId=%s",getEnv("WCP_HOST","localhost"),getEnv("WCP_PORT","2773"),getEnv("SECRET_NAME","llm/api/config"))req,_:=http.NewRequest("GET",url,nil)req.Header.Set("X-Aws-Parameters-Secrets-Token",getEnv("WCP_TOKEN",""))client:=&http.Client{Timeout:10*time.Second}resp,err:=client.Do(req)iferr!=nil{returnnil,err}deferresp.Body.Close()varresultstruct{SecretStringstring`json:"SecretString"`}json.NewDecoder(resp.Body).Decode(&result)varllmConfig LLMConfig json.Unmarshal([]byte(result.SecretString),&llmConfig)return&llmConfig,nil}

测试验证

Pod 状态检查：

$ kubectl get pods-n<namespace>-owide NAME READY STATUS RESTARTS AGE agent-app-748ddb77d5-mwbms2/2 Running05m

WCP 日志确认预取成功：

2026-06-28T11:18:40.818Z INFO - listening on http://127.0.0.1:2773 2026-06-28T11:18:45.728Z INFO - Pre-fetch complete: success=2, failed=0

Health 检查：

$ kubectlexec-n<namespace>deployment/agent-app-cagent --\curl-shttp://localhost:8080/health{"status":"healthy"}

Chat 对话测试：

$ kubectlexec-n<namespace>deployment/agent-app-cagent --\curl-s-XPOST http://localhost:8080/chat\-H"Content-Type: application/json"\-d'{"message":"你好"}'

响应示例：

{"model":"GLM-5.2","response":"我是GLM，由Z.ai开发的大语言模型..."}

整个方案的核心价值在于：让应用专注于业务逻辑，将 Secret 管理交给基础设施。WCP 的本地缓存机制将 Secret 获取延迟从 50-100ms 降至 1ms，同时 SSRF 防护确保了即使在高风险场景下也能安全地提供 Secret 服务。

最后需要说明的是，本文档只展示了 WCP 的 Secrets Manager 能力。实际上 WCP 还支持ACM 证书导出功能——它可以自动从 AWS Certificate Manager 导出 SSL/TLS 证书到本地文件系统，并支持证书到期自动刷新和自定义刷新命令。如果你的应用需要管理 HTTPS 证书，WCP 同样可以通过 Sidecar 或系统服务的方式提供自动化的证书管理。