uBix Vault v0.2.0-beta.9

Ninth beta. Production-oriented storage and operations.

Added

• MySQL/MariaDB storage backend — -storage mysql (or Helm storage.type=mysql) runs the vault against a database instead of a local disk, so the node is replaceable: it can die and restart against the same durable, replicated database. The vault creates its own tables; you provide a database, a user, and a DSN (via a Secret in Kubernetes). Values stay barrier ciphertext — the database never sees plaintext, so a DB or DSN compromise yields ciphertext, not secrets. Single active writer (durability, not multi-writer HA). No new dependency — reuses the MySQL driver. (ADR D-014)
• Rekey — rotate the Shamir unseal shares live, with no downtime and no data re-encryption (e.g. when a share-holder leaves). POST /v1/sys/rekey/* or ubixvault operator rekey init|update|status|cancel. The master key is regenerated and the keyring re-wrapped under it; the barrier key and all data are untouched.
• Scheduled backups (Helm) — an opt-in backup.enabled CronJob snapshots the running vault to a separate (off-node) PVC on a schedule, using a least-privilege sys/snapshot token.

Still essentially one dependency (the MySQL driver). See docs/DEPLOYMENT.md for MySQL storage setup and credential hardening.

Pre-release. Not production-hardened; no external security review. For production, use HashiCorp Vault or OpenBao.

See CHANGELOG.md.

uBix Vault v0.2.0-beta.8

Eighth beta. Transit becomes full crypto-as-a-service, plus response wrapping.

Added

• Transit crypto-as-a-service — the Transit engine now covers the full surface beyond encrypt/decrypt/rotate:
  • rewrap (/v1/transit/rewrap/{name}) re-encrypts a ciphertext under the key's latest version without exposing plaintext, so old versions can be retired after a rotation.
  • data keys (/v1/transit/datakey/{plaintext|wrapped}/{name}) generate a random 128/256/512-bit key wrapped under the named key, for envelope encryption.
  • HMAC + verify (/v1/transit/hmac/{name}, /v1/transit/verify/{name}) — keyed HMAC (sha2-256/384/512), constant-time, version-tagged so it survives rotation.
  • asymmetric signing — keys can be ecdsa-p256/384/521 or ed25519; sign (/v1/transit/sign/{name}) and verify (signature or hmac), with per-version PEM public keys returned so signatures verify without the vault.
• Response wrapping — /v1/sys/wrapping/wrap stores a JSON payload behind a single-use, TTL'd token (default 5m, max 24h); /v1/sys/wrapping/unwrap returns it exactly once. Secure-introduction: hand a consumer a short-lived token instead of the secret.

All of it stdlib-only — still essentially one dependency. Symmetric and signing key operations are mutually exclusive, and existing untyped keys keep working as AES-256.

Pre-release. Not production-hardened; no external security review. For production, use HashiCorp Vault or OpenBao.

See CHANGELOG.md.

uBix Vault v0.2.0-beta.7

Seventh beta. JWT/OIDC login completes the auth-method set.

Added

• JWT/OIDC auth method — exchange a signed JWT for a token (POST /v1/auth/jwt/login). Signatures verified entirely with the standard library — RS256/384/512 and ES256/384/512 — against static PEM public keys and/or a fetched JWKS (with a refetch-on-miss for key rotation); no new dependency. Configure validation under /v1/auth/jwt/config and define roles under /v1/auth/jwt/role/{name} binding audiences and claims to a policy set and token TTL. Login validates exp/nbf, bound issuer, audiences, and per-claim bindings before issuing.

Pre-release. Not production-hardened; no external security review. For production, use HashiCorp Vault or OpenBao.

See CHANGELOG.md.

uBix Vault v0.2.0-beta.6

Sixth beta. Human login and certificate management from the console.

Added

• userpass auth method — log in with a username and password (POST /v1/auth/userpass/login/{username}) → a token with the user's policies. Passwords stored only as a PBKDF2-HMAC-SHA256 hash (600k iterations, per-user salt) via the Go 1.24 stdlib crypto/pbkdf2 — no new dependency; constant-time compare, timing equalized for unknown users.
• PKI in the web console — the /ui/ console gains a PKI panel: generate/view the root CA, manage roles, and issue certificates (copy-able cert/key/CA, "shown once" key).

Pre-release. Not production-hardened; no external security review. For production, use HashiCorp Vault or OpenBao.

See CHANGELOG.md.

uBix Vault v0.2.0-beta.5

Fifth beta. An internal certificate authority, self-hosted transit auto-unseal, and security hardening.

Added

• PKI secrets engine — generate a self-signed root CA (key never leaves the vault) and issue short-lived, role-constrained leaf certificates. Vault-compatible /v1/pki/*.
• Transit auto-unseal seal — unseal by wrapping the master key via another Vault-compatible Transit engine, so no KEK lives on the host. Seal interface (ADR D-013).

Security

• Internal review pass: 500 responses no longer echo internal error strings; documented env-var handling for seal secrets. Verified no ACL bypass, path-bound AEAD, constant-time recovery checks, fail-closed audit.

Both features are in-house, no new dependency.

Pre-release. Not production-hardened; no external security review. For production, use HashiCorp Vault or OpenBao.

See CHANGELOG.md.

uBix Vault v0.2.0-beta.4

Fourth beta. Machine authentication and API hardening.

Added

• AppRole auth method — machine clients present a stable role_id + a secret_id (stored only as a hash) to POST /v1/auth/approle/login and get a token scoped to the role's policies. Vault-compatible /v1/auth/approle/* paths.
• Rate limiting — optional per-client token-bucket throttling (-rate-limit, chart rateLimit.*); health, metrics, and the console are exempt; over-limit → 429 + Retry-After. In-house, no new dependency.

Same posture as prior betas: minimal dependency graph (still essentially one third-party dep), strict CSP console, audited writes.

Pre-release. Not production-hardened; no external security review. For production, use HashiCorp Vault or OpenBao.

See CHANGELOG.md.

uBix Vault v0.2.0-beta.3

Third beta. The /ui/ web console gains full read/write management.

Added

• Web console management — beyond read-only:
  • KV v2: create/edit secrets (→ new version), version history, read a specific version, per-version soft-delete / undelete / destroy (inline confirm).
  • ACL policies: list, read, create/edit (JSON or HCL), delete.
  • Tokens: mint a child token scoped to policies with an optional TTL.

Same posture: token in header (no cookies), strict CSP, textContent rendering, every write an audited /v1 call.

Pre-release. Not production-hardened; no external security review. For production, use HashiCorp Vault or OpenBao.

See CHANGELOG.md.

uBix Vault v0.2.0-beta.2

Second beta. Kubernetes deployment support and an auto-unseal recovery-key fix.

Added

• Helm chart (deploy/charts/ubixvault) — single-node StatefulSet, optional Ingress, and a Prometheus ServiceMonitor.
• Multi-arch image publishing to ghcr.io/cwolsen7905/ubixvault (linux/amd64 + arm64).
• Auto-unseal recovery keys — init now returns k-of-n recovery keys that authorize root-token regeneration, closing a lockout gap.
• Operator CLI TLS options — -ca-cert, -tls-skip-verify.
• Prometheus metrics at GET /v1/sys/metrics (in-house exporter, no new dependency).
• Read-only web console at /ui/ — seal state + KV read/list.

Pre-release. Not production-hardened; no external security review. For production, use HashiCorp Vault or OpenBao.

See CHANGELOG.md.

uBix Vault v0.2.0-beta.1

Beta: hardening and completeness on top of the v0.1.0 MVP. uBix Vault is now usable for real workloads (see docs/DEPLOYMENT.md), though it has not had an external security review.

Pre-release. Not production-hardened. For production, use HashiCorp Vault or OpenBao.

Added

• Token TTLs, expiry, and renewal — tokens expire (default + explicit TTL; root non-expiring); expired tokens are rejected; renew-self extends them.
• Auto-unseal — protect the master key with a 32-byte KEK instead of Shamir shares, so a restarted server unseals itself (-auto-unseal-key).
• Health/readiness endpoint — GET /v1/sys/health, readiness encoded in the status code (200/503/501).
• Backup / restore — consistent, encrypted snapshots (POST /v1/sys/snapshot, operator snapshot save/restore).
• Root-token regeneration — recover a new root token from a quorum of unseal shares.
• Lease renewal, lookup, and cascading revocation — dynamic-DB leases renew/lookup; revoking a token revokes the credentials it created.
• Kubernetes auth method — pods exchange a ServiceAccount token for a scoped token, validated via the TokenReview API.
• HCL policy documents — accept HashiCorp-style HCL policies alongside JSON (in-house parser, no new dependency).
• Deployment guide (docs/DEPLOYMENT.md).

Changed

• TLS hardening — without TLS, the server binds loopback-only; non-loopback plaintext is refused unless -dev-no-tls is set.
• Seal status reports the seal type (shamir or auto).

Known limitations

• Not production-hardened; no external security review.
• Auto-unseal takes the KEK directly (pluggable cloud-KMS/HSM seal is future work); root regeneration is Shamir-only.
• The in-house HCL parser is a policy-grammar subset, not full HCL.
• Cascading revocation and lease renewal cover dynamic-database leases.

See CHANGELOG.md for the full list.

uBix Vault v0.1.0

First release: the complete MVP core (see docs/DESIGN.md §6). uBix Vault can be initialized, unsealed, and used to store and generate secrets over an authenticated, authorized, audited HTTP API.

Status: working MVP, not yet production-hardened. No external security review or operational hardening yet — for production, use HashiCorp Vault or OpenBao.

Highlights

• Encryption barrier — AES-256-GCM at rest, with the storage path bound into the ciphertext.
• Shamir seal/unseal — in-house, constant-time GF(2⁸), validated against FIPS-197 vectors.
• Token auth + ACL policies — default-deny, scoped tokens; tokens indexed by hash, never stored in the clear.
• KV v2 — versioned secrets with soft-delete / undelete / destroy.
• Transit — encryption-as-a-service; keys never leave the vault and rotate without breaking old ciphertext.
• Dynamic database credentials — short-lived MariaDB users via a DatabasePlugin interface, auto-revoked on lease expiry.
• Audit logging — fail-closed; the client token is HMAC'd, never logged in the clear.
• Server + operator CLI — ubixvault server and ubixvault operator init/unseal/seal-status/seal.

CI runs build, race tests, golangci-lint (incl. gosec), govulncheck, and a MariaDB integration job on every change.

See CHANGELOG.md for the full list and known limitations.