Re: Incubation Proposal: CredHub (credential manager)


Travis McPeak
 

I see how getting UAA to interface correctly to somethung like Vault may be
difficult. Aside from that and the language stack, what are primary
diffetences with other mature key management systems?

Crypto (and surrounding implementations) are notoriously difficult to get
right. Are we planning to have any kind of third party audit?


On Tue, Dec 20, 2016, 6:05 AM Wayne E. Seguin <wayneeseguin(a)gmail.com>
wrote:

Most of our customers are using Vault already for secrets management and
would prefer to keep doing so as their final "at-rest" store.

For our customers it would therefore work best if CredHub can use Vault.

With this idea, can we design CredHub using interchangeable backends
(Perhaps a plugin API for backends) so that our customers can continue to
use Vault as the final "at-rest" backend key/credentials store?

On Mon, Dec 19, 2016 at 8:45 PM, Justin Smith <jusmith(a)pivotal.io> wrote:

It makes sense to build CredHub for many reasons. A few that come to mind
quickly are below.

1) The service must start and restart without human intervention. This
immediately means the key encrypting key resides in a Hardware Security
Module (HSM) of some kind. We think this is a first-class feature and
should be part of CredHub open source.
2) CloudFoundry runs in production in some of the most restricted
environments in the world. These environments tend towards favoring crypto
stacks they have seen and reviewed before. The Java ecosystem contains
several. The Go ecosystem will eventually get there, but it isn't right
now. We're fully aware there are tons of great Go apps (including large
chunks of CloudFoundry) that perform crypto today. We received credible
feedback that showed a Java preference for this type of application.
3) Authorization is an important part of credential management in CF.
Authorization can be an incredibly difficult problem, and an authorization
implementation can be very hard to change after it is built. We didn't see
anything available that had the right feature set. We could have bolted
something in front of another product, but we decided it made more sense to
build something new.

MVP certainly requires hitting a threshold of capabilities, but it also
requires leaving runway for what's ahead.

App secrets are a mainline scenario. Let's take it as a given that apps
must have access to plaintext secrets. From there, the discussion centers
on two questions: 1) what's the chain of custody of the secret and what has
access to it, and 2) how is the secret made available to the app. (1) is
all about CredHub and (2) is mostly about Diego. We'll engage in a
discussion on these in the weeks ahead.




--
~Wayne

Wayne E. Seguin
wayneeseguin(a)gmail.com
wayneeseguin on irc.freenode.net
http://twitter.com/wayneeseguin/
https://github.com/wayneeseguin/

Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.