3 Commits

Include renames

Author	SHA1	Message	Date
jklein	de995d0f53	Revert the enforcement experiment, and record what it measured ... Both experiments are in, and together they answer the question the scope of #5 rests on - with an answer that is not the one the plan assumed. MEASURED, run 888 on this branch: Install-test cyberchef SUCCESS, 1m9s probe port 8080 restricted to 192.0.2.11/32, which cannot be the k3d node's address Install-test outline FAILURE, 5m59s DNS egress rule removed, so "postgres" and "redis" do not resolve and /_health cannot pass So: POLICIES ARE ENFORCED in the install-test - outline's pod never became Ready and rollout status timed out after six minutes, which is the net this rollout needs. But THE KUBELET'S PROBE TRAFFIC IS EXEMPT from policy in k3s: cyberchef became Ready in 69 seconds with its probe port restricted to an address no probe can come from. What that changes, and what it does not: - The plan's claim was "a policy that blocks the probe path makes the install-test red". That is NOT true here, and it is now measured rather than assumed. The install-test's net is for EGRESS and for anything the application itself needs, not for the probe path. - It does not undermine the rollout, because this convention never restricts a probe port by default - the rule is rendered without a "from" until an operator sets probeSources. The trap CI cannot see is therefore not triggered by this PR; it is triggered by a deliberate narrowing, which is what the NOTES.txt sentence and ci/run-networkpolicy-test.sh's fourth assertion exist for. - It raises the stakes for the render assertions. A wrong ingress port - the NodePort mistake above all - would leave the pod Ready in CI (probes exempt) and no ingress controller runs there either, so nothing in the pipeline would notice. That failure is caught mechanically by assertion 2 or not at all. - And it says nothing about the production cluster, whose CNI is Calico, not k3s'. There, probe traffic is subject to policy, which is exactly why the default stays open. Part of #5	2026-10-14 14:17:49 +00:00
jklein	813c923070	test(outline): does the install-test enforce policies at all? [EXPERIMENT, reverted next] ... The first experiment did not settle it. Restricting cyberchef's probe port 8080 to 192.0.2.11/32 - an address that cannot be the k3d node's - left the install-test GREEN, which has two very different causes: either k3s' policy controller exempts the kubelet's probe traffic (good news for this convention, whose default leaves the probe port open anyway), or it enforces nothing at all (no net under this rollout). This separates them without touching a probe. Outline's egress rule for DNS is removed, so the pod cannot resolve "postgres" or "redis" - and all three of its probes hit /_health, which checks both stores. Expected: RED, which proves egress is enforced. Green means nothing is enforced in CI and the scope has to be renegotiated. Reverted in the next commit either way. Part of #5	2026-10-14 14:07:26 +00:00
jklein	77b978d669	feat(outline)!: NetworkPolicy, on by default ... Major, as every chart in this rollout is. Inbound 3000 only; outbound DNS plus 5432, 6379 and 443. Those three egress ports are the STANDARD ones and not the configured ones, which is this chart's real limitation and is written into values.yaml, the template header and NOTES.txt rather than left to be discovered: Outline's database, Redis and OIDC provider all arrive as connection URLs inside 1Password items that the chart never parses, so it cannot know where they listen and cannot validate a guess. A dependency on another port is blocked, and because all three probes hit /_health - which checks Postgres and Redis - the symptom is a pod that never becomes Ready rather than an error anyone reads. networkPolicy.egress.extraPorts is the escape hatch. That same property is what makes this chart the right place for the enforcement experiment in the next commit. Also reverts the cyberchef fixture from the first experiment: with the probe port restricted to an address that is not the node's, the install-test went GREEN, so the claim that it catches a blocked probe path does not hold as written. The next commit establishes whether policies are enforced in CI at all. Part of #5	2026-10-14 14:07:06 +00:00