RFC-SECOPS-0001                                           Appendix A
Category: Standards Track                      Glossary and Indexes

Appendix A: Glossary and Indexes

← Previous: Evolution | Index | Next: References →

This appendix applies to Sections 1 through 9 of this RFC.

It introduces no new behavior. Its purpose is reference, traceability, and longevity.

A.1 Glossary of Terms

This glossary defines terms as used in this RFC, not in general industry usage.

Authority

A system that is the single source of truth for a given piece of data at a given phase. At no time MAY more than one authority exist for the same secret.

Bootstrap Secret

A temporary secret required to bring the system to a state where a runtime authority can exist.

Bootstrap secrets:

• exist before the runtime authority,
• MUST be encrypted in Git,
• MUST NOT be rotated automatically,
• and MUST be retired after handover.

Runtime Secret

A secret owned by the runtime authority after bootstrap.

Runtime secrets:

• are rotated automatically,
• MUST NOT be stored in Git,
• and are lifecycle-managed by the system.

Derived Secret

A secret generated by infrastructure or controllers (e.g., databases, storage systems) and pushed into the runtime authority.

Internal Secret (v1.1)

A secret generated by an operator or controller within the same Kubernetes cluster, requiring distribution to consumers in other namespaces.

Internal secrets:

• are generated within the cluster boundary,
• MUST traverse Vault via PushSecret/ExternalSecret pattern,
• are lifecycle-managed by the generating operator.

See Section 5a.

Internal Configuration (v1.1)

Non-sensitive configuration data (endpoints, ports, connection parameters) generated or managed within the cluster that requires cross-namespace distribution.

Internal configuration:

• MAY use the same PushSecret/ExternalSecret pattern as secrets,
• MUST use separate Vault paths (platform-config/ vs platform-data/),
• is NOT a security boundary.

See Section 5a.

PushSecret (v1.1)

A Kubernetes custom resource (external-secrets.io/v1alpha1) that watches a source Secret and syncs selected keys to the runtime authority (Vault).

PushSecret enables the publication phase of internal secret distribution.

See Section 5a.3.

Platform Data Path (v1.1)

The standardized Vault path prefix for internal secrets: platform-data/{datasource}/{consumer}.

See Section 5a.5.

Platform Config Path (v1.1)

The standardized Vault path prefix for internal configuration: platform-config/{datasource}/{instance}.

See Section 5a.5.

Secret Publication Layer (v1.1)

A data plane component responsible for watching source secrets in producer namespaces and pushing selected data to the runtime authority.

The publication layer bridges operator-generated secrets to the centralized authority without transferring ownership.

See Section 4.3.8.

Runtime Secret Authority

The system responsible for:

• storing secret values,
• enforcing access control,
• tracking metadata and expiry,
• and executing rotation.

Kubernetes is NEVER the runtime authority.

Materialized Secret

A Kubernetes Secret derived from the runtime authority and consumed by workloads.

Materialized secrets are:

• disposable,
• replaceable,
• never authoritative.

Handover

The explicit, one-time transfer of authority from bootstrap secrets to the runtime authority.

Handover MUST be:

• observable,
• auditable,
• idempotent.

Rotation

The controlled replacement of a secret value according to a policy.

Rotation is:

• runtime-owned,
• automated,
• independent of Git.

Control Plane

Any system that decides what SHOULD exist.

Examples:

• Git repository
• GitOps controller
• Orchestration engine

Data Plane

Any system that holds or serves actual values.

Examples:

• Runtime secret authority
• Kubernetes Secrets (materialized only)

Root of Trust

The minimal cryptographic material that anchors the entire system.

This exists outside Kubernetes and is established once.

A.2 Architecture Decision Record (ADR) Index

This index summarizes key architectural decisions, their rationale, and where they are defined.

ADR-001 — Secrets Are First-Class Resources

• Decision: Secrets MUST be explicitly modeled with lifecycle and ownership.
• Rationale: Implicit secrets do not scale or audit.
• Defined In: Section 2

ADR-002 — Git Is Source of Intent, Not Value

• Decision: Git defines existence and policy, not runtime values.
• Rationale: Rotation and TTL cannot be Git-driven.
• Defined In: Section 2, Section 6

ADR-003 — Vault-First, Kubernetes-Second

• Decision: Kubernetes consumes secrets; it MUST NOT own them.
• Rationale: Kubernetes lacks lifecycle semantics.
• Defined In: Section 2, Section 5

ADR-004 — Explicit Bootstrap Phase

• Decision: Bootstrap secrets are temporary and transitional.
• Rationale: The bootstrap paradox MUST be modeled explicitly.
• Defined In: Section 3, Section 5

ADR-005 — No Git Involvement in Rotation

• Decision: Rotation MUST NOT require Git commits.
• Rationale: Runtime behavior MUST be autonomous.
• Defined In: Section 6

ADR-006 — Orchestration Over Scripts

• Decision: All sequencing MUST be declarative and observable.
• Rationale: Scripts create hidden control planes.
• Defined In: Section 4, Section 6, Section 8

ADR-007 — Single Authority at Any Time

• Decision: Authority MUST be singular and explicit.
• Rationale: Dual authority creates ambiguity and failure.
• Defined In: Section 2, Section 5, Section 7

ADR-008 — Cluster Independence

• Decision: Each cluster is autonomous.
• Rationale: Limits blast radius and simplifies recovery.
• Defined In: Section 9

ADR-009 — Internal Secrets MUST Traverse Vault (v1.1)

• Decision: Cross-namespace internal secrets MUST use PushSecret → Vault → ExternalSecret.
• Rationale: Direct namespace copying violates single-authority principle and loses audit trail.
• Defined In: Section 2 (Invariant 7), Section 5a, Section 8.10

ADR-010 — Configuration MAY Use Same Distribution Path (v1.1)

• Decision: Non-sensitive configuration MAY use the same PushSecret/ExternalSecret pattern.
• Rationale: Centralizes discovery and management; NOT a security boundary.
• Defined In: Section 2 (Invariant 8), Section 5a

A.3 Diagram Index

This index lists all Mermaid diagrams in the RFC, with their purpose and location.

Architecture Diagrams

Operational Diagrams

Internal Distribution Diagrams (v1.1)

Rotation Diagrams

Security and Evolution Diagrams

A.4 Reading Paths

For New Platform Engineers

1. 1. Introduction
2. 2. Requirements
3. 3. Architecture
4. 4. Components
5. 5. Mechanics
6. 5a. Internal Distribution (v1.1)

For Security & Audit Review

1. 2. Requirements
2. 5. Mechanics
3. 6. Rotation
4. 7. Security

For Future Architects

1. 2. Requirements
2. 8. Rationale
3. 9. Evolution

A.5 Final Note

This appendix exists to ensure that:

• architectural intent does not decay,
• decisions are not re-litigated without context,
• and the system remains understandable long after its original authors move on.

Document Navigation

End of Appendix A