SecretumVault

Post-quantum cryptographic secrets vault for modern infrastructure

SecretumVault is a Rust-native secrets vault with production-ready post-quantum cryptography (ML-KEM-768, ML-DSA-65), Cedar-based policy authorization, and flexible backend selection. Built for organizations deploying cryptographic agility today.

---

Why SecretumVault

The Problem: Current encryption will be broken by quantum computers. Most secret vaults have no PQC migration path. Cloud KMS vendors lock you in. Policy languages are proprietary.

The Solution: SecretumVault provides cryptographic agility through pluggable backends. Post-quantum crypto (ML-KEM-768, ML-DSA-65) works today via OQS backend. Classical crypto available for compatibility. Cedar policies are portable. Multi-cloud storage prevents lock-in.

vs HashiCorp Vault

Feature	HashiCorp Vault	SecretumVault
PQC Support	❌ No roadmap	✅ Production-ready (OQS backend)
Language	Go (CGO overhead)	Rust (memory safe, zero-cost abstractions)
Policy Engine	HCL policies	Cedar ABAC (AWS open standard)
Community	Large, mature	⚠️ Smaller (tradeoff for early PQC adoption)
Best For	General use, large teams	PQC today, Rust stacks, multi-cloud

vs AWS Secrets Manager

Feature	AWS Secrets Manager	SecretumVault
Multi-Cloud	❌ AWS-only	✅ Any cloud or on-premise
Self-Hosted	❌ SaaS only	✅ Full control
PQC Support	❌ None	✅ Production-ready ML-KEM + ML-DSA
Vendor Lock-in	⚠️ High	✅ Portable
Best For	AWS-native apps	Multi-cloud, PQC deployment, data sovereignty

Best for: Organizations deploying post-quantum cryptography today, multi-cloud deployments, Rust infrastructure stacks, compliance-heavy industries requiring data sovereignty and cryptographic agility.

---

30-Second Demo

# Start with Docker Compose (vault + etcd)
docker-compose -f deploy/docker/docker-compose.yml up -d

# Initialize vault (creates unseal keys + root token)
curl -X POST http://localhost:8200/v1/sys/init \
  -d '{"shares": 3, "threshold": 2}'

# Store a secret (using classical crypto by default)
export VAULT_TOKEN="<root_token_from_init>"
curl -X POST http://localhost:8200/v1/secret/data/myapp \
  -H "X-Vault-Token: $VAULT_TOKEN" \
  -d '{"data": {"api_key": "supersecret"}}'

# Retrieve secret
curl http://localhost:8200/v1/secret/data/myapp \
  -H "X-Vault-Token: $VAULT_TOKEN"

# Enable PQC: Edit svault.toml, set crypto_backend = "oqs", restart

The power: Production-grade secrets management with full PQC support today. Switch backends via config—no code changes needed.

---

Production Status

Classical Cryptography: Production-Ready ✅

Post-Quantum Cryptography: Production-Ready ✅

Cryptographic Backends

Backend	Algorithms	Status	Use Case
OpenSSL	RSA, ECDSA, AES-256-GCM	✅ Production	Classical crypto for compatibility
OQS	ML-KEM-768, ML-DSA-65	✅ Production	Post-quantum cryptography
AWS-LC	RSA, ECDSA (PQC experimental)	⚠️ Experimental	Testing AWS-LC PQC integration
RustCrypto	AES-256-GCM, ChaCha20-Poly1305	⚠️ Testing	Pure-Rust implementation testing

Post-Quantum Cryptography (OQS Backend)

Status: PRODUCTION-READY ✅

Algorithm	Implementation	NIST Standard	Status
ML-KEM-768	Key Encapsulation	FIPS 203	✅ Complete
ML-DSA-65	Digital Signatures	FIPS 204	✅ Complete
Hybrid Mode	Classical + PQC	In Progress	🚧 Q1 2026

Implementation via OQS (Open Quantum Safe):

• Library: oqs = "0.10" (official NIST PQC reference implementation)
• ML-KEM-768: Full key encapsulation (encapsulate/decapsulate) ✅
• ML-DSA-65: Full digital signatures (sign/verify) ✅
• NIST Compliance: Verified sizes (1088-byte ciphertext, 32-byte shared secret)
• Caching: Native OQS types cached for performance

