Commit Graph

6 Commits

Author SHA1 Message Date
dd698ff6d8 Migrate db, auth to mcdsl; remove mcias client dependency
- db.Open: delegate to mcdsl/db.Open
- db.Migrate: convert to mcdsl/db.Migration format, delegate
- auth: type aliases for TokenInfo/Authenticator/Config from mcdsl,
  re-export error sentinels, Logout helper
- cmd/server: construct auth.Authenticator from Config (not mcias.Client)
- server/routes.go logout: use auth.Logout(authenticator, token)
- grpcserver/auth.go: same logout pattern, fix Login return type
  (time.Time not string)
- webserver: replace mcias.Client with mcdsl/auth for service token
  validation; resolveUser degrades to raw UUID (TODO: restore when
  mcias client library is properly tagged)
- Dockerfiles: bump to golang:1.25-alpine, remove gcc/musl-dev,
  add VERSION build arg
- Deploy: add docker-compose-rift.yml with localhost-only port mapping
- Remove git.wntrmute.dev/kyle/mcias/clients/go dependency entirely
- All tests pass, net -185 lines

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-25 18:42:43 -07:00
ad167aed9b Checkpoint: grpc auth fix, issuer list/detail, v2 protos, architecture docs
Co-authored-by: Junie <junie@jetbrains.com>
2026-03-15 11:39:13 -07:00
33beb33a13 Add grpc_addr and [web] section to example configs
Both deploy/examples configs now document the new server.grpc_addr and
[web] settings introduced with the metacrypt-web separation. The Docker
example uses the compose service name (metacrypt:9443) as vault_grpc.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-15 10:15:47 -07:00
cc1ac2e255 Separate web UI into standalone metacrypt-web binary
The vault server holds in-memory unsealed state (KEK, engine keys) that
is lost on restart, requiring a full unseal ceremony. Previously the web
UI ran inside the vault process, so any UI change forced a restart and
re-unseal.

This change extracts the web UI into a separate metacrypt-web binary
that communicates with the vault over an authenticated gRPC connection.
The web server carries no sealed state and can be restarted freely.

- gen/metacrypt/v1/: generated Go bindings from proto/metacrypt/v1/
- internal/grpcserver/: full gRPC server implementation (System, Auth,
  Engine, PKI, Policy, ACME services) with seal/auth/admin interceptors
- internal/webserver/: web server with gRPC vault client; templates
  embedded via web/embed.go (no runtime web/ directory needed)
- cmd/metacrypt-web/: standalone binary entry point
- internal/config: added [web] section (listen_addr, vault_grpc, etc.)
- internal/server/routes.go: removed all web UI routes and handlers
- cmd/metacrypt/server.go: starts gRPC server alongside HTTP server
- Deploy: Dockerfile builds both binaries, docker-compose adds
  metacrypt-web service, new metacrypt-web.service systemd unit,
  Makefile gains proto/metacrypt-web targets

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-15 10:15:47 -07:00
8f77050a84 Implement CA/PKI engine with two-tier X.509 certificate issuance
Add the first concrete engine implementation: a CA (PKI) engine that generates
a self-signed root CA at mount time, issues scoped intermediate CAs ("issuers"),
and signs leaf certificates using configurable profiles (server, client, peer).

Engine framework updates:
- Add CallerInfo struct for auth context in engine requests
- Add config parameter to Engine.Initialize for mount-time configuration
- Export Mount.Engine field; add GetEngine/GetMount on Registry

CA engine (internal/engine/ca/):
- Two-tier PKI: root CA → issuers → leaf certificates
- 10 operations: get-root, get-chain, get-issuer, create/delete/list issuers,
  issue, get-cert, list-certs, renew
- Certificate profiles with user-overridable TTL, key usages, and key algorithm
- Private keys never stored in barrier; zeroized from memory on seal
- Supports ECDSA, RSA, and Ed25519 key types via goutils/certlib/certgen

Server routes:
- Wire up engine mount/request handlers (replace Phase 1 stubs)
- Add public PKI routes (/v1/pki/{mount}/ca, /ca/chain, /issuer/{name})
  for unauthenticated TLS trust bootstrapping

Also includes: ARCHITECTURE.md, deploy config updates, operational tooling.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-14 21:57:52 -07:00
4ddd32b117 Implement Phase 1: core framework, operational tooling, and runbook
Core packages: crypto (Argon2id/AES-256-GCM), config (TOML/viper),
db (SQLite/migrations), barrier (encrypted storage), seal (state machine
with rate-limited unseal), auth (MCIAS integration with token cache),
policy (priority-based ACL engine), engine (interface + registry).

Server: HTTPS with TLS 1.2+, REST API, auth/admin middleware, htmx web UI
(init, unseal, login, dashboard pages).

CLI: cobra/viper subcommands (server, init, status, snapshot) with env
var override support (METACRYPT_ prefix).

Operational tooling: Dockerfile (multi-stage, non-root), docker-compose,
hardened systemd units (service + daily backup timer), install script,
backup script with retention pruning, production config examples.

Runbook covering installation, configuration, daily operations,
backup/restore, monitoring, troubleshooting, and security procedures.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-14 20:43:11 -07:00