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
This commit is contained in:
6 files changed
+385
-25
No files matched your search
@@ -28,30 +28,6 @@ ingress:
|
||||
# Ingress switch.
|
||||
domain: cyberchef.ci.local
|
||||
enabled: false
|
||||
|
||||
# TEMPORARY - THIS COMMIT IS AN EXPERIMENT AND IS REVERTED IN THE NEXT ONE.
|
||||
#
|
||||
# The whole scope of Gitea #5 rests on one claim: that the install-test
|
||||
# ENFORCES NetworkPolicies, so a policy which blocks the probe path goes red in
|
||||
# CI instead of silently in production. k3d is created without
|
||||
# --disable-network-policy, so k3s should bring its policy controller - but
|
||||
# "should" read off a flag is not evidence, and 29 charts are about to be
|
||||
# switched over on the strength of it.
|
||||
#
|
||||
# So: 192.0.2.11/32 is a documentation address (RFC 5737 TEST-NET-1). It is
|
||||
# NOT the k3d node's IP and cannot be. Setting it restricts cyberchef's probe
|
||||
# port 8080 to that one source, which means the kubelet's probes - which come
|
||||
# from the node's own address - are dropped.
|
||||
#
|
||||
# EXPECTED: the pod never becomes Ready and `kubectl rollout status` times out,
|
||||
# i.e. the install-test for cyberchef goes RED.
|
||||
#
|
||||
# If it goes GREEN instead, policies are not enforced in CI, the net under this
|
||||
# rollout does not exist, and the scope has to be renegotiated rather than
|
||||
# pushed through.
|
||||
networkPolicy:
|
||||
probeSources:
|
||||
- 192.0.2.11/32
|
||||
httpRoute:
|
||||
enabled: true
|
||||
# The Gateway does not exist in the CI cluster, and it does not need to: a
|
||||
|
||||
Reference in new issue
Block a user