feat(template-chart): networkPolicy.ingress.ambientMesh, plus its checked CI exception

Gitea #143. A pod cannot be reached inside Istio's ambient mesh unless its
NetworkPolicy lets ztunnel's HBONE tunnel in - ambient explicitly does not
bypass policy enforcement - and 15008 is deliberately no containerPort of the
application, so assertion 2 of ci/run-networkpolicy-test.sh rejected it.

The switch is a named intention rather than a free port list, and it renders
two things that cannot be had separately: 15008/TCP inbound, and - where
probeSources is non-empty - 169.254.7.127/32 as an additional peer, because
inside the mesh the kubelet's probes are redirected away from the worker
node's address. Whoever opens 15008 by hand has not added the probe address,
and the first narrowed probeSources then drops every probe: the pod never
becomes Ready and the symptom reads as a broken application. That is
assertion 4 of the same script, one value further along.

Assertion 2 keeps its edge. It gets ONE named exception for ONE port number,
gated on one value, and it is not granted in the main loop at all - which
renders every chart with the value at its default, so 15008 stays an ordinary
failure there. The free-port variant was design A of #143 and would have
opened the assertion for all 30 charts.

Assertion 7 holds the exception to five things on two renders per chart:
the port and the ipBlock are absent while the switch is off, 15008 is present
while it is on, 15008 is still the ONLY ingress port that is not a
containerPort, and wherever the rule carrying it restricts sources it also
carries the ipBlock. The last one is reachable because these renders apply
ci/networkpolicy/<chart>.yaml, where probeSources is non-empty.

Built into the existing script, as for #136: the exception weakens assertion 2
and belongs beside it - a separate script could go green while the exception
it is paired with is wrong, with nothing connecting the two. The job already
runs over every chart on every pull request.

Found by running it: the policy's name comes from Chart.yaml's name, not from
the directory - template-chart is called "xxx".

Not proven, and said so in values.yaml, the template header and the script's
header: that 15008 alone suffices comes from Istio's documentation, and the
probe-source half reaches no release, because probeSources is empty in every
chart here. No namespace of this cluster carries istio.io/dataplane-mode, so
there is no path on which either could be measured. What is proven is the
render and the assertions.
This commit is contained in:
jklein committed 2026-10-19 17:56:19 +00:00
1 parent 725d046dd9
commit badfaa32cb
4 files changed
+548

No files matched your search

