Open Stack

Just a quick note on Castellan, at the moment it's not a particularly
strong abstraction for key management in general, just the openstack
key management interface.

The reason this is important is because if I recall correctly, Castellan
requires a keystone token for auth. It should be no suprise that COTS
key managers, software or hardware, do not support this method of
authentication.

Unless something has changed recently, Castellan is good for allowing
teams to pivot between a local key management implementation or
Barbican but a long way from allowing a direct pivot to another key
management system.

I do recall some efforts to move beyond this limitation and implement
KMIP[1] for direct access to HSMs that support it, however I'm not sure
what the end result there was.

[1]
https://specs.openstack.org/openstack/barbican-specs/specs/mitaka/kmip-key-manager.html

On Tue, Jan 17, 2017 at 12:57 PM, Ian Cordasco <sigmavirus24 at gmail.com>
wrote:

> On Mon, Jan 16, 2017 at 6:20 PM, Amrith Kumar <amrith.kumar at gmail.com>
> wrote:
> > Ian,
> >
> > This is a fascinating conversation. Let me offer two observations.
> >
> > First, Trove has long debated the ideal solution for storing secrets.
> There
> > have been many conversations, and Barbican has been considered many
> times.
> > We sought input from people who were deploying and operating Trove at
> scale;
> > customers of Tesora, self described users of the upstream Trove, and
> some of
> > the (then) active contributors who were also operators.
> >
> > The consensus was that installing and deploying OpenStack was hard enough
> > and requiring the installation of yet more services was problematic.
> This is
> > not something which singles out Barbican in any way. For example, Trove
> uses
> > Swift as the default object store where backups are stored, and in
> > implementing replication we leveraged the backup capability. This means
> that
> > to have replication, one needs to have Swift. Several deployers have
> > objected to this since they don't have swift. But that is a dependency
> which
> > we considered to be a hard dependency and offer no alternatives; you can
> > have Ceph if you so desire but we still access it as a swift store.
> > Similarly we needed some capabilities of job scheduling and opted to use
> > mistral for this; we didn't reimplement all of these capabilities in
> Trove.
> >
> > However, when it comes to secret storage, the consensus of opinion is
> > <eye-roll>Yet another service</eye-roll>.
>
> So, what spurred this thread is that I'm currently working on Craton
> which wants to store deployment secrets for operators and I've
> recently received a lot of private mail about Glare and how one of its
> goals is to replace Barbican (as well as Glance).
>
> I'm quite happy that Trove has worked hard not to reimplement its
> requirements that were already satisfied by OpenStack projects. That's
> kind of what I'm hoping to help people do with Barbican in this
> thread.
>
> > Here is the second observation. This conversation reminds me of many
> > conversations from years past "Why do you want to use a NoSQL database,
> we
> > have a <name here> database already". I've sat in on heated arguments
> > amongst architects who implemented "lightweight key-value storage based
> on
> > <random NoSQL solution>" and didn't use the corporate standard RDBMS.
>
> This I don't quite agree with this comparison. Surely when NoSQL came
> out, people ridiculed it for not having the same properties as RDBMS,
> but there's a large difference in people criticizing NoSQL databases
> having not used them and me asking people to use software that's
> already been audited for security and written by people who understand
> the underlying technologies.
>
> I'm sure if you said to your users and operators: "These N services
> need to store secrets and each has implemented that in its own way
> with no common configuration or storage location. None of them can
> take advantage of HSMs you have present in your infrastructure, and
> none of the people who really developed this are experts at storing
> secrets, but they tried their best!" Those operators would start to
> gnash their teeth and even maybe curse you under their breath. If you
> said "These services all need to store secrets securely, and that
> means we need to add Barbican which was written by people who took the
> time to document their threat models, perform a security analysis, and
> have worked with the larger security community to develop it." They'd
> be happier. I do understand, however, that your customers aren't
> deploying all the services that might use Barbican, and that's fine.
>
> What I'm gleaning from this conversation is that most of us have
> customers who only use 1 extra service that has a soft dependency on
> Barbican but never more than one. I have customers using Octavia and
> Magnum and a team that wants to use Craton, so it seems to me like we
> would benefit from doing the hard work of deploying Barbican but that
> situation is rare.
>
> > Finally, it is my personal belief that making software pluggable such
> that
> > "if it discovers Barbican, it uses it, if it discovers XYZ it uses it,
> if it
> > discovers PQR it uses that ..." is a very expensive design paradigm.
> Unless
> > Barbican, PQR, XYZ and any other implementation provide such material
> value
> > to the consumer, and there is significant deployment and usage of each,
> the
> > cost of maintaining the transparent pluggability of these, the cost of
> > testing, and development all add up very quickly.
>
> I believe this is exactly what Castellan is designed to be. That
> interface so that services that want to have a soft requirement on
> Barbican can do so through Castellan.
>
> > Which is why when some project wants to store a secret, it ciphers it
> using
> > some one way hash and stuffs that in a database (if that's all it needs).
>
> Sometimes you need to get that secret back out though and that one way
> hash won't cut it. Also you have to balance what most people on this
> list consider "normal" deployments of OpenStack against the increasing
> demand to be able to deploy OpenStack on a FIPS compliant kernel, so
> now we should all be designing our cryptographic based features in
> ways that can satisfy both or have fallbacks in the case of FIPS.
>
> Cheers
> --
> Ian Cordasco
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170117/81b96c70/attachment.html>