RFC-SECOPS-0001
                                                            Category: Standards Track
                                                            Status: Draft
                                                            Platform Engineering
                                                            January 2026

A GitOps-Native, Vault-First Secret Management Architecture

Status of This Memo

This document specifies a standards-track architecture for 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.

Abstract

This Request for Comments (RFC) defines a comprehensive, GitOps-native, Vault-first architecture for secret management in Kubernetes-based platforms. The architecture addresses the fundamental challenges of secret lifecycle management, including bootstrap, authority transitions, rotation, and recovery. This specification establishes a phase-driven model where secrets progress through well-defined stages with explicit authority boundaries, eliminating human-in-the-loop operations for steady-state secret handling.

The system treats secrets as first-class platform resources with defined ownership, lifecycle stages, and documented relationships to consuming systems. Git serves as the source of intent (not runtime values), while a dedicated runtime secret authority manages the actual secret lifecycle including rotation, expiry, and access control.

Copyright Notice

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

Document Information

Changelog

Intended Audience

This document is written for:

• Platform & Infrastructure Engineers
• Cloud / Kubernetes / GitOps Architects
• Security & Compliance Reviewers
• Broader Engineering Organization
• Open-source contributors and external auditors

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 The Initial System (Pre-Architecture State)
   • 1.3 Operational Shortcomings
   • 1.4 The Cost of Script-Driven Secret Management
   • 1.5 Why Incremental Fixes Failed
   • 1.6 Why a Dedicated Secrets Platform Became Necessary

2. Requirements and Invariants

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

Part 2: Architecture

3. System Architecture

   • 3.1 Architectural Overview
   • 3.2 Phase Model
   • 3.3 Authority and Trust Boundaries
   • 3.4 High-Level Control Flow
   • 3.5 Failure Domains and Recovery

4. System Components

   • 4.1 Component Taxonomy
   • 4.2 Control Planes vs Data Planes
   • 4.3 Responsibility Boundaries
   • 4.4 Component Interaction Model
   • 4.5 Phase-to-Component Mapping
   • 4.6 Failure and Recovery Scenarios

5. Operational Mechanics

   • 5.1 Terminology and Resource Types
   • 5.2 Bootstrap Mechanics (Pre-Vault)
   • 5.3 Runtime Authority Initialization
   • 5.4 Explicit Authority Handover
   • 5.5 Steady-State Secret Lifecycle
   • 5.6 Rotation and Expiry Handling
   • 5.7 Failure Modes and Recovery
   • 5.8 Security and Trust Guarantees

5a. Internal Distribution Mechanics (v1.1)

• 5a.1 Scope and Applicability
• 5a.2 Internal Secret Classification
• 5a.3 Distribution Framework
• 5a.4 Decision Framework
• 5a.5 Vault Path Conventions
• 5a.6 Component Roles
• 5a.7 Prerequisites and Dependencies
• 5a.8 Integration Points

Part 3: Operations

6. Rotation Framework

   • 6.1 Rotation as a System Property
   • 6.2 Rotation Principles and Invariants
   • 6.3 Rotation Policy Model
   • 6.4 Orchestration Responsibilities
   • 6.5 Event Sources and Triggers
   • 6.6 End-to-End Rotation Flows
   • 6.7 Observability and Auditability
   • 6.8 Failure Modes and Recovery

7. Security Considerations

   • 7.1 Security Objectives
   • 7.2 Trust Model and Root of Trust
   • 7.3 Trust Boundaries
   • 7.4 Identity and Authentication Model
   • 7.5 Authorization and Access Control
   • 7.6 Threat Model
   • 7.7 Blast Radius Analysis
   • 7.8 Compromise Scenarios and Recovery
   • 7.9 Security Guarantees and Limitations

Part 4: Rationale and Evolution

8. Design Rationale

   • 8.1 Why This Section Exists
   • 8.2 Sealed Secrets–First Architectures
   • 8.3 argocd-vault-plugin–Centric Designs
   • 8.4 CI/CD–Driven Secret Injection
   • 8.5 GitHub Environments as Source of Truth
   • 8.6 "Just Use Vault" (No GitOps Bootstrap)
   • 8.7 Kubernetes Secrets as the Authority
   • 8.8 Bash-Driven Orchestration
   • 8.9 Why Incremental Improvements Were Insufficient

9. Future Considerations

   • 9.1 Design for Change
   • 9.2 Multi-Cluster Expansion
   • 9.3 Multi-Environment Support
   • 9.4 Ephemeral and Preview Environments
   • 9.5 Hybrid and Cloud-Adaptive Deployments
   • 9.6 What Does Not Need to Change
   • 9.7 Anticipated Trade-offs and Limits

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 → Mechanics → Security

Understanding Design Decisions? Read Requirements → Rationale → Evolution

Implementing Cross-Namespace Secret Distribution? (v1.1) Start with Internal Distribution → Components → Mechanics

RFC-SECOPS-0001 — Index