Using Sops to keep secrets

Secrets management is something that gets more important these days with distribution of runtime platforms and responsibilities such as cloud services and teams deploying to all lifecycle environments. With that change you want to have your secrets in code and encrypted. And that will be solved by already existing technologies as Git and GPG. But what about having the GPG key(s) in code?

  • The public key may be in a git repo, un-encrypted, because it can be used to encrypt new data, but you wouldn’t want to place the master key in the git repo un-encrypted.
  • Also, you would want a third party, trusted, part to encrypt and decrypt data used for the stages in between the git repo and the deployment of the application.

Enter Sops

So SOPS can be best explained by this blog and especially the quote:

The idea behind SOPS is to provide a wrapper around a text editor that takes care of the encryption and decryption transparently. When creating a new file, sops generates a data encryption key “Kd” that is itself encrypted with one or more KMS master keys and PGP public keys. Kd is used to encrypt the content of the file with AES256-GCM. In order to decrypt the files, sops must have access to any of the KMS or PGP master keys.

Downsides

Using both SOPS and GPG for securing a workflow where the developer/ops person should be able to add secrets, but not be able to decrypt them adds security layers and enables trust between ops and development teams, but it adds complexity. It’s well worth taking into considerations the benefits both GPG and SOPS gives each of their own and for what purposes. The importance is to make it easier for the developer/ops to automate deployments with enabled trust and distribute the secrets per repo so not one secret, if revealed, can ruin a massive load of infrastructure. Also, with AWS where you may hide/lock parts of the filesystem in a runtime environment as Docker, you can easier hide credntials needed to decrypt secrets. Thus, clean SOPS usage would be beneficial if development and deployment environments were on a cloud platform. While using local environments and developers being local admins over their environments, such credentials might be in danger of being revealed and cause havoc.

References

This link seems pretty good formulated as well: Managing Git Docker secrets with SOPS