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