Review tl;dr

Minimal dependencies, so easy to install and easy to use. Nice integration with git command line, but doesn't provide a great deal of functionality. Only supports shared secrets which is very limited as far as controlling access.

Product Summary

transcrypt is another in a relatively long of tools that focus on encrypting secrets in SCM. transcrypt is unique in that it uses openssl rather than gpg, like most similar tools.

Evaluation

It does what it does well, it just doesn't do very much. Pretty easy to install: it's available via brew, and since there are so few dependencies it's pretty easy to install manually. Requires a bit of manual-hacking of the git repo to add a file, but still pretty straightforward to use. Biggest liability is the lack of support for asymmetric encryption, so you can't revoke access for individual users.

Strengths

• very few dependencies
• .gitattributes modifications means that tig or git diff work as usual

Weaknesses

• No support for asymmetric encryption
• Only supports git

Ratings

• Ease of setup: good
• Easy of use: good
• Cloud readiness: good
• Datacenter readiness: good
• Automation / pipeline readiness: good
• Product maturity: fair
• Developer friendliness: good
• Documentation: fair
• Stability: good
• Auditability: poor

Review tl;dr

Vault is the runaway product in the secret-service open-source world. Vault isn't entirely mature as a product but it's definitely worth a look if you have sophisticated security needs and want to treat your secrets as ephemeral.

Product Summary

Vault is a fundamentally a tool for controlling access to resources via policies. It provides a means of decoupling control of access to resource (authz) from the identity of the requestor (authc) via a clean CLI and API for a number of use cases.

The key feature to Vault is leases. It is assumed for Vault deployments that a secret is only valid for so long. Obviously this doesn't handle a case where you want to send out a secret and "recall it" (think outlook "recall message" and how well that works) but rather it's for things like keys and credentials that have a natural lifespan, after which they can be changed. If credentials are always fetched from your vault server based on lease time, you can be guaranteed (unless there is an explicit expiration) that those credentials are always the latest and greatest and the app (or user) never has to worry about what those credentials actually are.

The interactions with HTTP API are pretty involved and have a pretty fair number of interactions. The logic you would need to build into your app to utilize the secrets would require a fair amount of code and the first thing you are going to want to do is develop a library in your native language to handle that interaction as transparently as possible.

Evaluation

Strengths

• REST API is pretty easy to use
• Supports a number of secret and authentication backends
• Good built-in help
• Secret lease model encourages a strong key rotation strategy
• Compelling model for ephemeral credentials that can integrate with AWS roles
• Several very interesting useful, including AWS, mysql, PostgreSQL and Consul
• Auditing support at the application level
• Community is responsive, including the devs

Weaknesses

• Comparatively high cost of entry compared to other tools and strategies.
• API docs are incomplete and at times, contradictory
• Inconsistent REST return code semantics (e.g. returning 400s for things that really should be 503s)
• Relative product immaturity means that API is not yet solidified, so building your own backends would be a tricky endeavor and you will probably end up re-writing
• Not available in standard repos. Extract is deploy.

Ratings

• Ease of setup: fair
• Easy of use: fair
• Cloud readiness: good
• Datacenter readiness: good
• Automation / pipeline readiness: fair
• Product maturity: fair
• Developer friendliness: fair
• Documentation: fair
• Stability: fair
• Auditability: good

Review tl;dr

Viable command line tool for encrypting items in git repos. A little more straightforward to use than some of the others because git filters means you get a native "git experience".

Product Summary

Another command line tools for encrypting data in a git repo using filters. Encryption is done via GPG. According to the site, repos that are public or mixed secret and non secret content are the sweet spot for git-crypt:

As such, git-crypt is not the best tool for encrypting most or all of the files in a repository. Where git-crypt really shines is where most of your repository is public, but you have a few files (perhaps private keys named *.key, or a file with API credentials) which you need to encrypt"

Evaluation

Strengths

• Simple workflow
• Can use key pairs for encryption / decryption
• Lock / unlock adds filtering to diff, so you can use tig or git diff work as usual

