Status
Proposed on 2026-03-14 by Lars Solem.
Context
Dataverket already has an accepted break-glass model for emergency access, and Identitet covers daily auth flows through ZITADEL and Teleport.
What is still missing is the daily secrets and certificate model for normal platform operation. The platform will need to manage:
- service-to-service credentials
- API tokens
- database credentials
- tenant application secrets
- TLS certificates
- encryption keys for internal platform components
Without an explicit lifecycle, secrets handling will fragment across services and become one of the highest-risk parts of the platform.
Decision
Dataverket treats secrets and certificate management as a first-class platform capability distinct from:
- user identity and access management
- break-glass access control
- application deployment logic
The platform must provide a daily lifecycle for issuing, storing, rotating, distributing, revoking, and auditing secrets and certificates.
Scope
The secrets and certificate lifecycle must cover:
- service-to-service credentials
- machine or workload identity materials where applicable
- tenant-facing database credentials
- application runtime secrets
- TLS certificates for public and internal endpoints
- encryption keys used by platform services
Separation of concerns
Dataverket must keep these concerns separate:
Identitet Authentication, tokens, user and service identity context
Break-glass CA Emergency operator access when the normal stack is unavailable
Daily secrets system Normal issuance, storage, rotation, and revocation for platform and tenant secrets
One system may integrate with another, but they are not the same responsibility.
Lifecycle requirements
The daily secrets system must support:
- issuance of new secrets and certificates
- scoped access control
- secret retrieval by authorized services
- rotation without manual node-by-node intervention where possible
- revocation or replacement workflows
- auditability for read, write, and rotation events
Static long-lived secrets should be minimized wherever the platform can instead use short-lived credentials or derived identity.
Tenant isolation requirements
Because Dataverket is multi-tenant, the secrets model must support:
- tenant and project scoping
- environment-aware isolation where appropriate
- clear separation between operator secrets and tenant secrets
- no accidental exposure of platform-internal credentials to tenant-facing APIs
The secrets model must fit the tenant -> project -> environment hierarchy rather than bypassing it.
Certificate requirements
The platform must explicitly manage certificate lifecycle for:
- public ingress endpoints
- internal service endpoints where TLS is required
- database and service endpoints exposed to tenants
- control-plane components where certificate rotation affects availability
Certificate issuance and rotation must not depend on ad hoc manual file distribution in normal operation.
Operational model
The daily secrets system must provide:
- machine-readable APIs or controllers
- rotation visibility
- failure visibility
- revocation workflows
- backup and recovery considerations for the secret store itself
If the secrets backend is unavailable, the impact on control-plane and tenant workloads must be understood and designed for.
Relationship to break-glass
The accepted break-glass architecture remains valid and separate.
The break-glass CA is not the normal platform certificate authority for all day-to-day secrets operations. It exists specifically to preserve emergency administrative access under failure conditions.
Daily certificates and secrets should be managed through the normal secrets system, with explicit rotation and audit semantics.
Multi-datacenter implications
Because Dataverket is multi-datacenter, the secrets system must be evaluated for:
- site-aware availability
- replication or recovery behavior
- failure-domain-aware operation
- impact during inter-site partitions
The platform must not assume that secret distribution remains safe or correct under partition unless that behavior is designed explicitly.
Explicit non-decisions for now
This ADR intentionally does not yet choose:
- a specific secrets backend
- a specific certificate issuance backend for daily operations
- exact key management implementation
- exact tenant secret delivery model
Those require later selection ADRs.
Consequences
- secrets and certificates are now explicit architecture domains rather than hidden implementation details
- Identitet is no longer overloaded with responsibilities it should not own
- break-glass remains distinct from daily operations
- multiple later product and platform decisions can now depend on a shared secrets model
Decision Outcome
Proposed. This ADR records the current preferred direction and still needs acceptance before it becomes binding.
Related Decisions
- This ADR complements the accepted break-glass design in oob-security-ca.md.
- The tenancy implications depend on 009-resource-inventory-and-tenancy-model.md.
- API and task-level auth context remain governed by 008-public-api-style.md and 007-nats-subject-and-event-envelope.md.
- Multi-datacenter availability expectations must stay aligned with 012-inter-datacenter-topology-and-failover.md.
More Information
- secrets backend selection criteria
- certificate authority model for daily operations
- tenant secret delivery model
- secret rotation and revocation workflows
- backup and disaster recovery strategy for the secrets backend
Audit
- 2026-03-14: ADR proposed.