DEV Community: When It Runs

When a Kyverno Wildcard Guardrail Runs Past a Post-Policy CRD Until a Restart

When It Runs — Sat, 26 Sep 2026 09:48:11 +0000

`kinds: ["/"] + operations: [DELETE] on Kyverno v1.19.1 (crdWatcher` on): "no policies matched admission request" for a post-policy CRD's custom resource until the admission controller restarted — a pre-policy CRD's resource was denied before and after.

When It Runs — Run Report #RR05 · Testing what infrastructure actually does.

Provider · Component: Kyverno · ClusterPolicy wildcard matching (kinds: ["*/*"]) and the admission controller's policy cache

Versions tested: Kyverno v1.19.1 (current release as of the desk check, published 2026-09-10; re-confirmed as current at lab start on 2026-09-13), installed from the official Helm chart kyverno/kyverno 3.9.1 (repo https://kyverno.github.io/kyverno/); admission-controller image reg.kyverno.io/kyverno/kyverno:v1.19.1 at digest sha256:b31d8511ae5fd6010e2a01ea72ebae08eb82fa51d91af14a1d9fe989949b4edb. The documentation strings and issue/PR states were checked against the live docs and GitHub on 2026-09-12 and re-confirmed on 2026-09-13.

Config profile: A single-node kind cluster running the Kyverno v1.19.1 admission controller with crdWatcher enabled (Helm value admissionController.crdWatcher=true; the live container args included --crdWatcher=true, alongside --resyncPeriod=15m and --v=4); a wildcard ClusterPolicy; and a benign CRD (plus one of its custom resources) installed after the policy. Node Kubernetes version v1.34.0.

Verified on: 2026-09-24 (desk sources re-checked; v1.19.1 is still the current release) · lab measured 2026-09-13 on v1.19.1.

Affects: Kyverno ClusterPolicies that rely on a kinds: ["*/*"] wildcard deny rule (operations: [DELETE]) to cover CRDs installed after the policy is applied (v1.19.1, crdWatcher enabled; measured: the deletion was allowed — the guardrail did not match — until the admission controller was restarted).

TL;DR: On Kyverno v1.19.1 (Kubernetes v1.34.0, crdWatcher enabled), a kinds: ["*/*"] wildcard deny ClusterPolicy did not deny deletion of a labeled custom resource whose CRD was installed after the policy — the deletion was allowed at every poll across a ~32-minute window (past the 15-minute informer resync) and became denied only after the admission controller was restarted, while a pre-policy CRD's custom resource was denied throughout (control).

Full report: https://whenitruns.substack.com/p/when-a-kyverno-wildcard-guardrail

Reproduction repo: https://github.com/whenitruns/when-a-kyverno-wildcard-guardrail-runs-past-a-post-policy-crd-until-a-restart

When OPA's `semver.is_valid` Runs on What SemVer Rejects

When It Runs — Thu, 24 Sep 2026 05:26:00 +0000

On OPA v1.20.2, semver.is_valid returns true for leading-zero versions (01.2.3, 1.02.3) and empty pre-release/build sections (1.2.3-, 1.2.3+), and semver.compare compares 1.02.3 and 1.2.3 as equal.

When It Runs — Run Report #RR04 · Testing what infrastructure actually does.

Provider · Component: OPA (Open Policy Agent) · SemVer built-ins — semver.is_valid and semver.compare

Versions tested: OPA v1.20.2 (official opa_linux_amd64_static release; measured on our lab — see §2). The documentation strings and the built-in's source were checked against the live docs and the v1.20.2 source tag (2026-09-12).

Config profile: A single official opa binary; expressions evaluated with opa eval --format pretty, in both the default (non-strict) mode and --strict-builtin-errors (see §2 and §4).

Verified on: 2026-09-25 (re-measured on v1.21.0, the current release — see the update below) · lab measured 2026-09-12 on v1.20.2; desk sources re-checked 2026-09-22.

Affects: OPA policies that use semver.is_valid or semver.compare as a version trust gate — for example "reject the supplied version unless it is valid SemVer," or "allow when declared ≥ minimum" (measured on v1.20.2; on v1.21.0 these inputs are rejected — see the update below).

TL;DR: OPA's docs describe semver.is_valid as validating "that the input is a valid SemVer string", but on v1.20.2 it returns true for strings the SemVer spec rejects — leading-zero numbers (01.2.3, 1.02.3) and empty pre-release/build sections (1.2.3-, 1.2.3+) — and semver.compare compares 1.02.3 and 1.2.3 as equal rather than erroring the way it does for other malformed input like 1.2; OPA v1.21.0, released 2026-09-24, no longer shows either behavior in our re-run.

Full report: https://whenitruns.substack.com/p/when-opas-semveris_valid-runs-on

Reproduction repo: https://github.com/whenitruns/when-opas-semver-is-valid-runs-on-what-semver-rejects

When OPA's Bundle Loader Runs Past a `.manifest` Typo

When It Runs — Tue, 22 Sep 2026 22:53:25 +0000

In bundle mode, a one-character .manifest key typo (rego_verison for rego_version) draws no diagnostic that names the key; the failure can surface as rego_parse_error pointing at your .rego — OPA v1.20.1

When It Runs — Run Report #RR03 · Testing what infrastructure actually does.

Provider · Component: OPA (Open Policy Agent) · bundle .manifest loading — unknown top-level keys and rego_version

Versions tested: OPA v1.20.1 (official opa_linux_amd64_static release, Build 2026-08-28; measured on our lab VM — see §2). Documentation, published schema, and source facts checked against the live docs and the v1.20.1 source tag (2026-09-02).

Config profile: Single official opa binary; minimal two-file bundles (.manifest + one policy.rego, full contents in §2); one minimal config.yaml used only for the contrast check in §4.

Verified on: 2026-09-22 (desk sources re-checked; v1.20.2 is the current release) · lab measured 2026-09-11 on v1.20.1.

Affects: OPA bundles whose .manifest carries a mistyped or unknown top-level key — for example rego_verison instead of rego_version (measured on v1.20.1).

TL;DR: OPA's own docs state that the bundle loader "has always ignored unknown top-level keys" in .manifest, so when a bundle is loaded in bundle mode (opa build -b, or at runtime) a mistyped rego_version produces no diagnostic that names the key (measured on OPA v1.20.1) — the failure can surface instead as rego_parse_error: `if` keyword is required before rule body pointing at your .rego source file, while a mistyped key in the sibling config.yaml has drawn an explicit unknown configuration option warning since v1.19.0.

Full report: https://whenitruns.substack.com/p/when-opas-bundle-loader-runs-past

Reproduction repo: https://github.com/whenitruns/when-opas-bundle-loader-runs-past-a-manifest-typo

When the `Contact K8S API Server From Container` Rule Runs Silent

When It Runs — Wed, 16 Sep 2026 11:51:01 +0000

The shipped k8s_api_server FQDN condition (fd.sip.name="kubernetes.default.svc.cluster.local") fired on neither Falco 0.43.1 nor 0.40.0 in our lab — and the falco.org example still shows pre-v0.19.0 fd.sip="1.2.3.4"

When It Runs — Run Report #RR02 · Testing what infrastructure actually does.

Provider · Component: Falco · the k8s_api_server macro and the Contact K8S API Server From Container rule (published docs vs. shipped default)

Versions tested: Docs — live on falco.org (checked 2026-08-18). Shipped rule defaults — 0.18.0, 0.19.0, and current falcosecurity/rules main. Runtime firing — our lab (2026-08-18, one kind cluster): Falco 0.43.1 and 0.40.0, both observed not firing on a benign in-cluster API-server contact.

Config profile: Default shipped rules, no override — for the desk layers, the published documentation and versioned shipped rule files; for the lab, each image's bundled falco_rules.yaml as shipped (plus one added observation-only rule that changes no detection logic; full text in §2).

Verified on: 2026-09-14 (desk sources re-checked: the falco.org example, the shipped rule conditions, and #3834; Falco 0.44.1 was then the current release) · lab measured 2026-08-18 on Falco 0.43.1 and 0.40.0.

Affects: Operators who set the k8s_api_server macro by following the currently published example, and environments where the shipped DNS-associated condition never matches — as in a community report (#3834) and in our own lab.

TL;DR: Falco's published k8s_api_server override example still shows the placeholder 1.2.3.4:8080 that the shipped rules replaced with a DNS-associated FQDN condition in v0.19.0 — and in our lab that current condition fired on neither Falco 0.43.1 nor 0.40.0 for a benign in-cluster API-server contact, because the field it matches on (fd.sip.name) stayed empty.

Full report: https://whenitruns.substack.com/p/when-the-contact-k8s-api-server-from

Reproduction repo: https://github.com/whenitruns/when-the-contact-k8s-api-server-from-container-rule-runs-silent

When Falco Runs Out of Metadata

When It Runs — Mon, 14 Sep 2026 12:27:36 +0000

user.uid, user.loginuid, and fd.name under absent metadata on Falco 0.44.1 — plus the reported 4294967295 and /<NA> forms (0.31.0–0.40.0)

When It Runs — Run Report #RR01 · Testing what infrastructure actually does.

Provider · Component: Falco · alert output field rendering when metadata is absent (user.uid, user.loginuid, user.name, fd.name)

Versions tested: Falco 0.44.1 (our lab, 2026-08-18 — modern_ebpf, standard Ubuntu 24.04 kernel). Publicly reported across 0.31.0 (2022) through 0.40.0 (2025) — quoted as reported, not re-measured.

Config profile: Default falco.yaml as shipped in the official 0.44.1 image, with json_output=true and one custom output rule (full text in §2).

Verified on: 2026-08-18 (desk sources re-checked; lab run on 0.44.1 the same day) — re-verification against the then-current release happens at publication.

Affects: Anyone consuming Falco alert fields as values — dashboards, filters, and correlation that treat an absent field as a real one.

TL;DR: On Falco 0.44.1 we observed absent metadata rendered in value-like forms — user.loginuid as -1 (the one documented substitution), fd.name as <NA>/null, and one alert carrying a real uid, -1, and null side by side — while the reported forms user.uid = 4294967295 and the path-shaped /<NA> (#1921, #2126, #3246) did not appear in our scenarios and stand on those reports.

Full report: https://whenitruns.substack.com/p/when-falco-runs-out-of-metadata

Reproduction repo: https://github.com/whenitruns/when-falco-runs-out-of-metadata