Status
Proposed on 2026-03-14 by Lars Solem.
Context
Dataverket already has ADRs for break-glass access and daily secrets management, but those do not together form a complete security strategy.
The platform also needs explicit direction for:
- tenant network isolation
- API authentication and authorization
- NATS security boundaries
- service-to-service transport security
- workload isolation
- image and artifact trust
Decision
Dataverket adopts a platform-wide security strategy based on layered controls rather than one single security mechanism.
The platform security baseline must cover:
- identity and authorization
- secrets and certificate lifecycle
- network segmentation and isolation
- transport security
- workload isolation
- supply-chain and artifact trust
Network isolation
The platform must support explicit segmentation between:
- operator and management networks
- provisioning networks
- underlay transport
- tenant-facing logical networks
- inter-datacenter control paths
Tenant isolation must not rely on naming convention or application goodwill alone.
API and control-plane security
The public API must require:
- strong authentication
- authorization based on tenant, project, environment, and operator scope
- auditability for privileged actions
- rate limiting and abuse protection
NATS security
NATS is a critical control-plane transport and must not be treated as an open internal message bus.
The platform must define:
- which services may publish to which subjects
- which services may subscribe to which subjects
- authentication for NATS-connected components
- operator visibility into cross-site and privileged messaging paths
Least privilege applies to message transport as well as to APIs.
Service-to-service transport security
Internal service communication should assume:
- authenticated service identity
- TLS on important internal paths
- stronger transport protections on higher-trust control-plane links
- explicit policy for inter-datacenter service communication
Workload isolation
The platform must define expected isolation for:
- containers and Kubernetes workloads
- VMs
- tenant workloads sharing underlying infrastructure
The platform should not imply stronger isolation guarantees than the selected runtime and network model can actually provide.
Supply-chain and artifact security
The platform must also account for:
- trust in Talos and VM images
- trust in container images
- image promotion and provenance
- replication of trusted artifacts between datacenters
Supply-chain trust is part of platform security, not a separate optional concern.
Consequences
- security is no longer split into isolated ADRs for break-glass and secrets only
- later decisions about NATS, APIs, networking, and workload platforms must fit a shared security baseline
- tenant isolation and service trust become explicit architectural constraints
Decision Outcome
Proposed. This ADR records the current preferred direction and still needs acceptance before it becomes binding.
Related Decisions
- Identity and authorization concerns must align with 023-identity-and-access-model.md.
- Secrets and certificate lifecycle must align with 016-secrets-and-certificate-lifecycle.md.
- Network segmentation assumptions must align with 005-network-service-and-topology.md.
- Observability and operator visibility must align with 017-observability-and-operations-baseline.md and 022-operator-visibility-and-control-surface.md.
More Information
- NATS authz and subject policy model
- workload isolation guarantees
- image provenance and signing model
- service-to-service transport security implementation
Audit
- 2026-03-14: ADR proposed.