1. 3
  1. 3

    While this article is specifically regarding the 0.100 release of SecureStore for rust, SecureStore itself is a language-agnostic open protocol for a plain-text, git-versioned alternative to storing secrets as environment variables (which is inherently insecure and prone to leakage) or via network-accessible secret management servers (which are a really heavy dependency, incur a fairly significant devops cost, and are overkill for most companies’ needs). SecureStore implementations are available for other languages, and the protocol was designed from the ground up to be portable, git-friendly, and easy to use.

    SecureStore vaults unify the way passwords are stored and retrieved in-development and in-production and make spinning up development environments really easy (since the secrets are actually cloned alongside the code when you just check out the repo, you just need to know the password or be given a single decryption key). The git versioning makes sure that your secrets are committed at the same time as the code that uses them, and the usage of separate vaults for production and dev use means you can separate who has access to what. Even if your secrets change daily, the master decryption key is generally static (unless you rotate it) and so you only need to deploy the production keyfile once to newly imaged servers via CI or out-of-band.

    1. 1

      I think I can guess but maybe you can confirm. Does it support multiple passwords/keys to decrypt the secrets? E.g. each developer has their own password they don’t share with anyone.

      1. 2

        Not with one vault, no. Typically you’d have a dev vault with a password shared with everyone with repo write access and a staging/prod vault only authorized devs trusted with remote access to prod servers, protected with its own password (or no password and keyfile only for even greater security).