Secrets Manager Agent now works in EKS sidecars

Finally, a cleaner way to handle secrets in Kubernetes.

The AWS Secrets Manager Agent runs as a sidecar in your EKS pods, giving your apps HTTP access to secrets without needing language-specific SDKs. Just call localhost:2773.

What makes this different:

• No SDK overhead — Works across Python, Go, Java, Node, whatever. One HTTP endpoint.

• Local caching — Secrets stay in memory. Faster retrieval, fewer API calls to Secrets Manager.

• SSRF protection — Agent generates random tokens. Blocks unauthorized requests automatically.

• Post-quantum crypto — ML-KEM key exchange is on by default. No config needed.

• Pod Identity integration — No OIDC provider headaches. IAM roles attach directly to service accounts.

The sidecar pattern gives you isolation and granular security boundaries. Each pod gets its own agent instance. Perfect for apps needing runtime secret access and dynamic refresh without pod restarts.

Compare it to the CSI Driver approach: use the Agent for HTTP-based access and immediate refresh control. Use CSI Driver when you need file-mounted secrets and Kubernetes-native management.

The workflow is straightforward: app hits the agent, agent checks cache, if missing it authenticates via Pod Identity, grabs the secret from Secrets Manager, caches it, returns it. Done.

This hits a real pain point in Kubernetes secret management. No more baking credentials into code or wrestling with complex rotation logic across dozens of pods. Just HTTP calls to a local endpoint.