2 Commits

Include renames

Author	SHA1	Message	Date
jklein	96c23b7912	feat(keycloak)!: NetworkPolicy, on by default - the full convention in one chart ... Major. This is the richest policy of the sweep and the one with the largest blast radius, and it is the only chart whose three ports fall into three different classes - so it is where the convention is visible in full: http (8080) NOT addressed by any probe, so it CAN be restricted by source, and it is: own namespace, allowedNamespaces, and the ingress controller. The only real inbound restriction in this whole rollout, possible only because the probes use a different port. management (9000) the port all three probes address, so it stays open inside the cluster. That matters here specifically: this surface carries health and metrics UNAUTHENTICATED, and "no Ingress" was its only protection before this object. The policy turns "anything that can route to the pod" into "anything inside the cluster"; probeSources closes the rest. jgroups (7800) the cluster bus, restricted to the pods this policy itself selects - a podSelector with no namespaceSelector, the narrowest rule the object can express. All four port numbers come from keycloak.settings rather than being written down twice, so moving keycloak.ports.http moves the policy with it. And the egress rule for the database is the CONFIGURED port, keycloak.db.port - this is the one chart in the sweep that does not have to guess, because its database port is a value instead of a field inside an opaque secret. The outbound cluster-bus rule is not a duplicate of the inbound one: policyTypes lists Egress, so a replica dialling its peer is subject to this policy too, and without it the bus would be open inbound and blocked outbound - a cluster that never forms, with two nodes that each look healthy. THE BLAST RADIUS IS WRITTEN INTO THE CHART, because nothing in CI can catch it: this release is the cluster's identity provider, no ingress controller runs in the install-test, and the probes use 9000 - so the pod becomes Ready whether or not the http rule is right. NOTES.txt therefore asks for two checks after the first upgrade: log in, and look at whether any consumer uses the in-cluster Service address instead of the public issuer URL (those namespaces need allowedNamespaces). Not allowed at all, and named as the likely first surprise: SMTP, because the mail server is configured per realm where the chart cannot see it. The test's overlay guard is tightened in the same commit, and keycloak is why. It counted any source-restricted rule, and this chart restricts two of them in its own defaults - so the guard would have been satisfied while the probe branch, the only branch an overlay exists to reach, was never rendered. It now counts restricted PROBE rules. All twelve failure paths were re-run against the change. Part of #5	2026-10-14 14:30:30 +00:00
jklein	36bcfd3b11	feat(ci): assert every rendered NetworkPolicy against its own render ... The part that carries the rollout of Gitea #5. 29 charts get a policy that is on by default, and every way one of them can be wrong is SILENT: the API server accepts a policy that filters nothing just as readily as one that filters everything, and neither is a render error, so neither the build nor a rollout sees it. ci/run-networkpolicy-test.sh holds every rendered NetworkPolicy against the pod specs, probes and Services of the SAME render: 1. the podSelector really matches a pod of that render - otherwise the object sits in the namespace, is listed by kubectl, reads as a boundary and filters nothing, usually because a label was renamed in another file; 2. every INGRESS port is a containerPort of the selected pods, which catches the NodePort mistake mechanically. Egress ports are deliberately excluded: an egress port belongs to the DESTINATION, and comparing it would fail every chart that reaches a database; 3. no ingress rule allows every source by accident. "from: []" always fails - it allows everything while reading as a restriction. A MISSING "from" is the documented open form and is accepted only where the render justifies it: every port of the rule is addressed by a network probe, or published by a NodePort Service. That is stricter than the plan's wording, which banned both forms, and it had to be, because the precedents use the second one on purpose; 4. the probe path. For every port a NETWORK probe addresses, the policy either leaves it unrestricted or the chart offers networkPolicy.probeSources AND says in NOTES.txt that a list missing the node's IP leaves the pod permanently un-Ready. exec probes are excluded by design - they run inside the container and put no packet on the network, which is exactly why valkey and minecraft-server can restrict their port by source with no probeSources at all. Two guards beyond the four: a chart that renders NO policy fails, because that is how this issue decayed in the first place - garage and keycloak were both created after #5 and both arrived without one. And a "#" comment inside a rendered policy fails, because it is part of the object and is shipped to the cluster. Helm is the parser through ci/yaml2json, as in the other render tests: the runners have neither pyyaml nor yq, and a hand-written parser could read nothing, find nothing and leave this green over a chart it never looked at. Every failure path was run, not just the green ones, and one of them earned its keep immediately: the probeSources check was a substring test, so a chart whose key had been deleted while the comment above it still discussed the value passed. It now looks for the key. Part of #5	2026-10-14 13:56:06 +00:00