refactor(secrets): drop the unused barman-cloud-creds #677
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: konairius/homelab#677
Reference in New Issue
Block a user
Drei ExternalSecrets synchronisieren ein Secret, das nichts liest. Aus drei Richtungen belegt statt vermutet:
hetzner-s3-creds.barmanObjectStore-Form — alle laufen über das barman-cloud-Plugin gegen eine ObjectStore-CR.barman-cloud-creds.Vermutlich ein Rest aus der Zeit vor der Plugin-Migration, als die Inline-Konfiguration ein Secret dieses Namens las.
Das ist nicht nur Unordnung.
seed/{authentik,immich,paperless}/barman-credstragen eine Hetzner-S3-Zugangsdatei, die nicht die benutzte ist: Fingerabdruckc2c5cf3e…gegen87954b64…des produktiven Pfads, die drei Kopien untereinander identisch. Ein gültiger Schlüssel ohne Verbraucher ist Angriffsfläche ohne Gegenwert — falls es ein eigener S3-Key ist, gehört er bei Hetzner widerrufen. Das kann nur ein Mensch, und unsere Kopien zu löschen erledigt es nicht.Wichtig zum Ablauf: die Manifeste zu entfernen entfernt die Objekte nicht. Alle drei tragen
kustomize.toolkit.fluxcd.io/prune: disabledaus den seed→app-KS-Übergaben, Flux überspringt sie beim GC also absichtlich. Nach dem Merge müssen die ExternalSecrets, ihre Secrets und die drei OpenBao-Pfade ausdrücklich gelöscht werden — sonst bleiben sie live und verwaist, was schlechter ist als sie deklariert zu lassen. Das mache ich danach, mit derselben Fingerabdruck-Prüfung wie bei den hetzner-creds.Die OpenBao-Pfade bleiben bis dahin bewusst stehen: sie vorher zu löschen hieße nur, drei ExternalSecrets gegen einen nicht mehr existierenden Schlüssel scheitern zu lassen.
Nebenbefund beim Nachsehen, wohin Barman überhaupt sichert: der Kommentar in
prometheusrule-cnpg-backup.yamlbegründet den fehlenden Backup-Alters-Alarm damit, dass die Backup-CRs binnen einer Minute gelöscht würden (#522). Das trifft nicht mehr zu — CRs vom 26. und 27.08. liegen noch da. Die Metrikcnpg_collector_last_available_backup_timestampist trotzdem überall 0, vermutlich weil der Plugin-WegCluster.status.lastSuccessfulBackupnicht befüllt (bei allen sieben<none>). Wer den Kommentar liest, repariert sonst die CR-Aufbewahrung und wundert sich. Separat zu klären.Three ExternalSecrets synced a Secret that nothing reads. Established rather than assumed, from three directions: every live ObjectStore names hetzner-s3-creds, no CNPG Cluster uses the legacy inline barmanObjectStore (all seven run the barman-cloud plugin against an ObjectStore CR), and no pod in the cluster mounts barman-cloud-creds. They are almost certainly left from before the plugin migration, when the inline configuration read a Secret of that name. Worth stating plainly because it is not merely untidy: seed/{authentik,immich, paperless}/barman-creds hold a Hetzner S3 credential that is NOT the one in use. Fingerprint c2c5cf3e against 87954b64 for the live hetzner-s3 path, with the three copies identical to each other. A valid key with no consumer is exposure without benefit, so if it is a distinct S3 key it wants revoking at Hetzner, which only a human can do — deleting our copies does not. Removing the manifests does NOT remove the objects. All three carry kustomize.toolkit.fluxcd.io/prune: disabled from the seed->app-KS handoffs, so Flux skips them during garbage collection by design. The ExternalSecrets, their Secrets and the three OpenBao paths have to be deleted explicitly after this merges; git alone leaves them live and orphaned, which is worse than leaving them declared. The OpenBao paths deliberately stay until then. Deleting them first would leave three ExternalSecrets failing to sync against a key that no longer exists, for no gain.🤖 Automated review — model
CLI default(complexity: complex), commit2f3d95265642ed0439b7d192406a2c3cbc064fc1.Summary
Removes three unused
barman-cloud-credsExternalSecretmanifests (authentik, immich, paperless) and theirkustomization.yamlentries. Pure deletion (0 additions / 57 deletions, 6 files). I verified the PR's central claim directly in the checkout: all three CNPG clusters use the barman-cloud plugin (barmanObjectName→ anObjectStoreCR) whoses3Credentialsall point athetzner-s3-creds, notbarman-cloud-creds, and a repo-wide grep forbarman-cloud-creds/barman-credsfinds no other live reference — only a historical mention inkubernetes/MIGRATION-sops-openbao.md. No blocking issues.🟡 Suggestions
kustomize.toolkit.fluxcd.io/prune: disabled(e.g.kubernetes/apps/authentik/barman-creds-externalsecret.yaml:14before deletion). The author states the follow-up cleanup (ExternalSecrets, Secrets, and the three OpenBaoseed/{authentik,immich,paperless}/barman-credspaths, plus revoking the Hetzner key if it's a distinct credential) will happen in a separate step. Worth confirming that follow-up actually happens soon after merge — until then the orphaned Secrets/OpenBao entries remain live with no manifest tracking them, which is a bit easier to lose track of than before.prometheusrule-cnpg-backup.yaml(justifying the missing backup-age alert, referencing #522) is now stale, and thatcnpg_collector_last_available_backup_timestampreads 0 on all seven clusters. Not part of this diff and not blocking here, but worth its own follow-up issue so it isn't lost.Tests
No tests apply — this is a pure Kustomize resource-list/manifest deletion with no logic change. Correctness here is best verified by confirming nothing references the removed name, which I did via grep (only hit: the migration doc, non-live) and by reading each cluster's
objectstore.yaml/cluster.yamlto confirm the actual credential path.Recommendation
Looks reasonable — no blocking issues; comments above are optional.
Korrektur zu meinem Text oben:
barman-cloud-credsist kein Hetzner-Key. Das war eine Vermutung, die ich als Feststellung formuliert habe.Das
REGION-Feld — kein Geheimnis — sagtgarage, während die produktive Zugangsdateifsn1trägt. Und der Kommentar inauthentik/objectstore.yamlordnet es ein: „Offsite Hetzner Object Storage (fsn1) — replaces Garage on nas-1."Es ist also eine Zugangsdatei für die Garage-Instanz auf nas-1, die von Hetzner abgelöst wurde. Im Cluster läuft kein Garage — kein Pod, kein Namespace.
Was daraus folgt:
Am Aufräumen selbst ändert das nichts: die drei ExternalSecrets sind unbenutzt, unabhängig davon, wohin sie zeigen. Es ändert nur, was danach noch zu tun wäre — und die Antwort ist möglicherweise: nichts.