Production Guidance:

• Deploy PQC today: Use crypto_backend = "oqs" in production
• Classical compatibility: Use crypto_backend = "openssl" if needed
• Hybrid mode: Coming Q1 2026 for dual classical+PQC

What Works Today (Production)

• ✅ Post-Quantum Crypto: ML-KEM-768 + ML-DSA-65 (OQS backend)
• ✅ Classical Crypto: RSA, ECDSA, AES-256-GCM (OpenSSL backend)
• ✅ Secrets Engines: KV (versioned), Transit (encryption-as-a-service), PKI (X.509), Database (dynamic credentials)
• ✅ Storage Backends: etcd (distributed), SurrealDB, PostgreSQL, Filesystem
• ✅ Authorization: Cedar policy engine with ABAC
• ✅ Enterprise Features: Shamir unsealing, TLS/mTLS, token management, audit logging

Metrics:

• 15,000+ lines of Rust across 20+ modules
• 50+ tests with comprehensive coverage
• 4 crypto backends (OpenSSL, OQS, AWS-LC, RustCrypto)
• 4 storage backends (etcd, SurrealDB, PostgreSQL, filesystem)
• 4 secrets engines (KV, Transit, PKI, Database)

---

Quick Navigation

For Security Teams

Deploy post-quantum cryptography today:

1. Why SecretumVault - PQC production-ready comparison
2. Production Status - OQS backend with ML-KEM + ML-DSA
3. Security Guidelines - Key management, audit logs, compliance

For Platform Engineers

Deploy and integrate:

1. 30-Second Demo - Get started immediately
2. Deployment Guide - Docker, Kubernetes, Helm
3. API Examples - Integration patterns

For Compliance Officers

Ensure data sovereignty and auditability:

1. Authorization & Policies - Cedar ABAC policies
2. Audit Logging - 100% operation logging
3. Multi-Cloud Storage - Avoid vendor lock-in

---

Features

🔐 Post-Quantum Cryptography

Status: Production-Ready ✅ (OQS Backend)

• ML-KEM-768: NIST FIPS 203 key encapsulation mechanism
  • Full implementation via OQS (Open Quantum Safe) ✅
  • Encapsulate + Decapsulate operations ✅
  • NIST-compliant sizes verified (1088-byte CT, 32-byte SS) ✅
• ML-DSA-65: NIST FIPS 204 digital signatures
  • Full implementation via OQS ✅
  • Sign + Verify operations ✅
  • Production-ready signature schemes ✅
• Hybrid mode: Classical + PQC algorithms (in development 🚧 Q1 2026)
• Multiple backends: OpenSSL (classical production), OQS (PQC production), AWS-LC (experimental), RustCrypto (testing)

Why it matters: Quantum computers will break current encryption. SecretumVault enables PQC deployment today with OQS backend.

Current deployment: Production-ready for organizations adopting NIST PQC standards.

🔑 Secrets Engines

• KV Engine: Versioned key-value storage with encryption at rest
• Transit Engine: Encryption/decryption without storing plaintext (encryption-as-a-service)
• PKI Engine: Certificate authority with X.509 support
• Database Engine: Dynamic credentials for PostgreSQL, MySQL, MongoDB
• Extensible: Add custom engines via trait implementation

🛡️ Authorization & Policies

• Cedar Integration: Attribute-based access control (ABAC) using AWS Cedar policy language
• Fine-grained policies: Context-aware decisions (IP allowlisting, time-based access, environment constraints)
• Token management: Lease-based credentials with automatic revocation and TTL
• Audit logging: Full request/response audit trail for compliance (SOC2, GDPR, HIPAA)

💾 Flexible Storage

• etcd: Distributed KV store with high availability and leader election
• SurrealDB: Document database with rich queries and graph capabilities
• PostgreSQL: Proven relational database with ACID guarantees
• Filesystem: Development/testing mode with JSON storage
• Extensible: Implement StorageBackend trait for any backend (S3, DynamoDB, etc.)

🚀 Cloud Native

