3. System Architecture
3.1 Architectural Overview
The interim secret management architecture consists of three layers connected by two trust boundaries:
- Secret Store Layer — AWS Secrets Manager, a managed cloud service that stores, encrypts, and serves secret values.
- Access Layer — AWS IAM credentials that authenticate on-premises servers to AWS Secrets Manager.
- Consumption Layer — Application code that retrieves secrets via the AWS SDK through a centralized configuration module.
A fourth, supporting layer provides visibility:
- Inventory Layer — A Git-tracked
secrets-inventory.yamlmanifest that records all secret metadata without values.
The architecture is intentionally simple. Complexity is deferred to RFC-SECOPS-0001, which introduces Vault, ESO, GitOps, and Kubernetes as the permanent operational infrastructure.
3.2 Authority Domains
The interim architecture has two authority domains:
| Domain | Authority | Scope |
|---|---|---|
| Secret Values | AWS Secrets Manager | Storage, encryption, versioning of secret values |
| Secret Metadata | Git (secrets-inventory.yaml) | Names, descriptions, consumers, rotation status |
3.2.1 Secret Value Authority
AWS Secrets Manager is the sole runtime authority for secret values (Invariant 1). All applications retrieve secrets from this single source.
AWS Secrets Manager provides:
- built-in encryption at rest (AWS KMS-managed keys or customer-managed keys),
- versioning of secret values,
- fine-grained IAM-based access control,
- and regional availability within the configured AWS region.
3.2.2 Secret Metadata Authority
Git is the authority for secret metadata. The secrets-inventory.yaml
manifest tracks:
- secret names (matching AWS Secrets Manager secret names),
- human-readable descriptions,
- consuming applications,
- rotation status and notes,
- and the RFC-SECOPS-0001 path convention category.
Git does not store secret values (Invariant 3).
3.3 Trust Boundaries
The architecture has two trust boundaries:
Trust Boundary 1 — Server to AWS
| Aspect | Description |
|---|---|
| Crossing Point | IAM credential presentation from on-premises server to AWS |
| Authentication | IAM user credentials (access key ID + secret access key) or IAM role assumption |
| Transport | HTTPS with TLS 1.2+ |
| Risk | Credential compromise grants access to all secrets the security principal can read |
| Mitigation | Least-privilege IAM policies scoped to specific Secrets Manager secret ARNs |
On-premises servers do not have native AWS identity (unlike EC2 instances with instance profiles or EKS pods with IRSA). Authentication MUST use either:
- IAM user access keys (access key ID + secret access key) stored securely on the server (less preferred due to long-lived credentials), or
- IAM role assumption (preferred where feasible, e.g., IAM Roles Anywhere for on-premises servers).
Trust Boundary 2 — IAM to Secrets Manager
| Aspect | Description |
|---|---|
| Crossing Point | IAM authorization evaluation for Secrets Manager API calls |
| Authorization | IAM policy attachments or Secrets Manager resource policies attached to the authenticating principal |
| Scope | Policies SHOULD restrict access to specific Secrets Manager secret ARNs or name prefixes |
| Risk | Overly broad policies grant access to unrelated secrets |
| Mitigation | Per-application IAM principals with policies scoped to platform-data/{datasource}/{consumer} name patterns |
3.4 Data Flow
3.4.1 Secret Population Flow
Secret population is a manual, operator-driven process:
- An operator creates or updates a secret in AWS Secrets Manager using the AWS Console or AWS CLI.
- The operator updates the
secrets-inventory.yamlmanifest in Git to reflect the new or modified secret. - The manifest commit serves as the audit record for the population event.
3.4.2 Secret Consumption Flow
Secret consumption is an application-driven process at startup or configuration reload:
- The application requests a secret by its conventional name
(e.g.,
platform-data/postgres/my-app). - The centralized secret configuration module calls the AWS SDK.
- The SDK authenticates with AWS IAM and retrieves the secret.
- The secret value is returned to the application in memory.
3.5 Failure Domains and Recovery
3.5.1 AWS Secrets Manager Unavailability
| Aspect | Description |
|---|---|
| Failure Mode | AWS Secrets Manager API returns errors or is unreachable |
| Impact | Applications cannot retrieve secrets at startup or reload |
| Blast Radius | All applications dependent on the affected AWS region |
| Detection | SDK error responses, application startup failures |
| Recovery | Wait for AWS service restoration; applications retain in-memory secrets until restart |
3.5.2 IAM Credential Compromise
| Aspect | Description |
|---|---|
| Failure Mode | IAM credentials (access key ID + secret access key) are leaked or stolen |
| Impact | Unauthorized access to secrets within the compromised IAM principal's policy scope |
| Blast Radius | Limited to secrets accessible by the compromised IAM principal |
| Detection | AWS CloudTrail logs, anomalous access patterns |
| Recovery | Rotate compromised IAM credentials, rotate all secrets accessible to the compromised principal |
3.5.3 Secret Inventory Drift
| Aspect | Description |
|---|---|
| Failure Mode | secrets-inventory.yaml does not match actual AWS Secrets Manager contents |
| Impact | Reduced visibility into platform secret state |
| Blast Radius | Operational awareness only; applications are unaffected |
| Detection | Periodic reconciliation between manifest and Secrets Manager |
| Recovery | Update secrets-inventory.yaml to match actual state |