4 Commits

Include renames

Author	SHA1	Message	Date
hermes	7364734713	fix(ci): count the kubeconfig's clusters correctly ... The cluster-count guard I added used `grep -c '"name"'`, which counts LINES. The jsonpath output is a single line, so the count was 1 for a kubeconfig with clusters and 1 for one without - which made the guard reject every kubeconfig: ERROR: the kubeconfig has no cluster entries. The count is now done with `grep -o . | wc -l`, which counts occurrences rather than lines. Tested against both cases: - a real kubeconfig with a stale CA -> the CA is refreshed and kubectl works - a kubeconfig with no clusters -> refuses with a clear message	2026-11-09 12:21:07 +10:00
hermes	3e20b558a5	fix(ci): harden the CA refresh script and add shellcheck to CI ... Round-2 review findings, all low severity. - `curl` now has `--connect-timeout` and `--max-time`, so an unreachable API server fails the job instead of hanging the runner indefinitely. - A guard for a kubeconfig with no cluster entries, or an empty one, with a clear message rather than an opaque kubectl error. - The fingerprint mismatch message now prints both the expected and the actual value, which cuts the time to diagnose the next CA rotation. - `set -euo pipefail` was already there; the script now passes shellcheck clean, and a shellcheck step was added to the CI test job so the operational scripts get the same treatment as the Python code.	2026-11-09 12:15:50 +10:00
hermes	a4b3d40e2d	fix(ci): pin the cluster CA in the repo rather than in a secret ... The CA fingerprint is not a secret. It is a public value that anyone can read straight off the certificate, so pinning it in a Gitea secret was the wrong shape: - A change to it would be invisible - no commit, no review. - Nobody with secret-write access could silently repoint the CI runner at a different CA. It now lives in `scripts/cluster-ca.sha256`, so changing it is a reviewable commit. The script reads it from there, and still accepts an override as its first argument. This also removes the need for a `KUBE_SERVER_CA_FINGERPRINT` secret, which the bot token cannot create anyway - the Actions secrets API is owner-only. The behaviour is unchanged: the CA is fetched over an unverified connection but only USED if it matches the pinned fingerprint, so an intercepted CA is refused. Re-tested against the live API server - the matching fingerprint refreshes the CA and kubectl then works; a wrong one is refused and the stale CA is left in place.	2026-11-09 12:13:27 +10:00
hermes	ce6f5b7962	fix(ci): pin the cluster CA fingerprint instead of trusting a fetched CA ... The review was right on both counts, and both are fixed. 1. MITM. Fetching the CA over an unverified connection (`curl -sk`) and then trusting it is a privilege-escalation hole: the runner holds cluster-admin credentials, so an attacker able to intercept the fetch could hand us a CA of their choosing and then read everything sent over the connection. The CA is now PINNED. It is still fetched over an insecure connection, but it is only USED if its SHA-256 fingerprint matches `KUBE_SERVER_CA_FINGERPRINT`. An intercepted CA will not hash to the pinned value, so it is refused. If the secret is not set, the job fails rather than trusting an unverified CA. 2. The hardcoded cluster name. `kubectl config set-cluster default` creates a NEW cluster entry when the kubeconfig's entry is called something else, leaving the original (and its stale CA) in use. The name is now read from the kubeconfig: `{.clusters[0].name}`. The bash is also moved out of the YAML into `scripts/kube-ca-refresh.sh`, so it can be read, reviewed and tested on its own rather than as a wall of shell inside a workflow file. All three paths are tested against the live API server: - no fingerprint supplied -> refuses, exit 1 - wrong fingerprint -> refuses, exit 1 - correct fingerprint -> refreshes the CA, exit 0, kubectl then works	2026-11-09 12:11:56 +10:00