SYSTEM Cited by 4 sources
AWS Secrets Manager¶
What it is¶
AWS Secrets Manager is AWS's managed service for storing, retrieving, and rotating secrets — API keys, database passwords, third-party credentials, and (in the sovereign-failover context) IAM user access keys. Supports Lambda-backed custom rotation.
Role in cross-partition IAM-user fallback¶
The sovereign-failover post names Secrets Manager as the recommended storage tier when IAM users must be used across partitions instead of federated identity:
"If IAM users are still used, credentials can be stored in AWS Secrets Manager, rotated using Lambda, and a backup user can improve availability." (Source: sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty)
Three moving parts of the fallback pattern:
- Secrets Manager holds the long-lived IAM user credential.
- A Lambda function performs rotation on schedule.
- A backup user (a second IAM user on the same rotation schedule) provides availability during rotation failures.
This is explicitly the fallback path — federation from a centralized IdP is the recommended primary architecture.
Role as source-of-record behind External Secrets Operator on EKS¶
The Generali Malaysia case study documents the idiomatic shape for
using Secrets Manager inside a Kubernetes cluster: pair it with
External Secrets Operator (ESO)
and consume the resulting K8s Secret objects as environment
variables (not volume mounts). Flow:
- Secret values live in AWS Secrets Manager (source of truth; rotated centrally by Secrets Manager's own rotation lambdas).
- ESO controller reads Secrets Manager on a recurring schedule.
- ESO writes a native K8s
Secretobject into the target namespace. - Pods consume it via
envFrom: secretRef:— env vars, no volume mounts, no daemonset.
This is the canonical pattern on stateless-only EKS clusters where volume mounts are structurally avoided. The alternative CSI-driver path adds a daemonset and requires a volume mount per pod — materially worse fit for stateless-only discipline. See systems/external-secrets-operator for the consumer-side detail.
"[Generali] implemented the External Secrets Operator on their EKS cluster to use Secrets Manager for centralized secret management, which reads the necessary secrets and automatically stores them as Kubernetes secrets without requiring application code changes or daemonsets." (Source: sources/2026-03-23-aws-generali-malaysia-eks-auto-mode)
Stub page¶
Seen in¶
- sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty — Secrets Manager named as the credential-storage substrate for the IAM-user-with-Lambda-rotation fallback pattern.
- sources/2026-03-23-aws-generali-malaysia-eks-auto-mode —
Secrets Manager as the source-of-record behind
External Secrets Operator
on Generali's EKS cluster: secrets sync into K8s
Secretobjects and pods consume them as env vars, no volume mounts required. Canonical K8s-native secret-store pattern. - sources/2026-04-08-aws-build-a-multi-tenant-configuration-system-with-tagged-storage-patterns
— named as the future extension backend for a
secret_config_*prefix in a tagged-storage-routing config service — "adding a new storage backend requires only: creating a new strategy class implementing the ConfigStrategy interface, adding one line to the keyStrategyMap with the new prefix and strategy". Positions Secrets Manager as the right backend for credentials / PII / rotated-secrets that require a stronger confidentiality shape than Parameter Store SecureString alone.
Related¶
- systems/aws-iam, systems/aws-lambda
- systems/external-secrets-operator — the K8s operator that pulls secrets into a cluster as native Secret objects.
- systems/aws-eks — common consumer platform via ESO.
- concepts/cross-partition-authentication
- patterns/centralized-identity-federation — the recommended alternative