cameleer/cameleer-server
1
0
Fork 0
Code Issues 41 Pull Requests Actions Packages Projects Releases Wiki Activity

Secret delivery option 4: External vault (Vault, OpenBao, Infisical) #132

New Issue
Open
opened 2026-04-15 00:33:43 +02:00 by claude · 0 comments
claude commented 2026-04-15 00:33:43 +02:00
Owner
Copy Link

Parent epic: #129

Overview

Use an external secret management system to store, encrypt, and deliver secrets to provisioned containers. Evaluates HashiCorp Vault, OpenBao (open-source Vault fork), Infisical, Doppler, SOPS, and others for our self-hosted Docker/Swarm/K8s deployment.

HashiCorp Vault

Licensing (2025-2026)

Aspect Status
License BSL 1.1 (not OSI-approved open source)
Self-hosted internal use Permitted
Competitive offering Prohibited
Cameleer SaaS implication Internal use to manage tenant secrets is fine
HCP Vault Secrets (SaaS) Discontinued — end of sale June 2025, EOL July 2026
Ownership IBM completed $6.4B acquisition Feb 2025

BSL is not a blocker for our use, but IBM acquisition introduces long-term uncertainty.

Architecture

Component Detail
Server Single binary, stateless compute + storage backend
Storage Integrated Raft (recommended), Consul, PostgreSQL, filesystem
Seal/Unseal Shamir's Secret Sharing (manual) or Auto-Unseal via KMS / Transit
HA 3-5 node Raft cluster
Minimum viable Single node with Raft + filesystem (no HA)

Relevant Auth Methods

Method How it works Cameleer fit
AppRole RoleId + SecretId (M2M) Best for Docker standalone
Kubernetes Pod ServiceAccount JWT Best for k3s containers
Token Direct token Dev/testing only

Secret Engines

Engine Use case Cameleer relevance
KV v2 Versioned key-value DB passwords, API keys — simplest starting point
Transit Encrypt/decrypt as a service Could encrypt config at rest in PG
Database Dynamic credentials with auto-rotation Per-tenant PG creds. No ClickHouse plugin
PKI Certificate authority Inter-container TLS

Integration Patterns for Cameleer

Pattern A: Server-side resolution (recommended)

DeploymentExecutor fetches secrets from Vault → passes to container as env vars/files

Simplest — only the server needs Vault access. Containers unchanged.

Pattern B: Vault Agent sidecar

Init container runs vault-agent → writes secrets to shared tmpfs → app reads files

More secure but adds orchestration complexity.

Pattern C: App-level SDK (Spring Cloud Vault)
Only works for apps that embed the SDK. Not suitable for arbitrary customer JARs.

K8s Integration Options

  • Vault Helm chart (standalone or HA)
  • Vault CSI Provider (mounts secrets as files)
  • Vault Secrets Operator (VSO) — CRD-based, creates K8s Secrets
  • External Secrets Operator (ESO) — vault-agnostic

Java Libraries

Library Maturity Notes
Spring Cloud Vault Mature Auto-configures properties, AppRole/K8s auth, token renewal
Spring Vault Lower level Direct VaultTemplate
Vault Java Driver (BetterCloud) Community Lightweight, no Spring dependency

Operational Overhead

Task Frequency Effort
Initial setup (single node, Raft, auto-unseal) Once 4-8 hours
Policy management Per new secret type 30-60 min
Upgrades Quarterly 1-2 hours
Backup verification Monthly 15 min
Seal event response Rare with auto-unseal 15-60 min

Self-Hosted on k3s: Practical for Small Team?

Feasible but non-trivial. Single-node Vault + Raft on k3s works. Auto-unseal via Transit Vault on separate VM eliminates manual unseal. Expect 2-4 hours setup, ~1 hour/month maintenance. Steep learning curve (HCL policies, auth backends).

OpenBao (Vault Fork)

Linux Foundation-governed, MPL 2.0-licensed fork of Vault (forked from 1.14).

