rthooks: add --fail-allow-namespaces-patterns flag

[PhilipSchmid]

Description

Add --fail-allow-namespaces-patterns to tetragon-oci-hook, accepting glob patterns for namespaces that should not cause the hook to fail when Tetragon is unreachable.

Patterns support a single * wildcard:

• kube-* — prefix match
• *-system — suffix match
• foo-*-bar — contains match
• * — matches any namespace

The flag can be used standalone or combined with the existing --fail-allow-namespaces exact-match list. A container is allowed if its namespace matches either an exact entry or any pattern. --fail-cel-expr takes precedence over both flags.

Patterns with more than one * are rejected at startup. If the namespace annotation key is absent from the container annotations the hook always fails (safe default).

Both flags are evaluated through a single CEL program. A custom namespace_matches_glob function is registered into the CEL environment, keeping all fail-check logic within the CEL evaluation path.

Changes

• cel.go: add namespaceMatchesGlob and register it as a CEL function; implement celAllowNamespacesWithPatterns as a single CEL program covering both exact names and glob patterns
• main.go: add FailAllowNamespacesPatterns to cliConf; simplify failTestProg to return *celProg directly
• cel_test.go: table-driven tests covering exact namespaces, all glob wildcard forms (prefix, suffix, contains, bare *, exact without wildcard, empty string, overlapping patterns), combined usage, missing annotation keys, multiple invalid glob forms, and annotation key priority
• values.yaml + _container_rthooks.tpl: add rthooks.failAllowNamespacesPatterns Helm value; pass each entry as a repeated flag to the hook binary
• runtime-hooks.md: document the new option, all wildcard forms, usage examples, and precedence rules

Motivation

Previously, the only way to exclude a group of namespaces from hook failures was --fail-cel-expr, which requires users to write a raw CEL expression. While powerful, this is error-prone for common cases like allowing all namespaces with a given prefix. The new flag covers these patterns without requiring any CEL knowledge:

rthooks:
  enabled: true
  failAllowNamespacesPatterns:
    - "kube-*"
    - "prod-*"
    - "*-system"

Release Note

rthooks: add --fail-allow-namespaces-patterns flag

[netlify]

✅ Deploy Preview for tetragon ready!

Name	Link
🔨 Latest commit	df027fb
🔍 Latest deploy log	https://app.netlify.com/projects/tetragon/deploys/69d60ca90d69f70008ea29a8
😎 Deploy Preview	https://deploy-preview-4812--tetragon.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[kkourt]

Thanks!

Can you split the PR into different commits so that it can be easily reviewed?

It feels to me that the PR was generated by an LLM. Please document the influence level (see: https://danielmiessler.com/blog/ai-influence-level-ail) of the PR.

[PhilipSchmid]

Thanks for the feedback and input!

Can you split the PR into different commits so that it can be easily reviewed?

Absolutely, I just did that and force-pushed 4 granular commits.

It feels to me that the PR was generated by an LLM. Please document the influence level (see: https://danielmiessler.com/blog/ai-influence-level-ail) of the PR.

💯, I used an LLM create that. I'd say it's an AIL 3-4. IMO, it's probably obvious that close to no human would have added so many unit tests 😅. Still, stuff like this was all implemented because I gave pretty detailed instructions to the LLM to do so, and I also reviewed them all and they make sense to me (according to me limited golang experience). Is there a specific way you want this AIL being mentioned in the PR and/or git commits? Maybe it's also worth to add a brief section about that in https://tetragon.io/docs/contribution-guide/ as I assume I'm not the first and won't for sure be the last one doing that?