The Rotation Runtime

What you experience: DSO detects changes and rotates containers automatically, without downtime. Each step is validated before the next begins.

01

Detect Change

Watcher polls provider or receives webhook. ~1s.

02

Spawn Container

Launch new container with updated secrets in memory.

03

Validate Health

Wait for health checks to pass (default 30s timeout).

04

Swap Traffic

Atomically rename containers. Old → backup, new → active.

05

Cleanup

Stop and remove old container. Secrets cleared from memory.

06

Rollback

On failure: restore previous container automatically.

Real-World Example

Your database password expires at midnight. Here's what happens automatically.

1

Database password expires or rotates

2

DSO detects change in secret provider

3

New container spawned with updated credentials

4

Health checks validate container readiness

5

Traffic swapped atomically to new container

6

Old container cleaned up. Rotation complete.

Result: Automatic and Safe

Database credentials rotated. Containers updated with new secrets. No downtime. No manual intervention needed. Automatic rollback if validation fails.

Internal Security Model

How DSO protects secrets internally: Memory-only flow, zero disk persistence, atomic operations, trust boundaries. For security and compliance teams.

The Data Flow (Provider → Agent → Container)

1

Secret Resolution

Agent authenticates to vault using machine identity (IAM instance profile, AppRole, etc.)

TLS 1.2+ connection, no hardcoded credentials on host

2

Memory Acquisition

Secret fetched and held exclusively in dso-agent heap (never touches disk)

In-memory cache with TTL, purged on agent stop or timeout

3

TAR Generation

In-memory TAR archive created with secret files and directory structure

Atomic construction in process memory, zero intermediate files

4

Atomic Injection

TAR streamed directly to container's tmpfs mount via Docker API

CopyToContainer operation completes atomically or fails completely

5

SIGHUP Reload

App reloads secrets from tmpfs without container restart or traffic interruption

Signal sent only after entire payload successfully injected

Trust Boundaries & Isolation

Defense in Depth

Three layers of isolation prevent secrets from reaching untrusted boundaries.

Cloud Boundary

  • AWS Secrets Manager / Azure Key Vault / HashiCorp Vault
  • Encrypted at rest by provider
  • TLS 1.3 encryption in transit
  • Machine identity authentication

Host Boundary

  • dso-agent daemon (systemd service)
  • Secrets in locked memory (mlock)
  • Unix socket isolation (/run/dso/dso.sock)
  • No disk persistence

Container Sandbox

  • tmpfs mount (/run/secrets/)
  • Secrets in RAM only
  • Isolated namespace
  • Auto-cleanup on container stop

Zero-Persistence Guarantee

Plaintext secrets never touch your host filesystem. If the machine loses power or crashes, all secrets vanish instantly with no forensic trace.

SOC2 Type II

  • Audit trails
  • Access controls
  • Incident response

PCI-DSS

  • No plaintext persistence
  • Encryption in transit
  • Least privilege access

ISO 27001

  • Identity-based access
  • Secure communication
  • Incident management