jklein
77b978d669
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
41 lines
2.0 KiB
YAML
41 lines
2.0 KiB
YAML
# cyberchef: stateless, no secrets.
|
|
#
|
|
# THIS CHART IS INSTALLED IN GATEWAY MODE, NOT IN INGRESS MODE (Gitea #114),
|
|
# and that is a deliberate trade, because the install-test runs exactly ONE
|
|
# configuration per chart and the two modes are mutually exclusive.
|
|
#
|
|
# What is given up: the Ingress of this one chart is no longer installed
|
|
# anywhere. That costs little. An Ingress is a built-in, GA type whose schema
|
|
# the API server has validated for a decade, k3d's own ingress controller is
|
|
# traefik while this chart asks for the class "nginx", so nothing ever routed
|
|
# through it here either - the install only ever proved "the API server
|
|
# accepted an Ingress". And it keeps being proved, twenty times over, by every
|
|
# other chart in the repo plus `helm lint --strict`, which renders this chart's
|
|
# DEFAULTS, i.e. Ingress mode, on every pull request.
|
|
#
|
|
# What is gained: a real HTTPRoute, applied against the real Gateway-API CRDs
|
|
# (see ci/gateway-api-crds.sh), which is a CRD whose schema nothing else in
|
|
# this repository has ever exercised. That is where a malformed parentRefs or
|
|
# backendRefs is actually caught.
|
|
#
|
|
# Still NOT proved by this, and it cannot be: that traffic flows. No Gateway
|
|
# controller runs in k3d, so nothing routes. The install-test proves the object
|
|
# is schema-valid and the pod becomes Ready; ci/run-httproute-match-test.sh
|
|
# proves the route points at a Service the same render creates.
|
|
ingress:
|
|
# The hostname is read by the HTTPRoute too (httpRoute.hostnames is empty, so
|
|
# it falls back to ingress.domain) - it is the release's public name, not an
|
|
# Ingress switch.
|
|
domain: cyberchef.ci.local
|
|
enabled: false
|
|
httpRoute:
|
|
enabled: true
|
|
# The Gateway does not exist in the CI cluster, and it does not need to: a
|
|
# parentRef is resolved by the Gateway controller, of which there is none
|
|
# here, so the reference is stored as written. What the real CRDs DO validate
|
|
# is its shape.
|
|
parentRefs:
|
|
- name: ci-gateway
|
|
namespace: default
|
|
sectionName: https
|