Skip to content

v1.3.5 — Zero-touch CrowdSec machine credentials

Operator-facing follow-up to v1.3.4. v1.3.4 stopped the AppSec metrics page from failing when machine credentials were missing; v1.3.5 removes the missing-credentials condition entirely for fresh installs by bootstrapping them automatically.

The problem v1.3.5 solves

v1.3.4's degraded-metrics banner promised a UI field — Settings → CrowdSec → Machine credentials — that never actually shipped. Operators following the instructions hit a dead end: either run cscli machines add argos-panel --password by hand inside the CrowdSec container and then... paste values where? Into a setting key via raw PUT /api/settings/...? Out of reach for anyone not already comfortable with the API.

The options were (a) ship the missing UI field or (b) bootstrap credentials without operator involvement. Option (b) is cleaner because the credentials aren't interesting — they're machine-to- machine credentials the panel and CrowdSec should just agree on. Zero-touch automation matches the rest of the deploy story (migrations auto-apply, VAPID keys auto-generate, CLOUDFLARE_API_TOKEN auto-imports).

How v1.3.5 works

New crowdsec-init sidecar in docker-compose.yml:

crowdsec-init:
  image: crowdsecurity/crowdsec:latest
  network_mode: "service:crowdsec"
  depends_on:
    crowdsec: { condition: service_healthy }
  volumes:
    - crowdsec_data:/var/lib/crowdsec/data
    - crowdsec_config:/etc/crowdsec
    - argos_shared_setup:/shared
  restart: "no"
  entrypoint: ["/bin/sh", "-c"]
  command:
    - |
      cscli machines add argos-panel --auto -f /shared/crowdsec-machine-credentials.yaml
      # ... idempotency + collision handling

Sequence:

  1. docker compose up brings CrowdSec to healthy.
  2. crowdsec-init runs once inside CrowdSec's network namespace, writes the credentials YAML to a shared volume, and exits 0.
  3. The argos panel depends on crowdsec-init: service_completed_successfully — it doesn't start until the handoff file is on disk.
  4. Panel boot calls crowdsec.ImportMachineCredentials, which:
  5. Skips if settings are already populated (idempotent; prior bootstrap, manual pre-v1.3.5 setup, or env-var override all count).
  6. Otherwise reads the YAML, encrypts the password under ARGOS_MASTER_KEY, writes user + ciphertext into the crowdsec.machine_user + crowdsec.machine_password_encrypted settings, and deletes the plaintext file.
  7. The existing crowdsec client reads those settings at startup via the new crowdsec.ResolveMachinePassword helper, which prefers encrypted → falls back to legacy plaintext → falls back to empty. The JWT-via-watchers-login path (already implemented pre-v1.3.5) takes over from there.

Net effect: AppSec metrics charts render on first boot. No manual cscli, no copy-paste, no .env additions.

What's new

  • crowdsec-init service in docker-compose.yml — one-shot init container running the same CrowdSec image, gated on the main CrowdSec being healthy, sharing its network namespace so cscli reaches the local LAPI without exposing ports.
  • New named volume argos_shared_setup — ephemeral handoff channel between init and panel. Safe to wipe (worst case the init regenerates).
  • backend/internal/crowdsec/bootstrap.go: ImportMachineCredentials + ResolveMachinePassword. Both idempotent and non-fatal on error.
  • New setting key crowdsec.machine_password_encrypted — argos1: ciphertext under the master key. Takes precedence over the legacy plaintext crowdsec.machine_password on read.

Backwards compat

  • Operators upgrading from v1.3.4 who never set up machine credentials: docker compose up -d brings up the new init container, panel imports credentials on next boot, metrics start rendering. No action required.
  • Operators who set the legacy plaintext crowdsec.machine_password setting manually pre-v1.3.5 (including via env var): ImportMachineCredentials detects the existing credentials and skips — the sidecar's file (if it wrote one) is cleaned up without touching the DB. Legacy plaintext setting continues to be honoured as a fallback.
  • Operators who set CROWDSEC_PANEL_MACHINE_USER / ..._PASSWORD as env vars: env still wins over any DB-resolved value. The import is a no-op; the env path is unchanged.

Rollback

If the init sidecar causes problems:

# In docker-compose.override.yml
services:
  crowdsec-init:
    profiles: ["do-not-run"]
  argos:
    depends_on:
      crowdsec-init: !reset null

Panel boot without the init running still works — it falls through to ImportMachineCredentials's "file missing" path, which is a no-op. Machine credentials simply do not auto-populate, and AppSec metrics fall back to the v1.3.4 degraded banner.

To downgrade fully: git checkout v1.3.4, rebuild, redeploy. No DB migrations to reverse; crowdsec.machine_password_encrypted is an inert setting row to v1.3.4 code.

Docs

Not changed

  • AppSec mode semantics (detect / block / disabled) — unchanged.
  • appsec.fail_open — unchanged.
  • appsec_unavailable notification — unchanged.
  • Caddy bouncer plugin — unchanged.
  • No DB migrations. Settings table is the credentials' home; no new table.
  • No UI changes. The degraded banner from v1.3.4 is still there — it just stops triggering for fresh installs because credentials are present.
  • v1.3.4 release notes — context for why we ended up here (metrics were 500-ing the whole page; v1.3.4 scoped the failure; v1.3.5 removes the failure).
  • AppSec (WAF-inline) — updated feature page.