Skip to main content

Secrets, PKI, and Runtime Trust Service implemented

This shared-service layer owns purpose metadata, delivery contracts, certificate and secret lifecycle posture, and the evidence boundary around runtime trust.

It is deliberately a coordination layer over Vault, step-ca, cert-manager, Kubernetes Secrets, and PKI helpers. It is not “a new vault.”

Core Boundary

Owned hereNot owned here
purpose registry, delivery mode, rotation policy, custody metadata, evidence component IDsraw secret stores, raw provider bodies, or public secret re-display
certificate lifecycle posture and readbackexposing private keys or raw wrapped-token bytes
one-time reveal rules for selected credentialsproduct-local shortcuts around rotation or revocation

Purpose Contract

Every credential or certificate needs a stable purpose identity:

  • what it is for;
  • who owns it;
  • where it is stored;
  • how it is delivered;
  • how often it rotates;
  • which evidence component proves it is healthy.

That is what turns secrets/PKI from hand-managed infrastructure into a platform service.

Storage Tiers

TierMeaning
vault_transitsigning/encryption without raw key export
vault_kvnormal secret custody in Vault
kubernetes_secrettransitional cache only, not the desired source of truth
ephemeralmemory-only material such as renewed short-lived certs

One-Time Reveal Rule

Some credentials are intentionally reveal-once only. After delivery, the platform must expose metadata only:

  • purpose;
  • expiry;
  • rotation due;
  • status;
  • evidence link.

There is no “show the secret again” product path.

Runtime Trust Flow

Design Rules

  1. Raw material appears only at the approved delivery boundary.
  2. New issuance and renewal fail closed outside grace windows.
  3. Existing short-lived credentials may survive until expiry, but stale posture must be visible.
  4. Extraction and regulated custody claims need explicit evidence packets.

What Reviewers Should Understand

ReviewerWhat this service proves
Securitysecret handling is contract-driven and evidence-backed
Operationsrotation and expiry have readable posture, not hidden tool-specific state
Architectureruntime trust is a shared platform service, not a product-specific afterthought
Developerscredential purpose and delivery mode are not implementation details they can improvise