3 ms·

Please can somehow explain how this might fit in with tools like AWS Secrets, pass CLI, GitHub Actions Secrets, etc?

pxc 4y ago
There are some use cases where pass and SOPS could reasonably be considered competitors, but for the most part, pass is best suited to personal/user secrets and SOPS is focused on infrastructure-as-code (e.g., secrets in Kubernetes or Nix configurations). There are no browser plugins for SOPS like there are for pass, for example. And SOPS has integration with more deployment tools than pass does. Like pass, SOPS wraps the CLIs of local encryption/decryption tools such as GPG and age. Unlike pass, it also wraps the CLIs of cloud-based secrets management services. One thing that potentially makes SOPS nicer for teams than pass is that you can freely mix and match the supported encryption and secrets management tools used to manage the secrets in a single project. So if we're on the same DevOps team and you prefer age but I need GnuPG in order to work with my PGP smartcard, we can still both easily manage and access the same secrets in the same repo together. Similarly, if we're working across teams, perhaps in a large organization or between two different organizations), we can use a single repo as a shared source of truth for shared secrets— even if one team is deploying their application to AWS and so it relies on Amazon's KMS for secrets, but the other team is deploying its application to Microsoft Azure and relies on Azure Vault for accessing secrets. SOPS works with two layers of keys: it encrypts for various keys that, in some user-specified combination, can be used to decrypt the keys that can decrypt the user's actual in-repo secrets. SOPS supports using GPG, age, AWS KMS, Azure Vault, etc., for that outer layer (which is all the end user really has to think about). re: GitHub Actions, GitLab CI/CD, etc.: SOPS is an alternative to entering your secrets in some web interface associated with your git forge or CI/CD service, so that your source code repository can be a single source of truth for all of the information needed to run your application, including any relevant secrets. In that way, your deployments no longer depend implicitly on the state of applications that offer to store secrets for you: those dependencies are made explicit, and those services are simply used to access part of your version-controlled source of truth about application deployment/configuration. (If you want to use SOPS for secrets that you also need to access in your GitHub Actions or GitLab CI/CD, you can do so by making the `sops` CLI available in the environment of a self-hosted GitHub Actions Runner or GitLab Runner.)

pxc 4y ago

There are some use cases where pass and SOPS could reasonably be considered competitors, but for the most part, pass is best suited to personal/user secrets and SOPS is focused on infrastructure-as-code (e.g., secrets in Kubernetes or Nix configurations). There are no browser plugins for SOPS like there are for pass, for example. And SOPS has integration with more deployment tools than pass does. Like pass, SOPS wraps the CLIs of local encryption/decryption tools such as GPG and age. Unlike pass, it also wraps the CLIs of cloud-based secrets management services. One thing that potentially makes SOPS nicer for teams than pass is that you can freely mix and match the supported encryption and secrets management tools used to manage the secrets in a single project. So if we're on the same DevOps team and you prefer age but I need GnuPG in order to work with my PGP smartcard, we can still both easily manage and access the same secrets in the same repo together. Similarly, if we're working across teams, perhaps in a large organization or between two different organizations), we can use a single repo as a shared source of truth for shared secrets— even if one team is deploying their application to AWS and so it relies on Amazon's KMS for secrets, but the other team is deploying its application to Microsoft Azure and relies on Azure Vault for accessing secrets. SOPS works with two layers of keys: it encrypts for various keys that, in some user-specified combination, can be used to decrypt the keys that can decrypt the user's actual in-repo secrets. SOPS supports using GPG, age, AWS KMS, Azure Vault, etc., for that outer layer (which is all the end user really has to think about). re: GitHub Actions, GitLab CI/CD, etc.: SOPS is an alternative to entering your secrets in some web interface associated with your git forge or CI/CD service, so that your source code repository can be a single source of truth for all of the information needed to run your application, including any relevant secrets. In that way, your deployments no longer depend implicitly on the state of applications that offer to store secrets for you: those dependencies are made explicit, and those services are simply used to access part of your version-controlled source of truth about application deployment/configuration. (If you want to use SOPS for secrets that you also need to access in your GitHub Actions or GitLab CI/CD, you can do so by making the `sops` CLI available in the environment of a self-hosted GitHub Actions Runner or GitLab Runner.)