Gitea #143, maintainer's instruction. The HBONE port and the redirected probe
source are ISTIO CONSTANTS, not standards, so they move from template literals
into values with documented defaults - an operator can then correct them when
Istio changes a number, without waiting for a chart release.
One object under one "enabled", so the two halves still cannot be set
separately; two values could drift apart, which is what this design exists to
prevent. Every read is null-safe (#99), so a deleted object or one carrying
only "enabled: true" falls back to the defaults declared here rather than
dereferencing nil - the defect #136 shipped one value away.
Provenance now written on each constant: 15008 is Istio's HBONE port, not
IANA-registered for this and unknown to Kubernetes; 169.254.7.127 is link-local
(RFC 3927, never routed), its IPv6 counterpart carries the same digits plus
1337, and neither the NetworkPolicy API nor the kubelet knows the address -
only Istio's data plane rewrites the probe source onto it. Both read for
ztunnel 1.30.6, and a change in either fails silently.
The exception in ci/run-networkpolicy-test.sh stays pinned to the numbers that
test names, and additionally asserts this chart declares the same defaults -
never "whatever the value says", which would let a mistyped port in through a
configurable field.
No version change: nothing is published yet, the default is still off, and the
render at defaults is byte-identical - re-diffed against origin/main.
Gitea #143. Additive, default false, so the render is byte-identical to the
previous release - proven by diffing both renders rather than asserted.
Switched on it adds 15008/TCP, ztunnel's HBONE tunnel, to the rule carrying
the probe port, and - inside that rule's source-restricted branch -
169.254.7.127/32, the address the kubelet's probes arrive from once the pod is
in the mesh. The two halves are one value because the second is the one nobody
thinks of: 15008 added by hand leaves a policy that passes review and drops
every probe the first time probeSources is narrowed.
Minor, not major: additive value, unchanged default, unchanged render.
Major, as every chart in this rollout is: networkPolicy.enabled defaults to
true, so the object reaches running releases on the next upgrade.
The simplest policy of the sweep, and the one to read first. CyberChef is a
static web app - nginx serves files, the recipes run in the visitor's browser,
the pod holds no state and calls nothing - so what the policy buys is the two
CEILINGS rather than any source restriction: inbound is capped at 8080, the
single port the pod declares, and outbound at DNS, which is as tight as the
object goes without breaking name resolution.
The 8080 rule carries no source selector by default, and that is deliberate
rather than an oversight: 8080 is the port all three probes address, and the
kubelet probes from the IP of the worker node running the pod, which no chart
can know. Guessing it wrong leaves the pod permanently un-Ready, a symptom that
reads as a broken application. Narrowing it is networkPolicy.probeSources, and
the restricted branch then also carries the ingress controller - measured as
the rke2-traefik DaemonSet in kube-system, which serves this chart's HTTPRoute
as well, since the same Traefik backs the Gateway API here.
Part of #5
jklein