Files
computer-playbook/plugins/filter
Prageeth Panicker 87c8199012 feat(web-app-wazuh): add Wazuh SIEM role with OIDC/LDAP RBAC
Add single-node Wazuh stack (manager, indexer, dashboard) as a new
Ansible role, integrated with the platform's Keycloak realm via native
OIDC and secondary LDAP authorization, with three-tier RBAC.

- Pins wazuh/wazuh-{manager,indexer,dashboard}:4.14.6 and
  wazuh-certs-generator:0.0.4 (one-shot cert bootstrap job)
- No external database: wazuh.indexer (OpenSearch) is self-contained
- Auth: native OIDC against Keycloak, working end-to-end after two
  infra fixes (JVM cacerts trust for the indexer's outbound calls to
  Keycloak, front-proxy vhost wiring)
- LDAP wired as a secondary, authentication-independent authorization
  backend (group-based backend_roles enrichment only)
- RBAC: three roles (administrator, security-analyst, readonly-auditor)
  via the platform's standard meta/rbac.yml + rbac_group_path pipeline
- Documents a genuine upstream Wazuh bug: wz-home as the default
  landing route throws an uncaught client exception for any
  non-all_access role; default route moved to OpenSearch Dashboards'
  own /app/home

Addressed two full rounds of review feedback (Kevin, Alejandro):
WEB_PROTOCOL usage, service-account naming, comment cleanup, shared
Keycloak-admin-helper extraction, a real TOCTOU race in RBAC test
setup, a Mermaid auth-flow diagram, meta/services.yml placement for
the certs-generator, CA-trust-path SPOT usage, CSP tightening
(including a genuine worker-src: blob: requirement found via live
testing), and a loud (non-silent) dev-bucket fallback warning.

Rebased onto main after a 3-month gap; brought the role in line with
~30 platform-convention changes introduced in that window (swarm
compose-template rules, Tor/onion contract, Playwright timeout/goto
wrappers, file layout, task numbering, comment policy, and more).

Live-deploy verification (9 iterations) found and fixed 6 further
real bugs invisible to lint/unit tests alone:
- credentials.* / meta/schema.yml -> secrets.credentials.* /
  meta/secrets.yml (another platform-drift casualty)
- notify: "compose up" -> "compose-up" (day-one handler-name typo)
- local.subnet collision with web-app-mailu's /24
- missing primary: false alongside tor.exclusive: false, which let
  the onion domain shadow the clearnet vhost entirely
- a second front-proxy include for the onion domain, later reverted
  (see below)
- shared sys-stk-front-proxy/sys-front-tls TLS-lookup keying bug
  (app-id-keyed vs. domain-keyed), which silently applied TLS to
  Wazuh's onion vhost

The last two are related: enabling genuine dual-stack (clearnet +
onion) reachability for tor.exclusive: false surfaced a real bug in
two shared platform roles. That fix was verified safe against all 103
apps currently in the repo, but is deliberately NOT included here -
shared-role changes deserve their own PR and review, not to ride in
on a single app's feature branch. Wazuh's second front-proxy include
was reverted accordingly; the resulting onion-reachability gap is
documented in the README as a known, platform-scoped limitation.

make test: 5508 passed, 3 failed (all three trace to untracked local
scratch files - Dockerfile.bak, scripts/lab-*.sh - not present in any
CI checkout).
2026-10-06 05:15:00 +00:00
..
…
…
2026-08-18 03:22:05 +02:00
…
…
…

Custom Filter Plugins for Infinito.Nexus

This directory contains custom Ansible filter plugins used within the Infinito.Nexus project.

When to Use a Filter Plugin

  • Transform values: Use filters to transform, extract, reformat, or compute values from existing variables or facts.
  • Inline data manipulation: Filters are designed for inline use in Jinja2 expressions (in templates, tasks, vars, etc.).
  • No external lookups: Filters only operate on data you explicitly pass to them and cannot access external files, the Ansible inventory, or runtime context.

Examples

{{ role_name | get_entity_name }}
{{ my_list | unique }}
{{ user_email | regex_replace('^(.+)@.*$', '\\1') }}

When not to Use a Filter Plugin

  • If you need to load data from an external source (e.g., file, environment, API), use a lookup plugin instead.
  • If your logic requires access to inventory, facts, or host-level information that is not passed as a parameter.

Schema 🗺️

How csp_filters.py assembles one application's Content-Security-Policy. Scope is the header build, not the other filters in this directory.

flowchart TD
    decl["meta/csp.yml<br/>whitelist, flags, hashes"]
    svc["meta/services.yml<br/>services.logout.enabled"]
    flags["csp_filters.py:136<br/>get_csp_flags"]
    grant["csp_filters.py:354<br/>logout grant"]
    wl["csp_filters.py:123<br/>get_csp_whitelist"]
    inj["sys-front-inj-dashboard,<br/>-javascript, -matomo, -logout<br/>add_csp_hash"]
    gate["csp_filters.py:365<br/>hash gate"]
    build["csp_filters.py:203<br/>build_csp_header"]
    header["set $csp<br/>nginx vhost"]

    decl -->|"1. flags read by"| flags
    flags -->|"2. tokens"| build
    svc -->|"3. read by"| grant
    grant -->|"4. adds 'unsafe-inline'<br/>to script-src-elem and -attr"| build
    decl -->|"5. whitelist read by"| wl
    wl -->|"6. tokens"| build
    inj -->|"7. snippets"| gate
    gate -->|"8. hashes, only when<br/>'unsafe-inline' is absent"| build
    build -->|"9. joined string"| header

    grant -.->|"TRIP-WIRE: the token it adds<br/>closes the gate below, so every<br/>registered hash is discarded"| gate
    svc -.->|"TRIP-WIRE: the flag derives from<br/>group_names, so the script policy<br/>follows the round, not the app"| grant
    grant -.->|"TRIP-WIRE: absent from the<br/>smart-defaults docstring, which<br/>names logout only for frame-ancestors"| build

Styles carry 'unsafe-inline' by default; scripts do not. The logout grant is the only path that puts it into a script directive.

Further Reading