An Interim Secret Management Architecture Using AWS Secrets Manager

Authors

Prathik Shetty

Shaik Noorullah Shareef

                                                            RFC-SECOPS-0002
                                                            Category: Standards Track
                                                            Status: Draft
                                                            Platform Engineering
                                                            February 2026

Status of This Memo

This document specifies a standards-track architecture for interim secret management within the platform infrastructure. Distribution of this memo is unlimited within the organization and to authorized external reviewers.

This document is a DRAFT and is subject to change based on review feedback.

This RFC describes a temporary architecture that is explicitly designed to be superseded by RFC-SECOPS-0001 once the prerequisite infrastructure (Kubernetes, HashiCorp Vault, External Secrets Operator, ArgoCD) is operational.

Abstract

This Request for Comments (RFC) defines an interim secret management architecture for platform applications running on on-premises infrastructure. The architecture uses AWS Secrets Manager as a centralized, cloud-hosted secret store accessed directly via the AWS SDK from application code.

This architecture exists because the target secret management system defined in RFC-SECOPS-0001 depends on infrastructure prerequisites that are not yet available: Kubernetes clusters, HashiCorp Vault, External Secrets Operator, and a GitOps delivery pipeline. Until those prerequisites are operational, the platform requires a pragmatic interim solution that centralizes secrets, eliminates scattered credential storage, and establishes naming conventions compatible with the future Vault-first architecture.

The interim architecture intentionally limits its scope to secret storage and consumption. It does not address automated rotation, audit logging, cross-namespace distribution, or policy enforcement. These capabilities are deferred to the target architecture defined in RFC-SECOPS-0001.

Copyright Notice

Copyright (c) 2026 ProficientNow Engineering. All rights reserved.

Changelog

Scope Boundaries

Intended Audience

This document is written for:

• Platform & Infrastructure Engineers
• Application Developers consuming secrets
• Security & Compliance Reviewers
• Broader Engineering Organization

No prior knowledge of the internal system is assumed.

Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Table of Contents

Part 1: Foundation

1. Introduction and Motivation

   • 1.1 Background and Context
   • 1.2 Current State (Pre-Architecture)
   • 1.3 Why an Interim Solution Is Necessary
   • 1.4 Relationship to RFC-SECOPS-0001

2. Requirements and Invariants

   • 2.1 Core Problem Restatement
   • 2.2 Design Goals
   • 2.3 Non-Goals
   • 2.4 Architectural Invariants
   • 2.5 Success Criteria

Part 2: Architecture

3. System Architecture

   • 3.1 Architectural Overview
   • 3.2 Authority Domains
   • 3.3 Trust Boundaries
   • 3.4 Data Flow
   • 3.5 Failure Domains and Recovery

4. System Components

   • 4.1 Component Taxonomy
   • 4.2 Component Responsibilities
   • 4.3 Component Interaction Model
   • 4.4 Failure and Recovery Scenarios

Part 3: Operations

5. Migration Path
   • 5.1 Migration Phases Overview
   • 5.2 Phase 0 — Current State (Secrets Manager + SDK)
   • 5.3 Phase 1 — Kubernetes Adoption (Secrets Manager + ESO)
   • 5.4 Phase 2 — Target State (Vault + ESO)
   • 5.5 Naming Convention Continuity
   • 5.6 Migration Risks

Part 4: Rationale and Evolution

6. Design Rationale

   • 6.1 Why This Section Exists
   • 6.2 HashiCorp Vault Without Prerequisites
   • 6.3 Environment Variables and .env Files
   • 6.4 Git-Encrypted Secrets (SOPS, Sealed Secrets)
   • 6.5 External Secrets Operator Without Kubernetes
   • 6.6 Cloud-Native Secret Stores With Abstraction Layers

7. Future Considerations

   • 7.1 Supersession by RFC-SECOPS-0001
   • 7.2 Interim Architecture Retirement Criteria
   • 7.3 Extension Points
   • 7.4 What Does Not Change on Supersession

Appendices

• Appendix A: Glossary and Indexes
• Appendix B: References

Quick Navigation

Reading Paths

New to the Platform? Start with Introduction → Requirements → Architecture

Security Review? Focus on Requirements → Architecture → Migration

Understanding Design Decisions? Read Requirements → Rationale → Evolution

Planning the Migration to Vault? Start with Migration → Evolution → RFC-SECOPS-0001