feat!: a NetworkPolicy in every chart, on by default #133
@@ -28,6 +28,30 @@ 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