// DISTRIBUTED VAULT

Secrets Management Without Central Masters

Store credentials, API keys, and config securely across your cluster. Encrypted at rest and in transit with Fernet symmetric encryption.

Real-World Use Case: Multi-Tenant SaaS with Isolated Secrets

A SaaS platform must keep each tenant's API keys, database credentials, and secrets isolated. Thousands of tenants, zero access cross-contamination.

1. REST API - Encrypted Secret Storage

Vault REST API
# Store a database password
$ curl -X POST https://node:20194/api/v1.0/vault \
  -H "Authorization: Bearer <jwt>" \
  -d '{
    "name": "tenant-001-db-password",
    "value": "super$ecure!pass"
  }'

# Retrieve (only authorized users)
$ curl https://node:20194/api/v1.0/vault/tenant-001-db-password \
  -H "Authorization: Bearer <jwt>"

# List all accessible vault entries
$ curl https://node:20194/api/v1.0/vault \
  -H "Authorization: Bearer <jwt>"

Key Properties

  • Encryption - Fernet symmetric encryption (AES-128)
  • Replication - Distributed across all cluster nodes
  • Access Control - ACLs control who can read/write
  • Rotation - Update secrets without restarting apps

2. DShell CLI - Interactive Vault Management

Operational Vault Management

Interactive shell for managing secrets without REST API:

  • action create SHELL --code "..." - Create actions
  • vault set NAME VALUE - Store secrets
  • vault get NAME - Retrieve secrets
  • vault list - List accessible secrets

DShell provides interactive shell for managing vault securely. Perfect for ops teams and scripting.

DShell Vault Commands
# Start interactive dshell
$ dshell -s cluster-node-1 -p 20194 -u admin

# Create an action using vault secrets
dshell> action create backup-db SHELL \
  --code "mysqldump -p{{vault.db-password}} > backup.sql"

# Store API credentials in vault
dshell> vault set stripe-api-key sk_live_xyz123...
Secret stored and replicated to all nodes

# List all vault entries you have access to
dshell> vault list
stripe-api-key (created: 2025-02-20)
tenant-a-db-password (created: 2025-02-15)
slack-webhook-url (created: 2025-02-10)

# Batch mode to update multiple secrets
$ dshell action create deploy-prod SHELL \
  --code "ansible-playbook deploy.yml -e pass={{vault.prod-db-pass}}"

3. Multi-Tenant Isolation

Namespace Example
// Tenant A's group permissions
{
  "group": "tenant-a-app",
  "permissions": {
    "vault": [
      "can_read:tenant-a-*",
      "can_write:tenant-a-*"
    ]
  }
}

// Tenant A can NOT access tenant-b secrets
$ dshell vault get tenant-b-api-key

403 Forbidden - Access Denied

Namespace-Based Control

Each tenant namespace is isolated via ACLs:

  • Tenant A can only access secrets starting with `tenant-a-*`
  • Tenant B can only access secrets starting with `tenant-b-*`
  • Admin can see and manage all
  • Cross-tenant reads return 403 Forbidden

4. Automatic Secret Injection

Orchestration Template
{
  "name": "deploy-saas",
  "steps": [
    {
      "name": "configure-db",
      "action_type": "SHELL",
      "code": "python3.9 - <<'PY'\nimport psycopg2\nwith psycopg2.connect(dbname={{vault.db_name|tojson}}, user={{vault.db_user|tojson}}, password={{vault.db_password|tojson}}, host={{vault.db_host|tojson}}, connect_timeout=5) as connection:\n    with connection.cursor() as cursor:\n        cursor.execute('SELECT 1')\n        assert cursor.fetchone() == (1,)\nprint('Database reachable')\nPY",
      "expected_rc": 0,
      "id": "1",
      "undo": false,
      "target": "all",
      "parent_step_ids": []
    },
    {
      "name": "start-app",
      "action_type": "SHELL",
      "code": "python3.9 - <<'PY'\nimport os\nos.environ['API_KEY'] = {{vault.api_key|tojson}}\nos.environ['STRIPE_KEY'] = {{vault.stripe_secret|tojson}}\nos.execvp('python3.9', ['python3.9', 'app.py'])\nPY",
      "expected_rc": 0,
      "id": "2",
      "undo": false,
      "target": "all",
      "parent_step_ids": [
        "1"
      ]
    }
  ]
}

Dimensigon 0.3.5 launches Python via SHELL. Provision Python 3.9, psycopg2 and the application on disposable lab nodes; use synthetic vault values and a lab PostgreSQL endpoint. This example checks connectivity with SELECT 1 and does not configure a database.

Runtime Injection

  • Secrets never stored in orchestration definitions
  • Injected at execution time only
  • Review node and application logging before supplying secrets; this example prints only the connection result
  • Each node has local copy for offline resilience

Additional Capabilities

🔄 Dynamic Secret Rotation

Automatically rotate secrets on schedule. Orchestrations seamlessly use new values without restarts.

Rotation Policy
"db_password": {
  "rotation_policy": "monthly",
  "next_rotation": "2025-04-12",
  "auto_update": "true"
}

📋 Audit Trail & Compliance

Complete audit log of all secret access, modifications, and rotations for compliance (HIPAA, SOC2).

Audit Log
// Full audit trail
"2025-03-12 14:32:01":
  "user": "alice@org",
  "action": "read",
  "secret": "aws_key",
  "approved": "true"

🔀 Multi-Version Secrets

Store multiple versions of secrets. Roll back instantly if a secret causes issues in production.

Version Control
"db_password": {
  "v1": "old_pass",
  "v2": "current_pass",
  "current": "v2",
  "rollback": "v1"
}

🌍 Cross-Cluster Sync

Secrets automatically synced across multiple clusters with quorum consistency guarantee.

Sync Status
"sync": {
  "cluster-us": "in-sync",
  "cluster-eu": "in-sync",
  "cluster-sg": "syncing"
}
🔐

End-to-End Encryption

Secrets encrypted at rest, in transit, and during execution.

👥

Multi-Tenant Isolation

Namespace-based ACLs keep tenant secrets segregated.

🔄

Automatic Replication

Secrets replicated across all nodes via catalog sync.

♻️

Secret Rotation

Update secrets without app restarts or re-deployments.

Explore Polyglot Orchestration Back to Features