hermes
a4b3d40e2d
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.
18 lines
911 B
Plaintext
18 lines
911 B
Plaintext
# SHA-256 fingerprint of the cluster's API server CA (the k3s server-ca.crt).
|
|
#
|
|
# This is a PUBLIC value, not a secret - it can be read straight off the
|
|
# certificate. It lives in the repo rather than in a Gitea secret so that
|
|
# changing it is a reviewable commit, and so nobody with secret-write access
|
|
# can silently repoint the CI runner at a different CA.
|
|
#
|
|
# The deploy job fetches the cluster's CA over an unverified connection and
|
|
# compares its fingerprint against this value. A CA that does not match is
|
|
# refused, so an attacker able to intercept the fetch cannot substitute
|
|
# their own.
|
|
#
|
|
# To refresh it after a legitimate CA rotation:
|
|
# openssl x509 -in /var/lib/rancher/k3s/server/tls/server-ca.crt # -noout -fingerprint -sha256
|
|
# and update the line below (colons are stripped before comparison, so either
|
|
# format works).
|
|
d23a17bb9c5f7c66d15e15635d6bb928e3a34f38142705e4e6516075a5f35907
|