laantungir/fips
1
0
Fork 0
mirror of https://github.com/jmcorgan/fips.git synced 2026-07-30 19:46:15 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
37c2973e2fb45d2051a69ffc7a7356b2262b5b7e
fips/testing/acl-allowlist
T
History
Johnathan Corgan 37c2973e2f Test infrastructure overhaul: gateway robustness + full CI coverage 
Single combined commit covering five interlocking pieces of test and
CI work that landed during the v0.3.0-prep cycle.

## fips-gateway robustness

- src/bin/fips-gateway.rs DNS upstream probe converted from a 3-second
  hard-fail to a bounded retry loop (5 attempts × 1s timeout, 1s sleep
  between attempts; ~10s worst case). Covers the cold-boot race where
  the daemon's TUN is up but the DNS responder at [::1]:5354 is still
  binding. Each failed attempt logs at INFO. In production the binary's
  retry is the live recovery mechanism; with retry it recovers silently
  instead of relying on Restart=on-failure (~5s blip + spurious ERROR
  per cycle).
- packaging/debian/fips-gateway.service `ExecStartPre` now waits up to
  30 seconds for the daemon's `fips0` TUN to appear before exec'ing
  the gateway binary. Eliminates the cold-boot race where the gateway
  exits with `fips0 interface not found` and recovers via
  `Restart=on-failure`, producing a 5-second blip and a spurious error
  log per restart cycle.
- testing/docker/entrypoint.sh gateway-mode waits up to 30s for the
  daemon's DNS responder to bind [::1]:5354 (probes once per second
  with `dig @::1 -p 5354 ... test.fips`) before exec'ing fips-gateway.
  Belt-and-suspenders with the binary's own retry: in CI we want
  deterministic startup ordering. On timeout, fall through so the
  binary's probe reports the definitive error.

## Test infrastructure DNS bind migration to ::1

After session 359's daemon DNS-bind default flipped from `127.0.0.1`
to `::1` (the production fix for ISSUE-2026-0002), the static-test
infrastructure was carrying a stale workaround that overrode the
default back to IPv4 loopback. The fips-gateway integration test
exposed the divergence: the gateway probes its DNS upstream at
`[::1]:5354` (production default) while the daemon was binding
`127.0.0.1:5354` from the template override — IPv6-explicit sockets
do not accept v4-mapped traffic, so the upstream probe exhausted
retries and the gateway exited.

- Drop the explicit `bind_addr: "127.0.0.1"` line from every test
  config that emits it: testing/static/configs/node.template.yaml,
  testing/chaos/configs/node.template.yaml, the sidecar heredoc in
  testing/docker/entrypoint.sh, testing/acl-allowlist/generate-configs.sh
  (six per-node blocks), testing/nat/scripts/generate-configs.sh, and
  the four tor templates under testing/tor/. Daemon picks up its
  production `::1` default.
- Flip the dnsmasq forwarder for `.fips` in testing/docker/Dockerfile
  from `127.0.0.1#5354` to `::1#5354` so dnsmasq on the shared test
  image continues to reach the daemon. Template and Dockerfile must
  move together since most static suites resolve `<npub>.fips` via
  the test-image dnsmasq.

## rekey-accept-off integration variant + UDP unit test

- New `rekey-accept-off` topology and docker-compose profile under
  testing/static/. 2-node variant where node-b runs with
  `udp.accept_connections: false`. Pins the regression class that
  ISSUE-2026-0004 fixed (cross-connection winner's rekey msg1 was
  being filtered by the accept_connections gate, breaking rekey).
- testing/static/scripts/rekey-test.sh accepts REKEY_TOPOLOGY and
  REKEY_ACCEPT_OFF_NODES env vars; its inject-config subcommand
  applies the per-node `udp.accept_connections: false` edit, and
  the test asserts no sustained "Dual rekey initiation" log lines.
- New UDP variant of `should_admit_msg1` admit-rekey unit test in
  src/node/tests/handshake.rs.

## ci-local.sh full integration coverage

