SOPS e Sealed Secrets: tenere il plaintext fuori da Git per Kubernetes MSP

Due progetti open source consolidati, getsops/sops e bitnami/sealed-secrets, coprono una lacuna comune nelle pipeline GitOps: mantenere i valori dei segreti fuori dal testo in chiaro nel controllo di versione, consentendo comunque al cluster giusto di decifrarli automaticamente.

Cosa fa ciascuno strumento

SOPS, con circa 22.000 stelle su GitHub, cifra i file di configurazione e dei segreti prima che vengano committati, usando backend di tipo age, PGP o KMS cloud. L'accesso alla decifratura è controllato da chi detiene la chiave, separatamente da chiunque abbia accesso in lettura al repository. Sealed Secrets, mantenuto con circa 9.000 stelle, adotta un approccio legato al cluster: uno strumento lato client cifra un Secret Kubernetes con la chiave pubblica del cluster di destinazione, producendo una risorsa personalizzata SealedSecret che è sicura da archiviare su Git. Solo il controller nel cluster, che possiede la chiave privata corrispondente, può trasformarla di nuovo in un Secret utilizzabile.

Dove si inseriscono e cosa non sostituiscono

Usati insieme, i due strumenti coprono metà complementari dello stesso problema: SOPS protegge file arbitrari prima che arrivino su Git, e Sealed Secrets protegge il caso specifico di un Secret Kubernetes vincolato a un solo cluster. Nessuno dei due sostituisce la rotazione delle credenziali, il controllo degli accessi basato sui ruoli o l'isolamento di rete: un SealedSecret è sicuro da committare, ma è comunque testo cifrato per uno specifico confine di decifratura, non un sostituto dell'accesso con privilegi minimi. L'igiene pratica qui conta: limita chi può eseguire un'operazione di decifratura in CI, non stampare mai valori decifrati nei log di build e monitora lo stato del controller di Sealed Secrets e il suo programma di rotazione delle chiavi di cifratura. Valida qualsiasi modifica a entrambe le pipeline in un cluster non di produzione prima di distribuirla.

L'abitudine che vale la pena adottare

Il valore di entrambi gli strumenti è il controllo che impongono: una build che fallisce quando un segreto in chiaro si insinua in un commit, o un confine di decifratura che solo un cluster può attraversare, non il nome dello strumento su una slide. Fissa le versioni, mantieni i file cifrati revisionabili nelle pull request e tratta la rotazione delle chiavi come un'attività pianificata piuttosto che come una risposta a un incidente.

Fonti: getsops/sops, bitnami/sealed-secrets.