Weaknesses

• Basically no integrations other than git.
• Very little provisioning support
• Tight coupling with git makes it so that you have to operate in a git world. For example, you can't export the repo or the unlock simply won't work.

Ratings

• Ease of setup: poor
• Easy of use: fair
• Cloud readiness: good
• Datacenter readiness: good
• Automation / pipeline readiness: fair
• Product maturity: fair
• Developer friendliness: good
• Documentation: fair
• Stability: good
• Auditability: poor

Review tl;dr

Decent command-line tool for distributing secrets via SCM. Useable. No frills. Command line tools are layered on top, so you need to use the blackbox_* tools instead of your native SCM CLI. It offers GPG sub-keys as a mechanism for allowing access from automated users.

Product Summary

Blackbox is for storing secrets in Git, Mercurial, Subversion or Perforce. It was originally built for Puppet but that is no longer required. The basic model is that a series of scripts mediate the storage, encryption, and decryption of files. Keys are stored encrypted in SCM such that all authorized users can access them. Encryption is done via GPG.

You would generally not use blackbox as a service of any kind, nor would you be likely to use it during application runtime, but for development of manual secret access, and at provisioning time with your orchestration server.

It's worth noting that unlike most similar tools, blackbox has a story for automated users using sub-keys. It's not incredibly sophisticated, but similar tools don't even have a story for this.

It's worth noting that I did not evaluate the puppet use case, but just the tool as a command line tool. If you are in a puppet environment, you will probably want to do a separate evaluation of the integration.

Evaluation

Strengths

• Can use key pairs for encryption / decryption
• Strong puppet support
• Flexible in that it isn't opinionated about automation solutions.
• Good support for multiple repo types.
• Large number of SCM integrations

Weaknesses

• Doesn't integrate terribly well with git tools out of the box. (like tig, git history, etc).
• Only supports Centos/RedHat, OS-X, and Cygwin.
• Doesn't discourage storage of secrets on the machines--leaves it up to the dev.
• Automated deploy requires a build of an RPM, or copying source. Not in repos.
• Chef deploy encourages decryption at the puppet master, rather than the node
• No API outside of command line (and Puppet)

Ratings

• Ease of setup: fair (originally rated this as "poor", but compared to group at large, it was pretty straight-forward, so I'll call it "fair" if graded on the curve)
• Easy of use: good
• Cloud readiness: fair
• Data center readiness: fair
• Automation / pipeline readiness: poor
• Product maturity: good
• Developer friendliness: fair
• Documentation: fair
• Stability: good
• Auditability: poor. Doesn't stop you, but doesn't help you much either.

During the process of preparing for this presentation, I did a survey of a number of products to help implement a secret storage strategy. I did not approach these from a security analysts perspective but more from the devops side.

The criteria I used are as follows:

• Ease of setup - is the product straight-forward to deploy and do initial configuration?
• Easy of use - once set up, is the product intuitive? do you need to spend a lot of time going to the docs to figure out how to use it?
• Cloud readiness - does the product qualify as "cloud native": easily deployable, stateless, loosely couple dependencies, etc...?
• Datacenter readiness - will the product function easily in a more traditional corporate datacenter?
• Automation / pipeline readiness - does the product integrate well with continuous integration and continuous delivery environments or is it likely to be come the manual bottleneck?
• Product maturity - has the product been around and gone through some iterations so the wrinkles have been ironed out?
• Developer friendliness - does the APIs and/or command-line parameters are straightforward and the product has a good story for integrating into existing code?
• Documentation - RTFM
• Stability - does it crash or corrupt data?
• Auditability - does it provide decent auditing for both change and access or are you forced to build a layer on top?

Admittedly, some criteria proved to be more meaningful than others. For example, the "data center readiness" attribute ended up pretty flimsy. Any product I looked at that wasn't "data center ready" wasn't "cloud ready" either, due to product maturity.

Should I start reviewing any SAAS-type products, I think that will change so I'll leave the criteria up there.