p24-infra Docs

bms1-container-audit

3 min read

Playbook — Read-only audit of a container on bms-1

Status: ACTIVE Created: 2026-07-11 (#3734, W3/W4 CI/CD plan D5)

Why this exists

bms-1 (94.23.26.113, Pinbox24 production) root SSH is authorized only from:

  1. the Windows admin workstation key, and
  2. the VPS_ROOT_SSH_KEY GitHub Actions secret (base64 developer root key).

It is unreachable from the bms-4 / vps-i1 self-hosted AI runners — their keys (claude-admin-ci-* in secrets/monitoring.env.sops) are authorized on the vps hosts but their public halves are deliberately not in bms-1’s authorized_keys. This is the same constraint documented in pinbox24-image-backup.yml and secrets-sync.yml (sync-bms-1).

Consequence: a Claude worker (dev-issue or infra-task) running on vps-i1/bms-4 cannot SSH to bms-1 to run docker inspect/docker logs. Any bms-1 audit or op must run from a GitHub-hosted runner (ubuntu-latest) using VPS_ROOT_SSH_KEY, or manually from the Windows admin workstation.

The automated audit path

Workflow: .github/workflows/audit-bms1-git-deploy-v42-prod.yml (workflow_dispatch).

gh workflow run audit-bms1-git-deploy-v42-prod.yml --repo radieu/p24-infra \
  -f container=git-deploy-v42-prod -f issue=3734
# watch:
gh run list --repo radieu/p24-infra --workflow audit-bms1-git-deploy-v42-prod.yml --limit 1
gh run watch <run-id> --repo radieu/p24-infra

The workflow is read-only (docker inspect / logs / history / ps / events / image inspect) and secret-safe:

  • environment variables are reduced to names only (sed 's/=.*//'); names matching TOKEN|KEY|SECRET|PASS|PAT|CRED|AUTH are flagged ⚠️secret-looking but never valued;
  • docker logs output is grep -viE-filtered for token|secret|password|bearer|authorization|api_key;
  • docker history CreatedBy lines have any 20+ char value token masked to <redacted>;
  • image-level baked env is reported as <value baked in image, len=N> (length only) so a baked credential is surfaced as a finding without leaking the value.

It writes the report to the job step-summary and posts the raw facts as a comment on the target issue. A human (or the requesting worker) then adds the keep / remove / remove-but-rotate recommendation.

What the audit answers

  1. What is it? image ref, entrypoint/cmd, mounts, networks, restart policy.
  2. Is it still used? container status/uptime, first & last log timestamp, retained docker events, host crontab / systemd references that would trigger it.
  3. Token-in-image risk? image-level baked env vars (with a value → baked into the layer) and a filesystem scan for *.pem / id_rsa / *.key / .netrc / .git-credentials inside the image.

Do NOT

  • Do not add write/modify steps to this workflow — if a keep/remove decision lands on “remove”, that is a separate, human-approved change, not part of the audit.
  • Do not run bms-1 docker commands from a self-hosted AI runner — they will fail with Permission denied (publickey). Use this workflow.

Graph View