- New runner functions and dispatcher entries for `acl-allowlist`,
  `nat-cone` / `nat-symmetric` / `nat-lan`, `rekey-accept-off`,
  `dns-resolver`, `deb-install`. Each integrates with the existing
  summary tracking via `record`.
- New `--with-tor` flag (off by default) gates `tor-socks5-outbound`
  and `tor-directory-mode` runners. Tor stays opt-in because both
  harnesses depend on the live Tor network and would introduce a
  flake source unrelated to the FIPS code.
- New suite arrays (`ACL_SUITES`, `NAT_SUITES`, `DNS_RESOLVER_SUITES`,
  `DEB_INSTALL_SUITES`, `TOR_SUITES`) drive both the default sweep
  and `--list` output.
- `run_suite` extended to accept the new suite names for `--only`
  invocations.

## GitHub CI matrix expansions

- `gateway` matrix entry runs testing/static/scripts/gateway-test.sh
  against the existing docker-compose `gateway` profile.
- `rekey-accept-off` matrix entry exercises the new topology with
  REKEY_ACCEPT_OFF_NODES=b.
- `deb-install` matrix (debian12 + ubuntu24 + ubuntu26) runs
  testing/deb-install/test.sh with privileged systemd containers.
  ~5-7 min cold cache, ~2 min warm per distro. Self-contained: builds
  its own .deb in a Debian 12 cargo-deb builder image; does not
  depend on the build job's pre-built artifact.
- `dns-resolver` matrix entry runs the full 13-scenario harness
  (per-distro systemd resolver-backend tests + real-fips end-to-end
  scenarios) in a single job. Pins the production DNS bind path that
  ISSUE-2026-0002 lived in. ~7-12 min warm, ~12-15 min cold.

