Files

T

ci / audit (push) Successful in 46s

Details

[#389 ] GVM UI moved to 127.0.0.1:19443 — k3s ingress hostPorts claim 80/443 on this node

Workstation is a k8s worker: kube-proxy hostPort rules DNAT 80/443 (any
node IP + 127.0.0.1) into the ingress pod, shadowing loopback binds.
Also: gvm-script target importer (63/63 imported) committed.
https://projects.knownelement.com/issues/389

2026-09-05 11:29:24 -05:00

3.1 KiB

Raw Blame History

openvas/ — vulnerability scanning fed from the GLPI CMDB

Ticket #389 (Greenbone on kali-tsys) · umbrella #311 · lane index https://community.turnsys.com/t/297

Pipeline (GLPI → scan targets)

GLPI CMDB (computers, read-only via mglpi identity)
  └─ glpi-to-openvas.sh --format csv   # review artifact
  └─ glpi-to-openvas.sh --format gmp   # <create_target> fragments
        └─ GVM (OpenVAS) — app-test stack: ../docker/gvm-test/

glpi-to-openvas.sh reads the computer inventory (GLPI REST, read-only), parses the ts=<ip> | mgmt <ip> comment convention (mixed = and space — both accepted), and emits GMP <create_target> fragments or a review CSV.
--fixture FILE transforms a saved GLPI response offline (deterministic test path — fixtures/glpi-computers-sample.json is a real 80-record pull).
Verified 2026-09-05: 63 scan targets parsed from 80 GLPI records (the rest have no parsable IP and are skipped; --include-no-ip overrides).

Rules of engagement (non-negotiable)

Scans against PROD hosts require an approved GLPI Change + an Uptime Kuma maintenance window. sectestbed VMs are always fair game (that is their job).
Tailscale addresses are included in targets deliberately — scanning runs over tailnet, not LAN, unless a CR says otherwise.
Findings stay in this PRIVATE repo and Redmine. Never leave the boundary.
App-test GVM binds loopback only (127.0.0.1:9392). Production engine placement = kali-tsys VM per #389, deployed under its own CR.

Status

GLPI feed script, dual-shellcheck green, fixture-tested (2026-09-05)
GVM app-test compose (loopback, pinned version tags; digest-pin at proof)
GVM bring-up + first feed import (next run: feeds download several GB)
First sectestbed scan + findings triage into Redmine
kali-tsys production engine under CR (#389)

GVM stack (app-test lane) — official Greenbone Community Edition

docker/gvm-test/compose.yaml = the OFFICIAL Greenbone compose (fetched 2026-09-05 from https://greenbone.github.io/docs/latest/_static/compose.yaml, loopback-bound: 127.0.0.1:19443 (UI) + 127.0.0.1:19392 — moved off 443/80/9392 because THIS workstation is a k3s worker whose ingress hostPorts claim those). Registry: registry.community.greenbone.net (Docker Hub greenbone/* is discontinued; ghcr.io/greenbone/gvmd exists but the official stack uses the community registry — use the official file as-is).

Bring-up: cd docker/gvm-test && docker compose -f compose.yaml pull && docker compose -f compose.yaml up -d # admin password reset: docker compose -f compose.yaml exec -u gvmd gvmd gvmd --user=admin --new-password='' Feed sync runs on first start (multi-GB, takes hours — check docker compose logs -f gvmd).

Import GLPI targets once feeds are loaded (gvm-tools service in the compose): ../../openvas/glpi-to-openvas.sh --format gmp > /tmp/targets.gmp docker compose -f compose.yaml run --rm gvm-tools ... # see #389 note

3.1 KiB Raw Blame History