Nodig voor de werking van de site (login, voorkeuren, beveiliging). Altijd aan.
SOPS en Sealed Secrets: houd plaintext uit Git voor MSP Kubernetes
SOPS versleutelt configuratiebestanden voordat ze in Git belanden; Sealed Secrets versleutelt een Kubernetes Secret zodat alleen het doelcluster het kan ontsleutelen. Samen dichten ze het GitOps-secretsgat.
In dit artikel
Twee gevestigde opensourceprojecten, getsops/sops en bitnami/sealed-secrets, dichten een veelvoorkomend gat in GitOps-pipelines: secretwaarden uit plaintext in versiebeheer houden terwijl het juiste cluster ze nog steeds automatisch kan ontsleutelen.

Wat elke tool doet
SOPS, met ongeveer 22.000 GitHub-sterren, versleutelt configuratie- en secretbestanden voordat ze worden gecommit, met age, PGP of cloud KMS-achtige backends. Toegang tot ontsleuteling wordt bepaald door wie de sleutel bezit, los van wie leestoegang tot de repository heeft. Sealed Secrets, onderhouden met ongeveer 9.000 sterren, kiest een clustergebonden aanpak: een client-side tool versleutelt een Kubernetes Secret tegen de publieke sleutel van het doelcluster en produceert een SealedSecret custom resource die veilig in Git kan worden opgeslagen. Alleen de in-cluster controller, die de bijbehorende private sleutel bezit, kan er weer een bruikbaar Secret van maken.
Waar ze passen, en wat ze niet vervangen
Samen gebruikt dekken de twee tools complementaire helften van hetzelfde probleem: SOPS beschermt willekeurige bestanden voordat ze Git bereiken, en Sealed Secrets beschermt het specifieke geval van een Kubernetes Secret gebonden aan één cluster. Geen van beide vervangt credentialrotatie, role-based access control of netwerkisolatie -- een SealedSecret is veilig om te committen, maar het blijft ciphertext voor een specifieke ontsleutelgrens en geen vervanging voor least-privilege-toegang. Praktische hygiëne is hier belangrijk: beperk wie een ontsleuteloperatie in CI mag uitvoeren, print nooit ontsleutelde waarden naar buildlogs en monitor de gezondheid van de Sealed Secrets-controller en het rotatieschema van zijn sealing-sleutel. Valideer elke wijziging aan een van beide pipelines in een niet-productiecluster voordat je die uitrolt.
De gewoonte die de moeite waard is
De waarde van beide tools is de controle die ze afdwingen -- een build die faalt wanneer een plaintext secret in een commit sluipt, of een ontsleutelgrens die slechts één cluster kan overschrijden -- niet de naam van de tool op een slide. Pin versies, houd de versleutelde bestanden reviewbaar in pull requests en behandel sleutelrotatie als een geplande taak in plaats van incidentrespons.
Bronnen: getsops/sops, bitnami/sealed-secrets.