[Backport release-1.6] fix(networking): prevent webhook admission outages during namespace churn - #4052

hack/helm-unit-tests.sh finds suites by probing `make -n test` per
package and skips any package without that target, so this package's two
suites had never run in CI -- including the port agreement guard, whose
whole purpose is to catch a drift that fails open. The target is declared
.PHONY because nothing else declares it: hack/package.mk writes its
.PHONY as a variable assignment rather than a target, so a path named
`test` next to the Makefile would make the target up to date and skip the
recipe silently.

The suites now pin the two-spec shape rather than the old single-spec
one, and add what review asked for: one deny rule per spec whose
destination is a selector Cilium can actually resolve (the toServices
regression renders as a plausible ingressDeny and would otherwise pass),
the peer of the target-side pod deny, the collision-safe cluster-scoped
name, and a capability suite for the render-nothing branch.

Checked by mutation rather than by revert. Substituting
`fromEntities: [all]` for the target-side pod peer, dropping that rule
outright, replacing the source-side toEndpoints with a toServices
destination, pointing the deny at a port nothing serves, and removing the
capability guard each redden exactly the assertions that name them and
nothing else. `matchRegexRaw` and `notMatchRegexRaw` are not used --
helm-unittest 1.0.3 ignores both.

Assisted-By: LLM
Signed-off-by: Myasnikov Daniil <[email protected]>

…thing

The kube-ovn-webhook deny names the webhook's backend port only, and that
covers a pod dialling the Service ClusterIP for one reason: Cilium
translates a service to its backends before it enforces egress policy.
That ordering holds only while Cilium performs the DNAT, and the only
thing making it so is `cilium.kubeProxyReplacement`, true here against an
upstream chart default of "false". Flip it and the ClusterIP path to
/mutate-pods reopens while the backend deny keeps working: nothing fails,
nothing is logged, and the rendered policy is unchanged.

Two halves of a guard. tests/kube_proxy_replacement_test.yaml asserts the
value on the RENDERED cilium ConfigMap key -- not on .Values, so an
upstream bump that renames the key or stops honouring the override reds
too -- once per variant valuesFiles combination that
packages/core/platform/sources/networking.yaml installs, plus the
defaults case that guest clusters use. Nothing in this repo can observe a
live cluster's values, so an operator override in the field is caught
only by templates/kube-proxy-replacement-beacon.yaml, a status ConfigMap
that renders whenever the value is not true.

A beacon and not a fail(): whether Cilium without kube-proxy replacement
is a supported cozystack configuration is a platform decision, and
refusing to render the cluster's CNI over a weakened defence-in-depth
control is not this chart's call. It follows the -awaiting-etcd ConfigMap
in packages/apps/kubernetes/templates/cluster.yaml.

The package also gains a `test` target, because hack/helm-unit-tests.sh
finds suites by probing `make -n test` and silently skips a package
without one -- so without this the pin above would never run. Declared
.PHONY because hack/package.mk writes its own .PHONY as a variable
assignment and therefore declares nothing.

Mutation-proven: setting the value false and deleting the umbrella key
each red all six variant pins plus the no-beacon case, and neutering the
beacon's condition reds exactly the two beacon cases.

Assisted-By: LLM
Signed-off-by: Myasnikov Daniil <[email protected]>

system/ingress-nginx is owned by cozystack.ingress-application, whose
derived suite name is `ingress` -- not a suite, so the intersection at
the bottom of select-e2e.sh dropped it and an ingress-only change ran
only the four tenant-Kubernetes suites. The host cluster's own Ingress
coverage lives in the gateway suite, which was therefore never selected
by a change to the chart it exercises.

cozystack.ingress-nginx owns the same path but cannot carry the mapping
on this branch: the caller maps only *-application sources plus
external-dns, so a plain system source never reaches src_to_suites at
all. The comment says so, because the obvious-looking second arm would
be dead code.

