add kubernetes nginx rift audit

[AlexMKX]

Added automated audit for Kubernetes cluster.
Checks ingress and all pods running nginx or openresty.

[NadjiHamid]

This is a strong operational addition to the project and moves the repository beyond pure exploit demonstration into infrastructure-scale exposure auditing.

A few implementation details stand out positively:

• the scanner is intentionally read-only
• it avoids Kubernetes write operations entirely
• it uses only Python stdlib + local kubectl
• it validates live effective NGINX configuration instead of relying only on image/version matching

The decision to inspect actual rewrite directives is especially important. Detecting only “affected versions” would generate a large amount of noise, whereas this approach attempts to identify the specific rewrite primitive associated with the public PoC:

rewrite ... /something?query=...

The ingress-nginx fallback logic is also well designed:

• attempt "nginx -T"
• then fallback to live "/etc/nginx/nginx.conf"
• while restricting fallback behavior to ingress-controller contexts

That makes the audit much more practical in real Kubernetes environments where "nginx -T" may fail or produce incomplete output.

The parser tests are also more complete than most quick audit tooling:

• quoted rewrite replacements
• inline comments
• malformed rewrite handling
• avoiding regex-token false positives
• validation against the public PoC configuration

I also like that the tool clearly distinguishes:

• affected-version detection
  vs
• potentially dangerous active configuration

That is an important operational distinction.

A few observations and future-improvement ideas:

1. The current detection logic identifies the known public trigger primitive, not full exploitability.

The public exploitation chain depends on multiple runtime conditions beyond the presence of "?" inside rewrite replacements:

• escaping expansion behavior
• allocator topology
• request pool layout
• adjacency conditions
• variable handling interactions

So findings should be interpreted as:

• “potentially risky rewrite pattern”
  rather than:
• “confirmed exploitable target”

2. Rewrite + set correlation could eventually be strengthened.

Right now:

• rewrite directives are inspected
• set directives are counted globally

But the public PoC relies on interaction between:

• rewrite processing
• capture reuse
• variable assignment
• allocator behavior

A future enhancement could correlate:

• rewrite blocks
• nearby "set" usage
• captured variables ("$1", "$uri", etc.)
• location scope adjacency

This could significantly reduce false positives and improve exploit-likelihood scoring.

3. Some dynamically generated configurations may evade detection.

Examples:

• Lua/OpenResty generated rewrites
• envsubst-generated configs
• runtime-generated include chains
• controller-managed temporary configs

Those may require controller-specific adapters or AST-level parsing later.

4. The current parser is intentionally lightweight, which is reasonable operationally, but multiline or heavily templated rewrite directives may eventually require a more complete nginx config parser.

Overall though, this is a valuable addition because it shifts the project from:

• isolated exploit research
  toward:
• practical cluster-wide exposure discovery and operational auditing.

That is a meaningful improvement in scope and usability.