@@ -96,6 +96,24 @@ spec this policy selects.
{{- $probeSources := $np.probeSources | default list }}
{{- $allowedNs := $np.allowedNamespaces | default list }}
{{- $ic := $np.ingressController | default dict }}
{{- /* networkPolicy.ingress - the policy's INGRESS DIRECTION, and not to be
confused with networkPolicy.ingressController one line up, nor with the
chart's top-level .Values.ingress. Three different things whose names
overlap as substrings:
.Values.ingress the Ingress OBJECT this chart renders
.Values.networkPolicy.ingress switches on the policy's inbound side
.Values.networkPolicy.ingressController
the SOURCE SELECTOR for the ingress
controller's pods, a sibling of
networkPolicy.ingress and NO PART OF
IT
Named here because a search for "ingress" matches all three, and one
round of this work already reported ingressController as an inbound
escape hatch on the strength of the substring alone. */}}
{{- $npIngress := $np.ingress | default dict }}
{{- $ambientMesh := $npIngress.ambientMesh }}
{{- $routed := or .Values.ingress.enabled .Values.httpRoute.enabled }}
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
@@ -129,6 +147,29 @@ spec:
- protocol: {{ .protocol | default "TCP" }}
port: {{ .containerPort }}
{{- end }}
{{- if $ambientMesh }}
{{- /* FIRST HALF OF networkPolicy.ingress.ambientMesh. 15008/TCP is
ztunnel's HBONE tunnel, the port every inbound mesh connection
arrives on once the namespace carries istio.io/dataplane-mode.
Istio's own documentation is explicit that ambient "does not and
will never bypass Kubernetes NetworkPolicy enforcement", so
without this port a pod in the mesh is simply unreachable.
It is the one port in this rule that is NOT a containerPort of
the selected pod spec - ztunnel terminates it, not the
application - so ci/run-networkpolicy-test.sh holds a NAMED
exception for exactly this number, gated on exactly this value.
Anything else that is not a containerPort still fails, and so
does 15008 itself while the value is off.
NOT MEASURED, and the chart should not pretend otherwise: that
15008 ALONE suffices comes from Istio's documentation. What has
been measured on this cluster is only which listeners ztunnel
opens. Provable at the first namespace that joins the mesh, and
no namespace carries the label yet. */}}
- protocol: TCP
port: 15008
{{- end }}
{{- if $probeSources }}
{{- /* RESTRICTED, because the operator supplied probeSources. The
kubelet's probes come from the IP of the WORKER NODE running the
@@ -168,6 +209,35 @@ spec:
- ipBlock:
cidr: {{ . | quote }}
{{- end }}
{{- if $ambientMesh }}
{{- /* SECOND HALF OF networkPolicy.ingress.ambientMesh, and the reason
the switch is one value instead of two. Inside the mesh the
kubelet's probes are redirected and no longer arrive from the
worker node's address: they arrive from 169.254.7.127, which is
therefore the probeSources entry nobody would think to add.
The two halves are deliberately inseparable. An operator who
only opens 15008 by hand has a policy that passes every review -
and the moment probeSources is non-empty, every probe is dropped,
the pod never becomes Ready, and the symptom reads as a broken
application rather than as a policy. That is assertion 4 of
ci/run-networkpolicy-test.sh, re-created one value further along.
One switch cannot be set halfway.
Only rendered in this branch, because this is the only branch
with a "from" list at all: with probeSources empty the rule is
open and needs no peer. The IPv6 counterpart
fd16:9254:7127:1337:ffff:ffff:ffff:ffff is deliberately absent -
this cluster is SingleStack IPv4, and an ipBlock of the wrong
family is accepted by the API server and matches nothing.
UNPROVEN IN OPERATION: probeSources is empty in every chart of
this repository (stalwart sets it to the empty list explicitly),
so no release reaches this branch today. What CI proves is its
render, through the overlay in ci/networkpolicy. */}}
- ipBlock:
cidr: 169.254.7.127/32
{{- end }}
{{- else }}
{{- /* NO "from" SELECTOR, WHICH MEANS OPEN - deliberately, and only
inside the cluster, because this port carries no NodePort. The
+11
View File
@@ -45,6 +45,17 @@
}
}
},
"ingress": {
"description": "The policy's INBOUND side. Three names here overlap as substrings and are not the same thing: the top-level ingress is the Ingress OBJECT this chart renders, networkPolicy.ingress is this block, and networkPolicy.ingressController is the SOURCE SELECTOR for the ingress controller's pods - a SIBLING of this block and no part of it.",
"type": ["object", "null"],
"additionalProperties": false,
"properties": {
"ambientMesh": {
"description": "Opens the pod for Istio's ambient mesh; off by default and additive, so the render is byte-identical while it is false. Renders 15008/TCP inbound - ztunnel's HBONE tunnel, which ambient explicitly does not let bypass NetworkPolicy enforcement - AND, where probeSources is non-empty, 169.254.7.127/32 as an additional probe source, because inside the mesh the kubelet's probes are redirected away from the worker node's address. The two halves are inseparable on purpose: whoever opens 15008 by hand has not added the probe address, and the first narrowed probeSources then drops every probe, so the pod never becomes Ready and the symptom reads as a broken application rather than as a policy. Unproven in operation: that 15008 alone suffices comes from Istio's documentation, and no namespace of this cluster carries istio.io/dataplane-mode yet.",
"type": ["boolean", "null"]
}
}
},
"egress": {
"type": ["object", "null"],
"additionalProperties": false,
+56
View File
@@ -272,6 +272,62 @@ networkPolicy:
podLabels:
app.kubernetes.io/name: rke2-traefik
# The policy's INBOUND side. Mind the three names that overlap as substrings,
# because a search for "ingress" matches all of them and they are not the
# same thing:
#
# ingress (top level) the Ingress OBJECT this chart
# renders - host, TLS, className
# networkPolicy.ingress this block: what the policy lets IN
# networkPolicy.ingressController the SOURCE SELECTOR for the controller's
# pods. A SIBLING of this block and NO PART
# OF IT, despite the name.
ingress:
# Opens the pod for Istio's ambient mesh. OFF by default, and additive:
# with it off this chart renders byte for byte as it did before the value
# existed.
#
# WHAT IT RENDERS, and the two halves are the point:
#
# 1. 15008/TCP inbound - ztunnel's HBONE tunnel. Every inbound mesh
# connection arrives on it, and Istio's documentation is explicit that
# ambient "does not and will never bypass Kubernetes NetworkPolicy
# enforcement". Without this port a pod whose namespace has joined the
# mesh is unreachable.
# 2. 169.254.7.127/32 as an additional probe source - but ONLY where
# probeSources is non-empty, because only then does the rule have a
# "from" list at all. Inside the mesh the kubelet's probes are
# redirected and no longer come from the worker node's address.
#
# WHY ONE SWITCH AND NOT TWO. Point 2 is the one nobody thinks of. An
# operator who adds "15008" to a port list by hand writes a policy that
# passes review, and the first time probeSources is narrowed every probe is
# dropped: the pod never becomes Ready and the symptom reads as a broken
# application rather than as a policy. A switch whose halves can only be
# had together cannot be set halfway - which is why this is a named
# intention and not a free port list.
#
# TWO THINGS IT DOES NOT PROVE, and they belong next to the value rather
# than in a commit message:
#
# - That 15008 alone is enough. That comes from Istio's documentation.
# Measured on this cluster is only which listeners ztunnel opens
# ([::]:15008 inbound, plus its own admin and stats ports). Provable at
# the first namespace that joins the mesh; none carries
# istio.io/dataplane-mode yet.
# - That the probe-source half works. probeSources is empty in every
# chart here, so no release reaches that branch. CI proves its render,
# not its effect.
#
# If the policy restricts sources, note that 15008 is restricted with them:
# the port joins the rule that carries the probe port, so it is reachable
# from that rule's peers only. Whether ztunnel needs a peer of its own is
# open - it runs with its own pod IPs in istio-system (measured: no
# hostNetwork on the DaemonSet, Istio 1.30.6), so if one turns out to be
# needed it is expressible as a namespaceSelector plus podSelector and does
# not need an unknowable node-IP CIDR.
ambientMesh: false
egress:
# Additional outbound TCP ports. DNS (UDP and TCP 53) is always allowed and
# has no switch - a knob whose only other setting breaks every name lookup