Aspect Status
License MPL 2.0 (true open source)
Version 2.5.0 (February 2026)
Governance Linux Foundation + OpenSSF
GitHub 5.8k stars, active development
Vault compatibility API-compatible with Vault 1.14, most plugins work
Unique features Free namespaces (Vault Enterprise-only), CEL engine, Self-Init, Transactional Storage
Missing vs Vault Enterprise DR Replication, Performance Replication, Sentinel

Assessment: Production-ready. For self-hosted deployment, OpenBao is the clear choice over Vault CE — true open source, same tooling, namespaces included free (perfect for multi-tenancy).

Infisical

Architecture

Component Technology
Backend Node.js/TypeScript API server
Database PostgreSQL
Cache Redis
Encryption AES-256-GCM, client-side encryption
License MIT (most permissive)

Key Features

  • Secret versioning with point-in-time recovery
  • Environment-based organization (dev/staging/prod)
  • Dynamic credentials (PostgreSQL, MySQL, MongoDB, Oracle)
  • Automatic secret rotation
  • K8s Operator with auto pod redeployment on secret change
  • CSI driver integration
  • Audit logging, RBAC with OIDC/SAML SSO
  • Java SDK: com.infisical:sdk:3.0.5 with Spring Boot guide

Pricing (Self-Hosted)

Tier Cost Features
Community Free Unlimited secrets/projects, core features
Pro Usage-based Dynamic secrets, auto-rotation, advanced RBAC
Enterprise Custom SSO/SAML, audit streaming

Vault vs Infisical for Small Teams

Dimension Vault / OpenBao Infisical
Setup time 4-8 hours 30-60 minutes (Docker Compose)
Operational model Seal/unseal, HCL policies Standard PG + Redis ops
Learning curve Steep Moderate
Dynamic secrets Extensive Growing
Transit encryption Yes No
Maturity 12+ years ~3 years
ClickHouse support No native plugin No native plugin

Eliminated Options

Doppler — ⛔ Eliminated

SaaS-only, no self-hosted. All secrets transit Doppler's infrastructure. No Java SDK. Non-starter for self-hosted platform managing customer secrets.

Mozilla SOPS — Not suitable as primary solution

SOPS encrypts config files at rest (YAML/JSON). It's a build/deploy-time tool, not a runtime secret delivery mechanism. No lease renewal, rotation, or audit logging. Could complement a vault (encrypt Vault credentials in Git) but cannot replace one.

CyberArk Conjur OSS — ⛔ Eliminated

Enterprise-oriented, stale OSS version (1.21.1, June 2024), small community.

1Password Connect — Not recommended

Requires subscription ($7.99/user/mo), no Java SDK, cloud dependency.

Security Assessment

The "Secret Zero" Problem

Platform Solution
Kubernetes Solved — pods auth via ServiceAccount JWT, vault validates against K8s API
Docker standalone Partially solved — server holds Vault credential, resolves secrets server-side
Docker Swarm Docker secrets for initial credential, vault for everything else

For Cameleer: Server-side resolution means the secret zero reduces to "how does the server auth to the vault?" — K8s ServiceAccount (on k3s) or AppRole (Docker standalone).

Dynamic vs Static Secrets

Type When appropriate Cameleer examples
Static (KV) Things that don't change often API keys, OIDC secrets, license keys
Dynamic Per-deployment credentials PostgreSQL creds per tenant container

Single Point of Failure

Both Vault and Infisical become a SPOF if single-node:

  • If vault is down: Existing containers keep running (secrets already injected). New deployments fail.
  • Recovery: Vault restart ~30s. Infisical restart ~10s.

Is a Vault Overkill for <50 Containers?

For personal projects: Yes, probably overkill.
For a SaaS platform managing customer workloads: No, it is table stakes. The value: audit trail (SOC2), rotation, encryption at rest, dynamic credentials, separation of concerns.

Cross-Platform Compatibility

Solution Docker Standalone Docker Swarm Kubernetes
Vault/OpenBao API call API call K8s auth + VSO/ESO/CSI
Infisical Java SDK / REST Java SDK / REST K8s Operator + CSI
SOPS Deploy-time decrypt Deploy-time decrypt FluxCD/ArgoCD
ESO ❌ ❌ CRD-based sync

Comparison Matrix

