Distributed Vault - Dimensigon

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": "python",
      "code": "import psycopg2\nconn = psycopg2.connect(\n  database='{{vault.db_name}}',\n  user='{{vault.db_user}}',\n  password='{{vault.db_password}}',\n  host='{{vault.db_host}}'\n)\n# ... config ..."
    },
    {
      "name": "start-app",
      "action_type": "shell",
      "code": "export API_KEY={{vault.api_key}}\nexport STRIPE_KEY={{vault.stripe_secret}}\npython app.py"
    }
  ]
}

Zero-Trust Injection

Secrets never stored in orchestration definitions
Injected at execution time only
Not logged or persisted in execution history
Each node has local copy for offline resilience

🔐

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

Secrets Management Without Central Masters