1. Introduction and Motivation

RFC-SECOPS-0002                                                   Section 1
Category: Standards Track                                     Introduction

1.1 Background and Context

The platform operates on on-premises infrastructure. Applications run as processes within virtual machines, without container orchestration, Kubernetes, or a GitOps delivery pipeline.

The target secret management architecture, defined in RFC-SECOPS-0001, specifies a comprehensive, GitOps-native, Vault-first system. That architecture depends on several infrastructure prerequisites:

None of these prerequisites are operational. Their deployment timeline is uncertain.

Meanwhile, the platform requires a functional secret management system. Secrets exist today, applications consume them, and operational needs persist regardless of infrastructure readiness.

This RFC defines a pragmatic interim architecture that addresses immediate needs while maintaining compatibility with the future Vault-first system.

1.2 Current State (Pre-Architecture)

Prior to this architecture, secrets are managed through informal, operator-dependent mechanisms:

• Environment variables embedded in application process configuration.
• .env files stored on virtual machine filesystems.
• Manual credential creation in external service dashboards (cloud provider consoles, SaaS administration panels).
• Ad-hoc documentation of credentials in internal slack channels.

This approach has the following characteristics:

1.2.1 No Central Inventory

There is no authoritative answer to:

• What secrets exist across the platform?
• Which applications depend on which credentials?
• When credentials expire or require rotation?
• Who created a given secret and for what purpose?

1.2.2 Scattered Storage

Secrets reside in multiple locations simultaneously:

No single system tracks all secrets, and no mechanism enforces consistency between copies.

1.2.3 Manual Lifecycle

Secret creation, distribution, rotation, and deletion are entirely manual processes. Every lifecycle event depends on human memory and discipline. There is no automation, no notification of expiry, and no enforcement of rotation schedules.

1.3 Why an Interim Solution Is Necessary

The target architecture (RFC-SECOPS-0001) addresses all of the shortcomings described in Section 1.2. However, it requires infrastructure that does not yet exist.

Waiting for the target infrastructure is not a viable strategy because:

• Secrets exist now. Applications are running in production with credentials that require management.
• Risk has materialized. Recent operational security events involving unauthorized access to infrastructure and data stores have demonstrated the concrete consequences of the current decentralized approach. Every additional day without centralized secret management and audit trails increases exposure to credential-related incidents (expiry, leakage, inconsistency).
• Migration requires a starting point. When the target infrastructure becomes available, migrating from a centralized secret store is significantly simpler than migrating from scattered .env files across dozens of virtual machines.

The interim architecture exists to:

1. Centralize all secrets in a single, managed secret store.
2. Eliminate local .env files and scattered credentials as the primary storage mechanism.
3. Establish naming conventions that align with the future Vault path schema defined in RFC-SECOPS-0001 Section 5a.5.
4. Provide a documented inventory of all platform secrets.
5. Create a migration-ready foundation for the eventual transition to Vault.

1.4 Relationship to RFC-SECOPS-0001

This RFC is explicitly designed to be superseded by RFC-SECOPS-0001.

The naming convention is intentionally aligned. Secrets created under this interim architecture follow the same structural pattern as the Vault paths defined in RFC-SECOPS-0001: a platform-data/ or platform-config/ prefix, followed by the datasource and consumer identifiers separated by /. AWS Secrets Manager supports / as a path separator, so the naming convention is identical to Vault from the outset, eliminating separator remapping during migration.

When RFC-SECOPS-0001 is implemented, this RFC transitions to Superseded status and the interim architecture is retired according to the migration plan defined in Section 5.