Skip to content →

Mozilla SOPS VS Sealed Secret

Introduction

I am evaluating the use of Mozilla SOPS or Sealed Secret for a new K8s project that will be heavily based on GitOps. See Infrastructure as code vs. GitOps – A real-world example of how I did it on a previous project. These are some of the considerations I made.

Pros and cons

SOPS

  • Pro: Native decryption support with GitOps toolkit Kustomize controller
  • Pro: A wider community and history backing the project
  • Pro: Can configure a git directory for encryption. It helps the developers when encrypting secrets to use the correct namespace and cluster.
  • Pro: The ability to use Cloud Provider KMSs for encryption/decryption. However, that creates a dependency on them.

  • Con: The developers will need to import the gpg key and use the gpg toolkit on their local machine
  • Con: More complex setup and usage than Sealed Secret

Sealed Secret

  • Pro: Easier to work with the encryption, especially with the VS Code plugin
  • Pro: No need to install gpg or import keys
  • Pro: No ability to use cloud provider KMSs for encryption/decryption. I have added this as a pro since it forces us to reduce the number of dependencies and instead only use the Git repo as the source.

  • Con: …and as a Con. It may be scenarios where we need to use the cloud provider KMS for encryption/decryption.
  • Con: No native support in Flux

Skip both and use CSI Driver?

It is also an option to skip both SOPS and Sealed Secret and use the Azure KeyVault CSI secret store driver instead. With the Azure KeyVault CSI driver, it is possible to assign a pod or managed identity to a pod and retrieve the secrets from a given KeyVault as volumes or mirrored as secrets in K8s. I wanted to keep the number of dependencies and complexity to a minimum. It may very well be that we will be hosting applications on an on-prem K8s solution intermedium where KeyVault is unavailable. I want to try to keep the platforms as identical as possible to ease the transition from on-prem to the cloud.

Conclusion

The approach using Mozilla SOPS is precisely the same as using SealedSecrets. SOPS has a more solid foundation in the sense of age and community. However, the approach with SealedSecrets is easier for the developers when they only need to use the public key and a CLI or a VS Code plugin. With SOPS, the developers need to install and use gpg in addition to importing the gpg key.

Choice

I ended up using SealedSecret. It is tailored directly towards K8s, is easier for developers to use, and has the necessary features.

Published in architecture k8s

Subscribe
Notify of
guest

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x