The new bats case is mutation-proven -- restoring the derived `ingress`
name reds it and nothing else -- and sets no EXIT trap, because
cozytest.sh runs every @test as a function in one shell, so a test-level
trap outlives its test and only the last one registered ever fires.

Assisted-By: LLM
Signed-off-by: Myasnikov Daniil <[email protected]>

Regression for #3983, which reported fail-closed admission webhooks
becoming unreachable from the API server while an unrelated namespace was
deleted. The mechanism is not confirmed -- the errno in that report
cannot come from a policy denial, and namespace deletion churns service
backends as well as Cilium identities -- so the case asserts the property
the issue is about, that both webhooks still admit across a namespace
deletion, rather than claiming to reproduce a cause. Both admission paths
are exercised immediately after the deletion with no retry, because a
retry would paper over the window this exists to catch.

The pod in the churned namespace is what makes it a churn test rather
than a smoke test: k8s:io.kubernetes.pod.namespace is an
identity-relevant label, so a pod in a brand-new namespace allocates a
new Cilium identity and deleting the namespace releases it. An empty
namespace drives no identity churn at all.

Availability is asserted BEFORE the churn, as a precondition with its own
message, because every apply in the case passes through both fail-closed
webhooks -- so a cluster whose webhooks were already down fails here in a
way that reads exactly like the outage under test. Coordinates come from
the webhook registrations themselves, every registration of each, since
one being down aborts the apply.

Carried unchanged from the upstream change: both webhooks it names exist
on this branch and register under the same names.

Assisted-By: LLM
Signed-off-by: Myasnikov Daniil <[email protected]>

…port

Companion to the churn case above: that one proves the webhook stays
available, this one proves it is still unreachable from pods, which is
the property the policy exists for.

Rewritten against kube-ovn-webhook rather than ingress-nginx, because
this branch ships no ingress-nginx admission policy for the upstream case
to measure -- see the PR description. The substance is the same and the
structure follows it.

The port-scoping assertion is what earns the case. The policy previously
expressed the Service-frontend deny with `toServices`, which Cilium
resolves only in ALLOW rules, so the deny reached the datapath with an
empty L3 selector that Cilium reads as a wildcard when the rule carries
toPorts: "deny this Service on 8443" became "deny every destination on
8443" for every pod in the cluster. Every rendered-YAML assertion in the
package suites passed on that policy, and so would the two deny verdicts
here. So the case stands up its own listener on the denied port and
requires that to stay reachable, on both its ClusterIP and its pod IP.

Measured on a live kube-ovn+cilium cluster, three ways. With no policy
installed the two deny verdicts report BUG, so they are not vacuous. With
the policy installed all four verdicts pass, including the ClusterIP
path, which is the source-side rule's claim about Cilium translating a
service before enforcing egress policy. With the `toServices` form
substituted, the two listener verdicts report BUG while the two deny
verdicts still pass -- so the positive control is the only thing in the
change that separates a scoped deny from a cluster-wide egress outage on
that port, and it does separate them.

The namespace choice is load-bearing rather than tidiness, and the header
carries the measurement: from a tenant namespace both the webhook and an
unrelated cozy-kubeovn Service are unreachable with no policy installed
at all, because packages/apps/tenant ships a default-deny egress policy
per tenant that admits only namespaces carrying tenant.cozystack.io/*. A
deny verdict measured from there would hold with the policy uninstalled.
The case therefore creates its own cozystack.io/system namespace, where
the same cluster reached all four destinations before the policy went on.

Every verdict is gated on ready EndpointSlice backends before, during and
after the probe and on the webhook pods neither restarting nor being
replaced, because "denied by policy" and "no backend to route to" are the
same observation from inside a probe. Anything that leaves the question
undecidable fails as a setup failure rather than as a verdict.

Assisted-By: LLM
Signed-off-by: Myasnikov Daniil <[email protected]>