jklein
d3ef3729f8
Validate Helm Charts / Detect changed charts (pull_request) Successful in 3s
Validate Helm Charts / Resource quantities (pull_request) Successful in 12s
Validate Helm Charts / Selector match (pull_request) Successful in 12s
Validate Helm Charts / HTTPRoute match (pull_request) Successful in 11s
Validate Helm Charts / Bump level (pull_request) Successful in 4s
Validate Helm Charts / YAML scalars (pull_request) Successful in 11s
Validate Helm Charts / NetworkPolicy (pull_request) Failing after 11s
Validate Helm Charts / Build cyberchef (pull_request) Successful in 7s
Validate Helm Charts / Trivy config cyberchef (pull_request) Successful in 18s
Validate Helm Charts / Build template-chart (pull_request) Successful in 7s
Validate Helm Charts / Trivy config template-chart (pull_request) Successful in 17s
Install-test / Install-test cyberchef (pull_request) Successful in 1m4s
Validate Helm Charts / Install-test (pull_request) Successful in 1m4s
The scope of Gitea #5 - 29 charts at once, default on - rests on the claim that the install-test enforces policies, so a policy that blocks the probe path goes red in CI rather than silently in production. k3d is created without --disable-network-policy, but a flag read off a workflow file is not evidence. This commit restricts cyberchef's probe port 8080 to 192.0.2.11/32, an RFC 5737 documentation address that cannot be the k3d node's IP. The kubelet probes from the node's own address, so they are dropped and the pod must never become Ready. Expected: the cyberchef install-test goes RED on rollout status. If it goes green, policies are not enforced in CI and the scope has to be renegotiated. Reverted in the next commit either way. Part of #5
65 lines
3.1 KiB
YAML
65 lines
3.1 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
|
|
|
|
# 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
|
|
# 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
|