Logan CusanoandClaude Opus 5
865b5b4317
Board minutes #62 Decision 2 (server-26#64), due 2026-08-31. CTO draft #60 finding 1 and CISO draft #61 finding 3 reached this independently. GET/PUT /admin/features accepted only a Firebase admin token, so the unattended runbook had no headless path and SSHed into the c2-core container to write config/ai_features with the admin SDK. Moving a platform-wide AI cost switch required a full container shell, and set_flags() wrote no audit entry either way, so a flag flip was unattributable however it happened. - New agent_service_key (AGENT_SERVICE_KEY), deliberately separate from the Discord bot's service_key. Sharing one key would collapse two principals into a single unattributable identity in every log line, and the bot has no business flipping AI flags regardless. - require_agent_key_or_admin accepts the agent key or a Firebase admin, and rejects the Discord key. The "key is configured" guard is load-bearing: compare_digest("", "") is a match, so a deployment that never set the key would otherwise accept an empty credential. - set_flags() writes an audit_log entry with before/after values and the actor, wrapped so an audit failure cannot lose the flag write or 500 the route. - Cascade helper sets the global doc and every system carrying an ai_flags override in one call. A global False already beats everything, but a system False beats a global True, so turning AI *on* could half-apply and leave a radio system hot after shutoff. It scans for the override rather than hardcoding the two known system IDs, so a new system cannot silently defeat it. - cascade defaults to False. PUT /systems/{id}/ai-flags and the AiFlagsPanel toggle mean a per-system override is deliberate operator intent; cascading by default would erase it on any unrelated global flip. The runbook opts in. Issue items 5 and 6 (retiring the SSH path from drb-worksession.md) are NOT done here and the runbook is untouched. The credential does not exist in production yet, so the SSH path is still the only one that works; retiring it now would break the next unattended run. Owner activation is recorded on #64. Tests 273 -> 289. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
63 lines
4.2 KiB
Plaintext
63 lines
4.2 KiB
Plaintext
# Template for your Ansible Vault secrets file.
|
|
# Copy to vault.yml, fill in values, then encrypt:
|
|
# ansible-vault encrypt vault.yml
|
|
# Edit later with:
|
|
# ansible-vault edit vault.yml
|
|
|
|
# DO NOT put a literal "$" in any value here. Docker compose interpolates the
|
|
# top-level .env, and depending on version it also interpolates env_file, so a
|
|
# password like "aB$fPx" is read as the variable $fPx and silently replaced
|
|
# with an empty string — on one side of the connection but not the other.
|
|
# That produced "MQTT connect refused: Not authorized" with no obvious cause.
|
|
# Generate with: openssl rand -hex 32 (hex output has no shell metacharacters)
|
|
|
|
# ── MQTT ─────────────────────────────────────────────────────────────────────
|
|
# No more shared node credential (vault_mqtt_node_user/pass) — nodes now
|
|
# authenticate as username=<node_id>, password=<their node_keys.api_key>,
|
|
# checked by mosquitto's built-in dynamic-security plugin (c2-core
|
|
# administers it — see app/internal/dynsec.py). See vault_enrollment_token
|
|
# below for how a node gets that key in the first place.
|
|
vault_mqtt_c2_user: drb-c2-core
|
|
vault_mqtt_c2_pass: "CHANGE_ME"
|
|
vault_mqtt_dynsec_admin_pass: "CHANGE_ME" # openssl rand -hex 32 — must be >=12 chars, plugin-enforced minimum
|
|
|
|
# ── C2 Core ───────────────────────────────────────────────────────────────────
|
|
vault_service_key: "" # openssl rand -hex 32 — the Discord bot's key
|
|
# The work-session agent's own key for GET/PUT /admin/features. Generate a
|
|
# SEPARATE value — never a copy of vault_service_key, or a flag flip cannot be
|
|
# attributed to the agent vs the bot (server-26#64).
|
|
vault_agent_service_key: "" # openssl rand -hex 32
|
|
vault_enrollment_token: "" # openssl rand -hex 32 — fleet-wide, shared by every node's POST /nodes/enroll
|
|
vault_openai_api_key: ""
|
|
vault_google_maps_api_key: ""
|
|
vault_gemini_api_key: ""
|
|
vault_gcs_bucket: "your-gcs-bucket-name"
|
|
vault_firestore_database: "c2-server"
|
|
|
|
# ── Gitea Container Registry ──────────────────────────────────────────────────
|
|
vault_registry_host: "git.vpn.cusano.net"
|
|
vault_registry_user: "logan"
|
|
vault_registry_token: "" # Gitea access token, READ-ONLY package scope.
|
|
# The VM only pulls (roles/deploy/tasks/main.yml:62-72);
|
|
# nothing here pushes. Pushing is CI's job and uses a
|
|
# separate write-scoped token (BUILD_TOKEN in Gitea
|
|
# repo secrets). Keep them separate: this token sits on
|
|
# an internet-facing VM, and a write-scoped one there
|
|
# would let an attacker publish a poisoned image that
|
|
# every future deploy and edge node would install.
|
|
vault_registry: "git.vpn.cusano.net/logan" # full image prefix
|
|
|
|
# ── Discord Bot ───────────────────────────────────────────────────────────────
|
|
vault_discord_token: ""
|
|
|
|
# ── Frontend (Firebase) ───────────────────────────────────────────────────────
|
|
vault_firebase_api_key: ""
|
|
vault_firebase_auth_domain: ""
|
|
vault_firebase_project_id: ""
|
|
vault_firebase_storage_bucket: ""
|
|
vault_firebase_messaging_sender_id: ""
|
|
vault_firebase_app_id: ""
|
|
|
|
# No GCP key needed — the VM uses Application Default Credentials via the
|
|
# GCE metadata server. Terraform grants the required IAM roles at apply time.
|