<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="Generator" content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Cambria;
panose-1:2 4 5 3 5 4 6 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Cambria",serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Cambria",serif;color:#1f497d">We could certainly use the pre-existing Barbican capabilities, which would provide a reasonably easy and clean interface for key storage. However, this does not afford much (if any) additional security without the introduction of a Hardware Security Module as the Barbican back-end, and I’m not sure what the cost is of deploying Barbican (would this be on the fuel-master as well? Isn’t it getting crowded in there?).</span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Cambria",serif;color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Cambria",serif;color:#1f497d">Barbican currently has an integration available for a SafeNet Luna HSM, which runs in the tens of thousands per device, so I don’t think it’s reasonable to expect to use this for each customer environment (although long-term we should be looking to provide a full/secure solution to customers).</span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Cambria",serif;color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Cambria",serif;color:#1f497d">Sheena</span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Cambria",serif;color:#1f497d"> </span></p><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Evgeniy L [mailto:<a href="mailto:eli@mirantis.com">eli@mirantis.com</a>] <br><b>Sent:</b> Monday, August 24, 2015 6:48 AM<br><b>To:</b> OpenStack Development Mailing List (not for usage questions) <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br><b>Subject:</b> Re: [openstack-dev] [Fuel] SSL keys saving</span></p><p class="MsoNormal"> </p><div><p class="MsoNormal">Hi John,</p><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">I agree, that we didn't have these problems if we used Barbican and looks</p></div><div><p class="MsoNormal">like it's a good tool for our needs. But since we are in Hard Code Freeze</p></div><div><p class="MsoNormal">we should fix it somehow without introducing big changes in our current</p></div><div><p class="MsoNormal">architecture.</p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">But it would be a nice to see it as an improvement in 8.0 release.</p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">Thanks,</p></div></div><div><p class="MsoNormal"> </p><div><p class="MsoNormal">On Mon, Aug 24, 2015 at 3:57 PM, John Dennis <<a href="mailto:jdennis@redhat.com" target="_blank">jdennis@redhat.com</a>> wrote:</p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="MsoNormal">On 08/21/2015 05:10 AM, Stanislaw Bogatkin wrote:</p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><p class="MsoNormal">Hi folks.<br><br>Today I want to discuss the way we save SSL keys for Fuel environments.<br>As you maybe know we have 2 ways to get a key:<br>a. Generate it by Fuel (self-signed certificate will be created in this<br>case). In this case we will generate private key, csr and crt in a<br>pre-deployment hook on master node and then copy keypair to the nodes<br>which needed it.<br><br>b. Get a pre-generated keypair from user. In this case user should<br>create keypair by himself and then upload it through Fuel UI settings<br>tab. In this case keypair will be saved in nailgun database and then<br>will serialized into astute.yaml on cluster nodes, pulled from it by<br>puppet and saved into a file.<br><br>Second way has some flaws:<br>1. We already have some keys for nodes and we store them on master node.<br>Store keys in different places is bad, cause:<br>1.1. User experience - user should remember that in some cases keys will<br>be store in FS and in some other cases - in DB.<br>1.2. It brings problems for implementation in other different places -<br>for example, we need to get certificate for properly run OSTF tests and<br>now we should implement two different ways to deliver that certificate<br>to OSTF container. The same for fuel-cli - we should somehow get<br>certificate from DB and place it in FS to use it.<br>2. astute.yaml is similar for all nodes. Not all of nodes needs to have<br>private key, but now we cannot control this.<br>3. If keypair data serializes into astute.yaml it means than that data<br>automatically will be fetched when diagnostic snapshot will created. So<br>in some cases in can lead to security vulnerability, or we will must to<br>write another crutch to cut it out of diagnostic snapshot.<br><br><br>So I propose to get rid of saving keypair in nailgun database and<br>implement a way to always saving it to local FS on master node. We need<br>to implement next items:<br><br>- Change UI logic that saving keypair into DB to logic that will save it<br>to local FS<br>- Implement according fixes in fuel-library</p></blockquote><p class="MsoNormal"> </p></div></div><p class="MsoNormal">I have not been following this thread nor I do I know or understand all your requirements but I wanted to bring to your attention the fact OpenStack has a project called Barbican whose primary purpose is to safely store keys, plus it has many other features for handling keys. Key handling is tricky so rather than try to design something yourself perhaps it might make sense to leverage the Barbican work.<br><br><a href="https://wiki.openstack.org/wiki/Barbican/Incubation" target="_blank">https://wiki.openstack.org/wiki/Barbican/Incubation</a><br><br><a href="http://www.rackspace.com/blog/keeping-openstack-secrets-safe-with-barbican/" target="_blank">http://www.rackspace.com/blog/keeping-openstack-secrets-safe-with-barbican/</a><br><br><a href="http://www.slideshare.net/jarito030506/barbican-10-open-source-key-management-for-openstack" target="_blank">http://www.slideshare.net/jarito030506/barbican-10-open-source-key-management-for-openstack</a><span style="color:#888888"><br><br><br><span class="hoenzb">-- </span><br><span class="hoenzb">John</span></span></p><div><div><p class="MsoNormal"><br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></p></div></div></blockquote></div><p class="MsoNormal"> </p></div></div></body></html>