← Al het nieuws
ARTIKEL
19 oktober 2026 Bijgewerkt op 23 september 2026 2 min leestijd

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
  1. Wat elke tool doet
  2. Waar ze passen, en wat ze niet vervangen
  3. De gewoonte die de moeite waard is

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.

Een grote ronde stalen kluisdeur van een bank, zichtbaar door de ramen van het gebouw
Foto: Beyond My Ken (CC BY-SA 4.0), Wikimedia Commons.

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.