Verified locally: full `bash testing/ci-local.sh` sweep passes,
including 5/5 deb-install distros and all 13 dns-resolver scenarios.
Tor-inclusive sweep (`--with-tor`) verified in a follow-up run.
2026-04-30 10:24:32 +00:00
..
.gitignore
Add peer ACL enforcement with reloadable allow/deny files (#50)
2026-04-16 05:13:07 +00:00
docker-compose.yml
Add peer ACL enforcement with reloadable allow/deny files (#50)
2026-04-16 05:13:07 +00:00
generate-configs.sh
Test infrastructure overhaul: gateway robustness + full CI coverage
2026-04-30 10:24:32 +00:00
README.md
Add peer ACL enforcement with reloadable allow/deny files (#50)
2026-04-16 05:13:07 +00:00
test.sh
Add peer ACL enforcement with reloadable allow/deny files (#50)
2026-04-16 05:13:07 +00:00

README.md

ACL Allowlist Test

Six Docker nodes use per-node ACL files mounted at the hardcoded runtime paths:

  • node-a and node-b carry the insider allowlist (node-a, node-b, node-e, node-f)
  • node-c and node-d each carry a broad allowlist containing every node alias
  • node-e and node-f do not mount any ACL files locally
  • every node gets a generated /etc/fips/hosts with aliases for node-a through node-f

This lets us test three different node behaviors at once:

  • insiders (a, b) explicitly allow a, b, e, and f
  • outsiders (c, d) allow everyone locally, but still cannot join because insiders reject them
  • allowed remotes (e, f) rely on the insider ACLs and do not need local ACL files

Test Identities

Allowed:

  • node-a
    • npub1sjlh2c3x9w7kjsqg2ay080n2lff2uvt325vpan33ke34rn8l5jcqawh57m
    • 0102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f20
  • node-b
    • npub1tdwa4vjrjl33pcjdpf2t4p027nl86xrx24g4d3avg4vwvayr3g8qhd84le
    • b102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fb0

Denied:

  • node-c
    • npub1cld9yay0u24davpu6c35l4vldrhzvaq66pcqtg9a0j2cnjrn9rtsxx2pe6
    • c102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fc0
  • node-d
    • npub1n9lpnv0592cc2ps6nm0ca3qls642vx7yjsv35rkxqzj2vgds52sqgpverl
    • d102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fd0

Additional allowed:

  • node-e
    • npub1x5z9rwzzm26q9verutx4aajhf2zw2pyp34c6whhde2zduxqav40qgq36l6
    • nsec1egyrmekfw3u4l88v8zhrak9uht503s2kvn9v49tqgp6c5l2yuxgsv386l0
  • node-f
    • npub1ytrut7gjncn2zfnhn56c0zgftf0w6p99gf6fu8j73hzw5603zglqc9av6c
    • nsec1afh3nysthqh47awpdewcw59wvvp499f8dvlyclmnv4gvpxdk56dsa6eqsn

The generated fips.key fixtures use a mix of bare hex and nsec1... values. FIPS accepts either format in key files.

Run

Build the Linux binaries and test image:

./testing/scripts/build.sh --no-docker

Start the ACL test mesh:

./testing/acl-allowlist/generate-configs.sh
docker compose -f testing/acl-allowlist/docker-compose.yml up -d --build

Or run the full integration check:

./testing/acl-allowlist/test.sh

test.sh regenerates the ACL fixtures automatically before starting Docker. The generated ACL files use alias names, and the generated hosts file makes those aliases resolvable at runtime.

The ACL harness pins the expected test entrypoint explicitly so it does not accidentally reuse an older fips-test:latest image with a different startup script.

Docker service/container/hostname identifiers in this harness intentionally use service-*, fips-acl-container-*, and host-* names so they do not collide with the logical FIPS aliases node-a through node-f. For data-plane checks and operator examples, use the explicit FIPS names such as node-a.fips and node-d.fips.

ACL paths are fixed in this branch:

  • /etc/fips/peers.allow
  • /etc/fips/peers.deny

Mounted ACL files in this harness:

  • node-a and node-b: insider allowlist plus ALL deny fallback
  • node-c and node-d: broad local allowlist used by outsider nodes trying to blend in
  • node-e and node-f: no ACL files mounted
  • all nodes: /etc/fips/hosts aliases for node-a through node-f

Generated fixture location:

  • testing/acl-allowlist/generated-configs/

Inspect peer state:

docker exec fips-acl-container-a fipsctl show peers
docker exec fips-acl-container-b fipsctl show peers
docker exec fips-acl-container-c fipsctl show peers
docker exec fips-acl-container-d fipsctl show peers
docker exec fips-acl-container-e fipsctl show peers
docker exec fips-acl-container-f fipsctl show peers

Inspect the loaded ACL state directly:

docker exec fips-acl-container-a fipsctl acl show

Use explicit .fips names when checking reachability through the FIPS overlay:

docker exec fips-acl-container-a ping node-d.fips
docker exec fips-acl-container-a ping npub1n9lpnv0592cc2ps6nm0ca3qls642vx7yjsv35rkxqzj2vgds52sqgpverl.fips

The output shows both the original ACL file entries and the resolved effective npub entries.

Expected:

  • node-a sees node-b, node-e, and node-f
  • node-b sees node-a
  • node-c sees no peers
  • node-d sees no peers
  • node-e sees node-a
  • node-f sees node-a

Visible rejection logs:

docker compose -f testing/acl-allowlist/docker-compose.yml logs -f service-a service-b service-c service-d service-e service-f

On startup, node-c and node-d immediately try their configured outbound static connection to node-a. Their own ACLs permit that attempt, but the insider ACL on node-a still rejects both peers. Because node-a also has static peer stanzas for node-c and node-d, you may see both outbound_connect and inbound_handshake rejection messages during startup. The outsider-initiated path emits messages like:

Rejected peer by ACL ... context=inbound_handshake decision=denylist match

Those messages are now emitted at debug level. This harness enables RUST_LOG=info,fips::node=debug so the ACL rejection details stay visible in test logs, and operators can temporarily raise log level the same way when diagnosing ACL issues locally.

A later ping6 from node-c.fips does not emit a new inbound_handshake message. The ping uses the data-plane session path, and since no peer session to node-a.fips was established, it just times out.

Stop and clean up:

docker compose -f testing/acl-allowlist/docker-compose.yml down
Reference in New Issue View Git Blame Copy Permalink