• Kubernetes-ready: Native K8s deployments with RBAC and service mesh integration
• Helm charts: Production-ready templated deployments with customizable values
• Docker: Multi-stage builds for minimal attack surface (<50MB images)
• Prometheus metrics: Built-in observability with /metrics endpoint
• Structured logging: JSON or human-readable format with correlation IDs

🔄 Enterprise Ready

• TLS/mTLS: Encrypted client communication with mutual authentication
• Shamir Secret Sharing: Multi-factor unsealing (2-of-3, 3-of-5, 5-of-7 configurations)
• Auto-unseal: AWS KMS, GCP Cloud KMS, Azure Key Vault (planned Q2 2026)
• High availability: Multi-node clustering with Raft consensus (planned Q3 2026)
• Replication: Active-passive disaster recovery (planned Q3 2026)

---

Quick Start

Local Development with Docker Compose

# Clone repository
git clone https://github.com/jesuspc/secretumvault.git
cd secretumvault

# Build and start (vault + etcd + monitoring)
docker build -t secretumvault:latest -f deploy/docker/Dockerfile .
docker-compose -f deploy/docker/docker-compose.yml up -d

# Verify health
curl http://localhost:8200/v1/sys/health

# View logs
docker-compose -f deploy/docker/docker-compose.yml logs -f vault

Kubernetes Deployment

# Deploy to cluster
kubectl apply -f deploy/k8s/01-namespace.yaml
kubectl apply -f deploy/k8s/02-configmap.yaml
kubectl apply -f deploy/k8s/03-deployment.yaml
kubectl apply -f deploy/k8s/04-service.yaml
kubectl apply -f deploy/k8s/05-etcd.yaml

# Port-forward and access
kubectl -n secretumvault port-forward svc/vault 8200:8200
curl http://localhost:8200/v1/sys/health

Helm Installation

# Install with default configuration (OpenSSL backend)
helm install vault deploy/helm/ \
  --namespace secretumvault \
  --create-namespace

# Install with PQC enabled (OQS backend)
helm install vault deploy/helm/ \
  --namespace secretumvault \
  --create-namespace \
  --set vault.config.cryptoBackend=oqs \
  --set vault.replicas=3

---

Core Concepts

Config-Driven Architecture

All components are selected via svault.toml configuration:

[vault]
crypto_backend = "oqs"  # "openssl" (classical) or "oqs" (PQC) or "aws-lc" (experimental)

[storage]
backend = "etcd"  # or "surrealdb", "postgresql", "filesystem"

[seal]
seal_type = "shamir"
threshold = 2
shares = 3

[engines.kv]
path = "secret/"
versioned = true

[engines.transit]
path = "transit/"

No recompilation needed for backend changes—just update config and restart.

Post-Quantum Deployment

Enable PQC by changing one line:

[vault]
crypto_backend = "oqs"  # Switch from "openssl" to "oqs" for PQC

Restart vault and all secrets engines automatically use ML-KEM-768 + ML-DSA-65.

Registry Pattern

Type-safe backend selection using registry pattern:

// CryptoRegistry dispatches config string to backend
let crypto = CryptoRegistry::create(&config.vault.crypto_backend)?;
// Returns: OqsBackend (PQC) or OpenSslBackend (classical) based on config

// StorageRegistry creates backend from config
let storage = StorageRegistry::create(&config.storage)?;

// EngineRegistry mounts engines from [engines] section
let engines = EngineRegistry::mount_engines(&config.engines)?;

Async/Await

Built on Tokio for high concurrency:

• Non-blocking I/O for all storage operations
• Efficient resource utilization
• Scales to thousands of concurrent connections

Token-Based Authentication

All API requests require X-Vault-Token header:

curl -H "X-Vault-Token: $VAULT_TOKEN" \
  http://localhost:8200/v1/secret/data/myapp

Tokens have:

• TTL (time-to-live) with automatic expiration
• Renewable for extended access
• Revocable for immediate invalidation
• Audit-logged for compliance

---

Architecture Overview