Criterion Vault CE OpenBao Infisical SOPS Doppler
License BSL 1.1 MPL 2.0 MIT MPL 2.0 Proprietary
Self-hosted Yes Yes Yes Yes No
Setup complexity High High Low Low N/A
Operational burden High High Low-Med Minimal None
Java SDK Spring Cloud Vault Compatible Official N/A No
Dynamic secrets Extensive Extensive Growing No No
Transit encryption Yes Yes No N/A No
Audit logging Enterprise-grade Enterprise-grade Good None Good
Secret rotation Automatic Automatic Automatic Manual Automatic
Maturity 12+ years 2 years 3 years 8+ years 5 years

Recommendation

Phase 1 (Immediate): Infisical Self-Hosted

Why Infisical over Vault/OpenBao:

  1. Operational fit — runs on PostgreSQL + Redis (we already operate both). No unsealing, no HCL policies, no Raft consensus.
  2. Setup speed — Docker Compose in under an hour vs 4-8 hours for Vault.
  3. Java SDK — official Maven artifact with Spring Boot guide.
  4. MIT license — no restrictions.
  5. Cross-platform — same API for Docker standalone, Swarm, and K8s.
  6. Dynamic secrets — PostgreSQL dynamic credentials in community edition.
  7. Web UI — better DX for solo developer.
  8. K8s Operator — available for k3s deployment.

Phase 2 (If scaling beyond Infisical): OpenBao

If we outgrow Infisical (need Transit encryption, complex policies, broader dynamic secrets):

  • True open source (MPL 2.0), no IBM/BSL concerns
  • Free namespaces — perfect for multi-tenancy
  • API-compatible with Vault — Spring Cloud Vault works
  • Linux Foundation governance for long-term stability

What NOT to Do

  • Do not use Doppler — SaaS-only, no Java SDK
  • Do not use SOPS alone — config encryption tool, not runtime delivery
  • Do not use Conjur — enterprise complexity, stale OSS
  • Do not run Vault in dev mode in production
  • Do not store secrets in PostgreSQL JSONB without encryption (current state)

Verdict: ⭐⭐⭐⭐ (4/5) for Infisical; ⭐⭐⭐½ for Vault/OpenBao

Solution Rating Summary
Infisical 4.5/5 Best fit today. Low ops burden, MIT, Java SDK, dynamic secrets, cross-platform
OpenBao 4/5 Best long-term if Vault-grade power needed. True OSS, free namespaces
Vault CE 3.5/5 Battle-tested but BSL, IBM uncertainty, high ops burden
SOPS 3/5 Good complement, not primary solution
Doppler 2/5 SaaS-only disqualifies

Bottom line: Deploy Infisical self-hosted now, plan for OpenBao later if needed. Either way, this is a significant infrastructure addition — weigh against simpler options (file-mount + encryption at rest) that solve 80% of the problem.

Sources

