Configuration Diff & Validation#

InfraGuard ships two tools for config management: ConfigDiffer compares two configs and shows what changed, ConfigValidator runs security and best-practice checks against the effective runtime config.

Config Diff#

The differ compares two YAML config files (or one file against the generated defaults) and reports added, removed, and changed values.

CLI#

# Compare two config files
infraguard config diff config-prod.yaml config-staging.yaml

# Compare against default config
infraguard config diff --defaults config.yaml

Output#

+ Added (2)
  + domains.staging.example.com.upstream = 'https://10.0.0.6:8443'
  + domains.staging.example.com.drop_action.type = 'redirect'

- Removed (1)
  - domains.old.example.com  (was {upstream: 'https://10.0.0.3:8443', ...})

~ Changed (3)
  ~ pipeline.block_score_threshold: 0.7  ->  0.6
  ~ intel.feeds.refresh_minutes: 60  ->  30
  ~ api.bind: '127.0.0.1'  ->  '0.0.0.0'

Features#

Set-style list diffing: Scalar lists (CIDRs, ASNs, User-Agents) are compared as sets, so reordering doesn’t show as a change. Only actual additions and removals are reported.
Ordered list diffing: Structured lists (listeners, content routes) are compared positionally.
Secret masking: Values that look like secrets (containing “token”, “secret”, “key”, “pass”) are truncated in the output.
Colour-coded output: Green for added, red for removed, yellow for changed. Pass --no-color for plain text.
Ignore paths: Skip volatile paths that change between environments.

Config Validation#

The validator goes beyond Pydantic schema validation and checks for operational and security issues. It runs against the parsed config with defaults applied, so checks reason about the effective runtime state.

CLI#

# Validate a config file
infraguard config validate config.yaml

# Test a config without starting the server
infraguard config test config.yaml

Severity Levels#

Level	Meaning
error	Config will not work, or exposes immediate security risk
warning	Likely misconfiguration. Works but degrades security posture
info	Best-practice suggestion

Security Checks#

Code	Check
SEC001	API auth token is empty (unauthenticated management API)
SEC002	API auth token is too short (< 16 chars)
SEC003	API bound to non-loopback address without auth token
SEC004	Content route has no rate limiting
SEC005	Backend has no auth_token (public payload access)
SEC006	Backend auth_token is too short
SEC007	Campaign token validation enabled but no tokens configured
SEC008	3+ core pipeline filters disabled
SEC011	Phishing.club webhook enabled without HMAC secret
SEC012	Whitelisted CIDR is overly broad (e.g. /8 or wider)

Operational Checks#

Code	Check
OPS002	No listeners configured
OPS004	No domains configured
OPS005	Domain has no upstream URL
OPS007	Duplicate content route paths (earlier entry shadows later)
OPS009	Block score threshold outside valid [0.0, 1.0] range
OPS010	Block threshold too low (will block legitimate targets)
OPS011	Block threshold too high (scanners will pass)
OPS012	GeoIP lists configured but no database path set
OPS013	Country in both blocked and allowed lists

TLS Checks#

Code	Check
TLS001	HTTPS listener has no cert/key configured
TLS002	Plain HTTP listener on port 443 (likely typo)
TLS003	TLS verification disabled for upstream (vulnerable to MITM)
TLS005	TLS cert/key file not found on disk

Example Output#

  [ERROR  ] SEC001  api.auth_token
             API auth token is empty. The management API will accept
             unauthenticated requests.
  [WARNING] TLS003  domains.cdn.example.com.ssl_verify
             TLS verification is DISABLED for upstream https://10.0.0.5:8443.
             Vulnerable to MITM between redirector and teamserver.
  [INFO   ] OPS001  api.bind
             API bound to 0.0.0.0; ensure firewall rules restrict
             access to operator IPs.

1 error(s), 1 warning(s), 1 info(s).