┌─────────────────────────────────────────────────────────────┐
│                     API Layer (Axum)                        │
│  /v1/secret/* | /v1/transit/* | /v1/pki/* | /v1/database/*  │
└──────────────────────────┬──────────────────────────────────┘
                           │
        ┌──────────────────┼──────────────────┐
        │                  │                  │
        ▼                  ▼                  ▼
    ┌────────┐         ┌────────┐       ┌──────────┐
    │  Auth  │         │ Cedar  │       │  Metrics │
    │Manager │         │ Policy │       │Collection│
    └────────┘         │ Engine │       └──────────┘
                       └────────┘
                          │
    ┌─────────────────────┼──────────────────────┐
    │                     │                      │
    ▼                     ▼                      ▼
┌──────────┐    ┌──────────────────┐   ┌───────────────┐
│ KV Engine│    │ Transit Engine   │   │   PKI Engine  │
│  (Crypto)│    │  (Encrypt/Desc)  │   │ (Certificates)│
└──────────┘    └──────────────────┘   └───────────────┘
    │                     │                      │
    │                     ▼                      │
    │         ┌───────────────────────┐          │
    │         │  Database Engine      │          │
    │         │  (Dynamic Secrets)    │          │
    │         └───────────────────────┘          │
    │                     │                      │
    └─────────────────────┼──────────────────────┘
                          │
        ┌─────────────────┼────────────────┐
        │                 │                │
        ▼                 ▼                ▼
    ┌──────────┐    ┌──────────┐     ┌───────────┐
    │  Crypto  │    │ Storage  │     │   Seal    │
    │ Registry │    │ Registry │     │  Manager  │
    └──────────┘    └──────────┘     └───────────┘
        │                │                │
        │        ┌───────┼────────┐       │
        │        │       │        │       │
        ▼        ▼       ▼        ▼       ▼
    ┌────────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌────────────┐
    │OpenSSL │ │etcd │ │ DB  │ │ FS  │ │ Shamir SSS │
    └────────┘ └─────┘ └─────┘ └─────┘ └────────────┘
                          │
                          ▼
                 ┌─────────────────┐
                 │                 │
                 ▼                 ▼
            ┌─────────┐        ┌────────┐
            │SurrealDB│        │Postgres│
            └─────────┘        └────────┘

For detailed architecture: docs/architecture.md

---

Configuration

Minimal Setup

[vault]
crypto_backend = "openssl"

[server]
address = "0.0.0.0"
port = 8200

[storage]
backend = "etcd"

[storage.etcd]
endpoints = ["http://localhost:2379"]

[seal]
seal_type = "shamir"
threshold = 2
shares = 3

[engines.kv]
path = "secret/"
versioned = true

Production Setup

[vault]
crypto_backend = "oqs"  # Post-quantum production

[server]
address = "0.0.0.0"
port = 8200
tls_cert = "/etc/secretumvault/tls.crt"
tls_key = "/etc/secretumvault/tls.key"
tls_client_ca = "/etc/secretumvault/client-ca.crt"

[storage]
backend = "postgresql"

[storage.postgresql]
connection_string = "postgres://vault:${DB_PASSWORD}@db.example.com:5432/secretumvault"

[seal]
seal_type = "shamir"
threshold = 3
shares = 5

[engines.kv]
path = "secret/"
versioned = true

[engines.transit]
path = "transit/"

[engines.pki]
path = "pki/"

[engines.database]
path = "database/"

[logging]
level = "info"
format = "json"
output = "stdout"

[telemetry]
prometheus_port = 9090
enable_trace = true

[auth]
default_ttl = 24
cedar_policies_dir = "/etc/secretumvault/policies"

Full reference: docs/configuration.md

---

API Examples

Initialize Vault

curl -X POST http://localhost:8200/v1/sys/init \
  -H "Content-Type: application/json" \
  -d '{
    "shares": 3,
    "threshold": 2
  }'

Response:

{
  "keys": ["key1", "key2", "key3"],
  "root_token": "root_token_abc123"
}

Store Secret (KV Engine)

curl -X POST http://localhost:8200/v1/secret/data/myapp \
  -H "X-Vault-Token: $VAULT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "data": {
      "username": "admin",
      "password": "supersecret"
    }
  }'

Read Secret

curl http://localhost:8200/v1/secret/data/myapp \
  -H "X-Vault-Token: $VAULT_TOKEN"

Encrypt with Transit Engine

curl -X POST http://localhost:8200/v1/transit/encrypt/my-key \
  -H "X-Vault-Token: $VAULT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"plaintext": "dGhlIHF1aWNrIGJyb3duIGZveA=="}'

Full API reference: docs/API.md

---

Deployment

Docker

docker build -t secretumvault:latest -f deploy/docker/Dockerfile .
docker run -p 8200:8200 \
  -v /etc/secretumvault:/etc/secretumvault:ro \
  secretumvault:latest

Docker Compose

docker-compose -f deploy/docker/docker-compose.yml up -d

Includes: vault, etcd, surrealdb, postgres, prometheus, grafana

Kubernetes

kubectl apply -f k8s/
# Or: helm install vault helm/

Complete Deployment Guide

See docs/deployment.md for:

• Docker build and run
• Docker Compose multi-environment setup
• Kubernetes manifests and scaling
• Helm installation and customization
• TLS/mTLS configuration
• Prometheus monitoring
• Troubleshooting

---

How-To Guides

Quick task guides for common operations:

• Getting Started - Initial setup and first secrets
• Initialize Vault - Create unseal keys and root token
• Unseal Vault - Recover after restart
• Manage Secrets - Create, read, update, delete
• Configure Engines - Mount and customize engines
• Setup Authorization - Cedar policies and tokens
• Configure TLS - Enable encryption
• Integrate with Kubernetes - Pod secret injection
• Backup & Restore - Data protection
• Monitor & Troubleshoot - Observability

Full guide: docs/user-guide/howto.md

---

Project Structure

secretumvault/
├── src/
│   ├── main.rs                 # Server binary entry point
│   ├── config/                 # Configuration parsing
│   ├── error.rs                # Error types and conversions
│   ├── api/                    # HTTP API layer (Axum)
│   │   ├── server.rs           # Server setup and routing
│   │   ├── handlers/           # Endpoint handlers
│   │   └── middleware/         # Auth and Cedar middleware
│   ├── auth/                   # Authentication and authorization
│   │   ├── token.rs            # Token generation and validation
│   │   └── cedar.rs            # Cedar policy evaluation
│   ├── crypto/                 # Cryptographic backends
│   │   ├── backend.rs          # CryptoBackend trait and registry
│   │   ├── openssl.rs          # OpenSSL implementation
│   │   ├── oqs_backend.rs      # OQS post-quantum backend
│   │   └── aws_lc.rs           # AWS-LC backend
│   ├── storage/                # Storage backends
│   │   ├── mod.rs              # StorageBackend trait and registry
│   │   ├── filesystem.rs       # Filesystem implementation
│   │   ├── etcd.rs             # etcd implementation
│   │   ├── surrealdb.rs        # SurrealDB implementation
│   │   └── postgresql.rs       # PostgreSQL implementation
│   ├── engines/                # Secrets engines
│   │   ├── mod.rs              # Engine trait and registry
│   │   ├── kv.rs               # KV versioned store
│   │   ├── transit.rs          # Encryption as a service
│   │   ├── pki.rs              # Certificate authority
│   │   └── database.rs         # Dynamic database credentials
│   ├── core/                   # Core vault logic
│   │   ├── vault.rs            # VaultCore and initialization
│   │   ├── seal.rs             # Shamir SSS seal/unseal
│   │   └── router.rs           # Request routing to engines
│   ├── telemetry.rs            # Metrics, logging, audit
│   └── lib.rs                  # Library exports
├── deploy/                     # Deployment configurations
│   ├── docker/                 # Docker deployment
│   │   ├── Dockerfile          # Multi-stage container build
│   │   ├── docker-compose.yml  # Complete dev environment
│   │   └── config/             # Docker-specific config
│   ├── helm/                   # Helm charts for Kubernetes
│   └── k8s/                    # Raw Kubernetes manifests
├── docs/                       # Product documentation
│   ├── README.md               # Documentation index
│   ├── architecture/           # Architecture docs and ADRs
│   ├── user-guide/             # User guides
│   ├── development/            # Development docs
│   └── operations/             # Operations and deployment
├── examples/                   # Example code
├── README.md                   # This file
└── Cargo.toml                  # Rust manifest

---

Development

Build

cargo build --all-features

Test

cargo test --all-features

Lint

cargo clippy -- -D warnings

Format

cargo fmt

Run

cargo run --all-features -- server --config config/svault.toml

Documentation

cargo doc --all-features --open

---

Feature Flags

Enable optional features via Cargo:

# Build with PQC support (OQS backend)
cargo build --features pqc,oqs,surrealdb-storage,etcd-storage,postgresql-storage

# Build classical only (OpenSSL backend)
cargo build --features surrealdb-storage,etcd-storage,postgresql-storage

Available features:

• oqs - OQS cryptographic backend with production PQC (ML-KEM-768, ML-DSA-65)
• pqc - Enable post-quantum cryptography features (requires oqs)
• aws-lc - AWS-LC cryptographic backend (experimental PQC support)
• surrealdb-storage - SurrealDB storage backend
• etcd-storage - etcd storage backend
• postgresql-storage - PostgreSQL storage backend
• server - Server binary
• cli - Command-line tools
• cedar - Cedar policy evaluation

---

Security

Design Principles

• Encryption at rest: All secrets encrypted with master key derived from Shamir shares
• Least privilege: Cedar policies enforce fine-grained ABAC
• Audit logging: All operations logged with correlation IDs for compliance
• Secure defaults: Non-root execution, read-only filesystem, dropped capabilities
• Cryptographic agility: Pluggable backends enable algorithm migration
• Post-quantum ready: Deploy NIST PQC standards today with OQS backend

Security Guidelines

See docs/SECURITY.md for:

• Key management best practices
• Unsealing strategy and Shamir threshold selection
• Token security and TTL configuration
• TLS/mTLS setup for production
• Audit log review and SIEM integration
• Vulnerability reporting

---

Roadmap

Near-term (Q1-Q2 2026)

• Complete PQC KEM operations (ML-KEM-768 encapsulate/decapsulate) ✅
• Complete PQC signing operations (ML-DSA-65 sign/verify) ✅
• Hybrid mode implementation (classical + PQC)
• Additional secrets engines (SSH, Kubernetes Auth)
• Auto-unseal mechanisms (AWS KMS, GCP Cloud KMS, Azure Key Vault)
• Secret rotation policies
• Backup/restore utilities

Medium-term (Q3-Q4 2026)

• Active-passive replication
• Multi-node clustering with Raft consensus
• OAuth2/OIDC integration
• Cloud IAM integration (AWS, GCP, Azure)
• External Secrets Operator for Kubernetes
• Client SDKs (Go, Python, Node.js)

Long-term (2027+)

• Active-active multi-region replication
• Custom plugin system
• FIPS 140-2 certification
• HSM/TPM integration
• Chaos engineering test suite

---

Contributing

Contributions welcome! Please:

1. Fork repository
2. Create feature branch: git checkout -b feature/name
3. Make changes following .claude/CLAUDE.md guidelines
4. Test: cargo test --all-features
5. Lint: cargo clippy -- -D warnings
6. Submit pull request

---

License

Apache-2.0 License - See LICENSE file for details

---

Support

• Documentation: Full guides in docs/
• Issues: GitHub issue tracker
• Security: Report vulnerabilities via GitHub Security Advisory
• Community: Discussions and Q&A in GitHub Discussions

---

Presented At

• RustWeek 2026 - "Infrastructure That Compiles: A Rust Ecosystem for Governance at Scale"

---

Acknowledgments

SecretumVault combines proven patterns from:

• HashiCorp Vault - Inspiration for API design and secrets engine architecture
• NIST PQC Standardization - ML-KEM-768 (FIPS 203), ML-DSA-65 (FIPS 204)
• Open Quantum Safe (OQS) - Reference implementation of NIST PQC standards
• AWS Cedar - Policy language and attribute-based authorization
• Kubernetes Ecosystem - Cloud-native deployment patterns and operator integration

---

Built with ❤️ in Rust for post-quantum cryptographic agility and modern secrets management