Commit Graph
3 Commits
Author SHA1 Message Date
Admin addaabc0a8 feat(dev): DCNTRLIZED_DEV drives dev mode; dev fleet runs real mTLS
The single canonical dev flag is DCNTRLIZED_DEV=true, injected by every
docker-compose.debug/dev.yaml. Dev mode now selects endpoints and behaviors
without downgrading control-plane security:

- lib/env: IsDev()/GiteaURL(); registry BaseURL keys on DCNTRLIZED_DEV and
  DCNTRLIZED_GITEA_URL (renamed from GITEA_URL).
- authmgmt: Scheme()/PeerTransport() (satellite edges) key on DCNTRLIZED_DEV
  — dev satellites keep a plaintext RN-facing listener, production mTLS. The
  auth-management edge (New()) stays mTLS in both, preferring
  DCNTRLIZED_AUTH_URL in dev.
- Removed INSECURE_INTERNAL + propagateInsecureInternal from Maestro: the
  orchestrator no longer runs plaintext, and no longer injects the escape
  hatch into services it starts.
- lib/devboot: at boot (dev only) Maestro provisions the identities its
  compose-managed peers bind-mount at /dcntrlized/pki (before infra boots)
  and approves the known fleet in the auth trust store. Unknown peers still
  record a pending authorization and are refused (mechanisms active).
- Composes: prod docker-compose.yaml is clean (no DCNTRLIZED_DEV/GITEA_URL);
  the debug compose carries the dev flag + DCNTRLIZED_GITEA_URL only.
2026-08-16 15:51:49 +01:00
Admin 92f4787146 M2 §2: run actions and manifest fetch over mTLS with Maestro's identity
Extract maestroTransport() (Maestro's identity cert + instance CA) and
expose PeerTransport()/Scheme()/InsecureInternal() so every service peer
edge uses the same client. RunAction now targets
https://{ip}:{port}/action/{name} presenting Maestro's cert (services
require a CA-issued client cert, so only Maestro can drive actions — T4)
and FetchManifestWithRetry fetches /_manifest the same way.
INSECURE_INTERNAL=1 keeps the dev fleet plaintext (debug compose updated
to set it).
2026-08-16 01:12:01 +01:00
Admin 950b6e5827 feat(security): trusted-services surface + auth mgmt client (M2 §3)
Maestro is the UI/CA, not the enforcement: the auth service owns its
authorized-keys trust store. This is Maestro's side of the flow.

- lib/authmgmt: mTLS management client (Maestro's own identity cert from
  the instance CA) for /internal/{attestation,authorizations,revoke,
  pending}; RevokeServiceBestEffort for uninstall.
- handlers/peers: GET /api/peers, /api/peers/attestation, POST
  approve/revoke.
- uninstall: revoke the service's authorization in the auth trust store
  alongside the CRL identity revocation.
- frontend: TrustedServices panel (pending first-contact authorizations +
  approved keys with authorize/ignore/revoke actions).
- spec.yaml: document the new endpoints and schemas.
- housekeeping: untrack pki test log artifacts, gofmt fixes in pki.
2026-08-15 23:27:21 +01:00