SOPS vs Sealed Secrets: qual secrets para GitOps?
O SOPS criptografa arquivos de secrets arbitrários com KMS/age/PGP; o Sealed Secrets é um controller do Kubernetes que descriptografa CRDs SealedSecret em Secrets dentro do cluster.
O SOPS é de uso geral: ele criptografa qualquer arquivo estruturado e se integra a muitos backends e ferramentas de CI, descriptografando onde quer que você tenha a chave. O Sealed Secrets é específico do Kubernetes: você criptografa com uma chave pública do cluster em um SealedSecret que só o controller dentro do cluster consegue descriptografar, mantendo o plaintext totalmente fora do Git. O SOPS vence em flexibilidade entre ambientes; o Sealed Secrets vence em um modelo GitOps enxuto e nativo do Kubernetes.
| SOPS | Sealed Secrets | |
|---|---|---|
| Escopo | Qualquer arquivo | CRDs do Kubernetes |
| Descriptografia | Em qualquer lugar com a chave | Controller dentro do cluster |
| Backends | KMS, age, PGP | Par de chaves do cluster |
| Adequação a GitOps | Ampla | Nativa do K8s |
| Melhor para | Secrets entre ambientes | Secrets GitOps do K8s |
Caso de uso e escopo
O SOPS serve a times que gerenciam secrets entre muitos ambientes e tipos de arquivo com backends de chave flexíveis. O Sealed Secrets serve a GitOps exclusivo do Kubernetes onde você quer manifests criptografados no Git que só o cluster de destino consegue fazer unseal.
Adequação a ops e CI
O SOPS descriptografa no CI ou no deploy com uma chave; o Sealed Secrets depende de um controller dentro do cluster, então o CI só precisa da chave pública para criptografar. Runners gerenciados mais rápidos encurtam as etapas de criptografia/descriptografia e de build de manifests em qualquer um dos fluxos.
O veredito
Quer arquivos de secrets criptografados flexíveis e entre ambientes: SOPS. Quer selagem nativa do Kubernetes onde só o cluster consegue descriptografar: Sealed Secrets. A amplitude favorece o SOPS; o GitOps nativo do K8s favorece o Sealed Secrets.