Status
Proposed on 2026-03-14 by Lars Solem.
Context
Dataverket already has identity, secrets, and platform security directions, but transport security between internal services is still implicit.
That is not sufficient for a platform with:
- multi-tenant control paths
- cross-datacenter communication
- NATS-based orchestration
- services making privileged infrastructure changes
Decision
Dataverket treats service-to-service transport security as a first-class control-plane requirement.
The platform should assume:
- authenticated service identity
- TLS on important internal service paths
- stronger protections for high-trust control-plane links
- explicit policy for inter-datacenter service communication
Identity and authorization are incomplete if the transport path is not also protected.
Scope
This ADR applies to:
- internal HTTP or RPC traffic
- service-to-service calls between control-plane components
- cross-datacenter service communication
- privileged infrastructure-facing agents where transport risk matters
It does not replace workload-level network policy, but it complements it.
Baseline requirements
The transport security baseline must support:
- service authentication
- confidentiality where required
- integrity protection
- rotation of trust materials
- operator visibility into failure caused by transport trust problems
High-trust paths
Some paths are more sensitive than others, for example:
- control-plane APIs
- infrastructure automation commands
- cross-datacenter coordination
- secret-distribution paths
These paths should be treated with stricter trust assumptions than casual internal traffic.
Cross-datacenter implications
Because Dataverket is multi-datacenter, transport security must also account for:
- site-to-site communication over potentially less trusted networks
- site identity
- failure and rotation during partition or degraded operation
- trust material distribution between sites
Operational considerations
Transport security must be operable.
That means the platform needs:
- visibility into handshake or trust failures
- rotation workflows
- predictable certificate or trust-material rollout
- documented failure modes during expiry or mismatch
Relationship to NATS
NATS is part of the service-to-service transport story, but not the whole of it.
This ADR does not replace a specific NATS authorization model. It requires that transport trust and service identity be considered across all important internal paths.
Explicit non-decisions for now
This ADR intentionally does not yet choose:
- exact mTLS implementation
- exact internal CA tooling for daily operations
- exact trust bootstrap mechanism for all services
Those require later implementation decisions.
Consequences
- internal trust is no longer assumed implicitly
- service identity and secrets decisions now have a concrete transport target
- multi-datacenter communication is treated as a security boundary, not just a routing problem
Decision Outcome
Proposed. This ADR records the current preferred direction and still needs acceptance before it becomes binding.
Related Decisions
- Identity and access concerns must align with 023-identity-and-access-model.md.
- Secrets and daily certificate lifecycle must align with 016-secrets-and-certificate-lifecycle.md.
- Platform-wide security posture must align with 024-platform-security-strategy.md.
- Cross-site communication assumptions must align with 012-inter-datacenter-topology-and-failover.md.
More Information
- internal trust bootstrap model
- NATS-specific auth and transport policy
- service certificate rotation workflow
Audit
- 2026-03-14: ADR proposed.