Parent epic: #129 ## Overview Use an external secret management system to store, encrypt, and deliver secrets to provisioned containers. Evaluates HashiCorp Vault, OpenBao (open-source Vault fork), Infisical, Doppler, SOPS, and others for our self-hosted Docker/Swarm/K8s deployment. --- ## HashiCorp Vault ### Licensing (2025-2026) | Aspect | Status | |--------|--------| | License | BSL 1.1 (not OSI-approved open source) | | Self-hosted internal use | **Permitted** | | Competitive offering | Prohibited | | Cameleer SaaS implication | Internal use to manage tenant secrets is fine | | HCP Vault Secrets (SaaS) | **Discontinued** — end of sale June 2025, EOL July 2026 | | Ownership | IBM completed $6.4B acquisition Feb 2025 | BSL is **not a blocker** for our use, but IBM acquisition introduces long-term uncertainty. ### Architecture | Component | Detail | |-----------|--------| | Server | Single binary, stateless compute + storage backend | | Storage | Integrated Raft (recommended), Consul, PostgreSQL, filesystem | | Seal/Unseal | Shamir's Secret Sharing (manual) or Auto-Unseal via KMS / Transit | | HA | 3-5 node Raft cluster | | Minimum viable | Single node with Raft + filesystem (no HA) | ### Relevant Auth Methods | Method | How it works | Cameleer fit | |--------|-------------|-------------| | **AppRole** | RoleId + SecretId (M2M) | Best for Docker standalone | | **Kubernetes** | Pod ServiceAccount JWT | Best for k3s containers | | **Token** | Direct token | Dev/testing only | ### Secret Engines | Engine | Use case | Cameleer relevance | |--------|----------|-------------------| | **KV v2** | Versioned key-value | DB passwords, API keys — simplest starting point | | **Transit** | Encrypt/decrypt as a service | Could encrypt config at rest in PG | | **Database** | Dynamic credentials with auto-rotation | Per-tenant PG creds. **No ClickHouse plugin** | | **PKI** | Certificate authority | Inter-container TLS | ### Integration Patterns for Cameleer **Pattern A: Server-side resolution (recommended)** ``` DeploymentExecutor fetches secrets from Vault → passes to container as env vars/files ``` Simplest — only the server needs Vault access. Containers unchanged. **Pattern B: Vault Agent sidecar** ``` Init container runs vault-agent → writes secrets to shared tmpfs → app reads files ``` More secure but adds orchestration complexity. **Pattern C: App-level SDK (Spring Cloud Vault)** Only works for apps that embed the SDK. Not suitable for arbitrary customer JARs. ### K8s Integration Options - Vault Helm chart (standalone or HA) - Vault CSI Provider (mounts secrets as files) - Vault Secrets Operator (VSO) — CRD-based, creates K8s Secrets - External Secrets Operator (ESO) — vault-agnostic ### Java Libraries | Library | Maturity | Notes | |---------|----------|-------| | **Spring Cloud Vault** | Mature | Auto-configures properties, AppRole/K8s auth, token renewal | | Spring Vault | Lower level | Direct VaultTemplate | | Vault Java Driver (BetterCloud) | Community | Lightweight, no Spring dependency | ### Operational Overhead | Task | Frequency | Effort | |------|-----------|--------| | Initial setup (single node, Raft, auto-unseal) | Once | 4-8 hours | | Policy management | Per new secret type | 30-60 min | | Upgrades | Quarterly | 1-2 hours | | Backup verification | Monthly | 15 min | | Seal event response | Rare with auto-unseal | 15-60 min | ### Self-Hosted on k3s: Practical for Small Team? **Feasible but non-trivial.** Single-node Vault + Raft on k3s works. Auto-unseal via Transit Vault on separate VM eliminates manual unseal. Expect 2-4 hours setup, ~1 hour/month maintenance. Steep learning curve (HCL policies, auth backends). --- ## OpenBao (Vault Fork) **Linux Foundation-governed, MPL 2.0-licensed fork** of Vault (forked from 1.14). | Aspect | Status | |--------|--------| | License | **MPL 2.0** (true open source) | | Version | 2.5.0 (February 2026) | | Governance | Linux Foundation + OpenSSF | | GitHub | 5.8k stars, active development | | Vault compatibility | API-compatible with Vault 1.14, most plugins work | | Unique features | **Free namespaces** (Vault Enterprise-only), CEL engine, Self-Init, Transactional Storage | | Missing vs Vault Enterprise | DR Replication, Performance Replication, Sentinel | **Assessment:** Production-ready. For self-hosted deployment, OpenBao is the clear choice over Vault CE — true open source, same tooling, namespaces included free (perfect for multi-tenancy). --- ## Infisical ### Architecture | Component | Technology | |-----------|-----------| | Backend | Node.js/TypeScript API server | | Database | PostgreSQL | | Cache | Redis | | Encryption | AES-256-GCM, client-side encryption | | License | **MIT** (most permissive) | ### Key Features - Secret versioning with point-in-time recovery - Environment-based organization (dev/staging/prod) - Dynamic credentials (PostgreSQL, MySQL, MongoDB, Oracle) - Automatic secret rotation - K8s Operator with auto pod redeployment on secret change - CSI driver integration - Audit logging, RBAC with OIDC/SAML SSO - **Java SDK**: `com.infisical:sdk:3.0.5` with Spring Boot guide ### Pricing (Self-Hosted) | Tier | Cost | Features | |------|------|----------| | Community | Free | Unlimited secrets/projects, core features | | Pro | Usage-based | Dynamic secrets, auto-rotation, advanced RBAC | | Enterprise | Custom | SSO/SAML, audit streaming | ### Vault vs Infisical for Small Teams | Dimension | Vault / OpenBao | Infisical | |-----------|----------------|-----------| | Setup time | 4-8 hours | **30-60 minutes** (Docker Compose) | | Operational model | Seal/unseal, HCL policies | **Standard PG + Redis ops** | | Learning curve | Steep | Moderate | | Dynamic secrets | Extensive | Growing | | Transit encryption | Yes | No | | Maturity | 12+ years | ~3 years | | ClickHouse support | No native plugin | No native plugin | --- ## Eliminated Options ### Doppler — ⛔ Eliminated SaaS-only, no self-hosted. All secrets transit Doppler's infrastructure. **No Java SDK.** Non-starter for self-hosted platform managing customer secrets. ### Mozilla SOPS — Not suitable as primary solution SOPS encrypts config files at rest (YAML/JSON). It's a **build/deploy-time tool**, not a runtime secret delivery mechanism. No lease renewal, rotation, or audit logging. Could complement a vault (encrypt Vault credentials in Git) but cannot replace one. ### CyberArk Conjur OSS — ⛔ Eliminated Enterprise-oriented, stale OSS version (1.21.1, June 2024), small community. ### 1Password Connect — Not recommended Requires subscription ($7.99/user/mo), no Java SDK, cloud dependency. --- ## Security Assessment ### The "Secret Zero" Problem | Platform | Solution | |----------|---------| | **Kubernetes** | **Solved** — pods auth via ServiceAccount JWT, vault validates against K8s API | | **Docker standalone** | Partially solved — server holds Vault credential, resolves secrets server-side | | **Docker Swarm** | Docker secrets for initial credential, vault for everything else | For Cameleer: Server-side resolution means the secret zero reduces to "how does the server auth to the vault?" — K8s ServiceAccount (on k3s) or AppRole (Docker standalone). ### Dynamic vs Static Secrets | Type | When appropriate | Cameleer examples | |------|-----------------|-------------------| | **Static (KV)** | Things that don't change often | API keys, OIDC secrets, license keys | | **Dynamic** | Per-deployment credentials | PostgreSQL creds per tenant container | ### Single Point of Failure Both Vault and Infisical become a SPOF if single-node: - **If vault is down:** Existing containers keep running (secrets already injected). New deployments fail. - **Recovery:** Vault restart ~30s. Infisical restart ~10s. ### Is a Vault Overkill for <50 Containers? **For personal projects:** Yes, probably overkill. **For a SaaS platform managing customer workloads:** No, it is table stakes. The value: audit trail (SOC2), rotation, encryption at rest, dynamic credentials, separation of concerns. --- ## Cross-Platform Compatibility | Solution | Docker Standalone | Docker Swarm | Kubernetes | |----------|:-:|:-:|:-:| | **Vault/OpenBao** | API call | API call | K8s auth + VSO/ESO/CSI | | **Infisical** | Java SDK / REST | Java SDK / REST | K8s Operator + CSI | | **SOPS** | Deploy-time decrypt | Deploy-time decrypt | FluxCD/ArgoCD | | **ESO** | ❌ | ❌ | CRD-based sync | --- ## Comparison Matrix | Criterion | Vault CE | OpenBao | Infisical | SOPS | Doppler | |-----------|:---:|:---:|:---:|:---:|:---:| | License | BSL 1.1 | **MPL 2.0** | **MIT** | MPL 2.0 | Proprietary | | Self-hosted | Yes | Yes | Yes | Yes | No | | Setup complexity | High | High | **Low** | Low | N/A | | Operational burden | High | High | **Low-Med** | Minimal | None | | Java SDK | Spring Cloud Vault | Compatible | **Official** | N/A | No | | Dynamic secrets | Extensive | Extensive | Growing | No | No | | Transit encryption | Yes | Yes | No | N/A | No | | Audit logging | Enterprise-grade | Enterprise-grade | Good | None | Good | | Secret rotation | Automatic | Automatic | Automatic | Manual | Automatic | | Maturity | 12+ years | 2 years | 3 years | 8+ years | 5 years | --- ## Recommendation ### Phase 1 (Immediate): Infisical Self-Hosted **Why Infisical over Vault/OpenBao:** 1. **Operational fit** — runs on PostgreSQL + Redis (we already operate both). No unsealing, no HCL policies, no Raft consensus. 2. **Setup speed** — Docker Compose in under an hour vs 4-8 hours for Vault. 3. **Java SDK** — official Maven artifact with Spring Boot guide. 4. **MIT license** — no restrictions. 5. **Cross-platform** — same API for Docker standalone, Swarm, and K8s. 6. **Dynamic secrets** — PostgreSQL dynamic credentials in community edition. 7. **Web UI** — better DX for solo developer. 8. **K8s Operator** — available for k3s deployment. ### Phase 2 (If scaling beyond Infisical): OpenBao If we outgrow Infisical (need Transit encryption, complex policies, broader dynamic secrets): - True open source (MPL 2.0), no IBM/BSL concerns - **Free namespaces** — perfect for multi-tenancy - API-compatible with Vault — Spring Cloud Vault works - Linux Foundation governance for long-term stability ### What NOT to Do - **Do not use Doppler** — SaaS-only, no Java SDK - **Do not use SOPS alone** — config encryption tool, not runtime delivery - **Do not use Conjur** — enterprise complexity, stale OSS - **Do not run Vault in dev mode in production** - **Do not store secrets in PostgreSQL JSONB** without encryption (current state) ### Verdict: ⭐⭐⭐⭐ (4/5) for Infisical; ⭐⭐⭐½ for Vault/OpenBao | Solution | Rating | Summary | |----------|:---:|---------| | **Infisical** | 4.5/5 | Best fit today. Low ops burden, MIT, Java SDK, dynamic secrets, cross-platform | | **OpenBao** | 4/5 | Best long-term if Vault-grade power needed. True OSS, free namespaces | | **Vault CE** | 3.5/5 | Battle-tested but BSL, IBM uncertainty, high ops burden | | **SOPS** | 3/5 | Good complement, not primary solution | | **Doppler** | 2/5 | SaaS-only disqualifies | **Bottom line:** Deploy Infisical self-hosted now, plan for OpenBao later if needed. Either way, this is a significant infrastructure addition — weigh against simpler options (file-mount + encryption at rest) that solve 80% of the problem. ### Sources - [HashiCorp BSL License](https://www.hashicorp.com/en/license-faq) - [IBM Acquires HashiCorp](https://newsroom.ibm.com/2025-02-27-ibm-completes-acquisition-of-hashicorp) - [OpenBao Official Site](https://openbao.org/) - [OpenBao vs Vault Comparison](https://lalatenduswain.medium.com/openbao-vs-hashicorp-vault-the-secrets-management-showdown-every-devops-team-needs-to-read-in-2026-458ae0d9a408) - [Infisical GitHub](https://github.com/Infisical/infisical) - [Infisical Java SDK](https://github.com/Infisical/java-sdk) - [Infisical vs Vault](https://infisical.com/infisical-vs-hashicorp-vault) - [Vault AppRole Auth](https://developer.hashicorp.com/vault/docs/auth/approle) - [Vault Database Secrets](https://developer.hashicorp.com/vault/docs/secrets/databases) - [Spring Cloud Vault](https://docs.spring.io/spring-cloud-vault/reference/authentication.html) - [External Secrets Operator](https://external-secrets.io/latest/introduction/overview/) - [Secrets Management Tools 2026](https://guptadeepak.com/top-5-secrets-management-tools-hashicorp-vault-aws-doppler-infisical-and-azure-key-vault-compared/)
claude added the featuresecurity labels 2026-04-15 00:33:43 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
Accessibility (a11y) improvements
 bug
Something isn't working correctly
 cleanup
Code cleanup, dead code removal, refactoring
 epic
Epic: groups related issues
 feature
New functionality
 pmf
Product-market fit: critical for first market offer
 route-diagram
Route diagram page and execution overlay
 security
Authentication, authorization, RBAC
 ui
Frontend / React UI
 ux
UX/usability improvements
No Label feature security
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claude
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: cameleer/cameleer-server#132
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?