2. Requirements and Invariants

RFC-SECOPS-0002                                                   Section 2
Category: Standards Track                        Requirements and Invariants

This section defines the constraints and invariants that shape all subsequent architectural decisions. No design presented in later sections MAY violate the principles established here.

2.1 Core Problem Restatement

The platform REQUIRES an interim secrets management system that:

• centralizes all application secrets in a single managed store,
• replaces scattered .env files and environment variable injection,
• operates on on-premises infrastructure without Kubernetes,
• establishes naming conventions compatible with the future Vault-first architecture (RFC-SECOPS-0001),
• and remains simple enough to operate without dedicated secret management infrastructure.

The system MUST work under the assumption that:

• the target infrastructure (Kubernetes, Vault, ESO) is not yet available,
• the timeline for that infrastructure is uncertain,
• and the interim solution MUST NOT introduce coupling that impedes future migration.

2.2 Design Goals

2.2.1 Centralized Secret Storage

All platform secrets MUST reside in a single, managed secret store (AWS Secrets Manager). No application secret MAY remain solely in local files, environment variables, or operator memory as its authoritative source.

2.2.2 Documented Secret Inventory

A Git-tracked manifest (secrets-inventory.yaml) MUST enumerate all secrets stored in AWS Secrets Manager. The manifest contains metadata only (names, descriptions, consumers, rotation status) and MUST NOT contain secret values.

2.2.3 Naming Convention Alignment

Secret names in AWS Secrets Manager MUST follow the structural pattern defined in RFC-SECOPS-0001 Section 5a.5. AWS Secrets Manager supports the / path separator used in Vault, so the naming convention is identical to the Vault path schema:

The structural segments (platform-data, datasource, consumer) are identical to the Vault path schema and use the same / separator. This alignment ensures that the transition from AWS Secrets Manager to Vault requires no naming remapping or restructuring of application logic or the secret inventory.

2.2.4 Minimal Operational Scope

The interim architecture addresses secret storage and consumption only. It explicitly defers all other concerns to RFC-SECOPS-0001:

2.2.5 Migration Readiness

Every design decision in this architecture MUST be evaluated against the question: Does this make migration to RFC-SECOPS-0001 harder or easier?

Decisions that create tight coupling to AWS Secrets Manager or the AWS SDK beyond what is strictly necessary for interim operation MUST be avoided.

2.3 Non-Goals

The following are explicitly out of scope for this architecture:

2.3.1 Automated Secret Rotation

This architecture does not automate rotation. Secrets are rotated manually when required. The risk is accepted as a trade-off for simplicity and speed of deployment.

2.3.2 Audit Logging and Compliance

This architecture does not define audit logging requirements. AWS CloudTrail provides access logs for AWS Secrets Manager operations, but this RFC does not mandate, configure, or depend on it.

2.3.3 Cross-Service Secret Distribution

This architecture does not define mechanisms for distributing secrets between services or namespaces. Each application retrieves its own secrets directly from AWS Secrets Manager via the SDK.

2.3.4 Policy Enforcement Beyond AWS IAM Policies

Access control is limited to AWS IAM policy attachments and Secrets Manager resource-based policies. Fine-grained application-level secret access policies are deferred to the Vault policy system defined in RFC-SECOPS-0001.

2.3.5 Kubernetes Integration

This architecture does not address Kubernetes Secrets, ExternalSecret resources, SecretStore configuration, or any Kubernetes-native secret management. Kubernetes is not yet available.

2.4 Architectural Invariants

The following rules are non-negotiable invariants. Violating any of these invalidates the interim design.

Invariant 1 — AWS Secrets Manager Is the Sole Secret Store

All application secrets MUST be stored in AWS Secrets Manager.

No application MAY treat local .env files, environment variables, configuration files, or external dashboards as the authoritative source for any secret.

Local copies of secrets (e.g., in application memory at runtime) are transient and derived. The authoritative version always resides in AWS Secrets Manager.

This invariant ensures centralized management and a single source of truth during the interim period.

Invariant 2 — Naming Conventions MUST Align with RFC-SECOPS-0001

Secret names in AWS Secrets Manager MUST follow the platform-data/ and platform-config/ prefix conventions, using / as the segment separator, structurally aligned with the Vault path schema defined in RFC-SECOPS-0001 Section 5a.5. AWS Secrets Manager supports / in secret names, so the naming convention is identical to Vault from the interim period onward.

Deviation from these conventions creates migration debt and naming conflicts during the transition to Vault.

Invariant 3 — Secret Values MUST NOT Exist in Git

Git MUST contain only secret metadata (names, descriptions, consumers, rotation notes). Secret values MUST NOT appear in Git repositories under any circumstances.

This invariant is shared with RFC-SECOPS-0001 (Invariant 1) and ensures that no secret value leaks through version control history.

Invariant 4 — SDK Access MUST Be Centralized Per Application

Each application MUST access AWS Secrets Manager through a single, centralized configuration module. AWS SDK calls MUST NOT be scattered throughout application code.

This invariant limits the blast radius of the SDK-to-ESO migration. When the target architecture becomes available, only the centralized module requires replacement, not every file that consumes a secret.

Invariant 5 — The Interim Architecture Is Temporary

This architecture MUST be treated as temporary. No design decision MAY assume permanent reliance on AWS Secrets Manager or the AWS SDK for secret consumption.

All components, naming schemes, and operational procedures MUST be designed with explicit awareness that they are superseded by RFC-SECOPS-0001.

2.5 Success Criteria

This interim architecture is considered successful if:

• All platform secrets reside in AWS Secrets Manager with no authoritative copies in .env files or operator memory.
• A Git-tracked inventory manifest accurately reflects all stored secrets.
• Secret names follow the platform-data/ and platform-config/ naming conventions, structurally aligned with RFC-SECOPS-0001.
• Each application accesses secrets through a single centralized module.
• Migration to the target architecture (RFC-SECOPS-0001) requires changes only to the centralized secret access module per application, not widespread code modifications.