<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Madhuri,
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jun 15, 2015, at 12:47 AM, Madhuri Rai <<a href="mailto:madhuri.rai07@gmail.com" class="">madhuri.rai07@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Hi,<br class="">
<br class="">
Thanks Adrian for the quick response. Please find my response inline.<br class="">
<div class="">
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Mon, Jun 15, 2015 at 3:09 PM, Adrian Otto <span dir="ltr" class="">
<<a href="mailto:adrian.otto@rackspace.com" target="_blank" class="">adrian.otto@rackspace.com</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">Madhuri,
<div class=""><br class="">
<div class=""><span class="">
<blockquote type="cite" class="">
<div class="">On Jun 14, 2015, at 10:30 PM, Madhuri Rai <<a href="mailto:madhuri.rai07@gmail.com" target="_blank" class="">madhuri.rai07@gmail.com</a>> wrote:</div>
<br class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class="">
<div class=""><font size="2" color="003366" class="">Hi All,<br class="">
<br class="">
<font color="003366" class="">This is to bring the blueprint </font><a href="https://blueprints.launchpad.net/magnum/+spec/secure-kubernetes" target="_blank" class="">secure-kubernetes</a><font color="003366" class=""> in di<font color="003366" class="">scussion.
I have <font color="003366" class="">been trying to figure out <font color="003366" class="">
what could be the possible change <font color="003366" class="">area to support this feature in Magnum.</font></font></font></font></font></font> Below is just a rough idea on ho<font color="003366" class="">w to proceed further on it.</font><br class="">
<br class="">
<font color="003366" class="">Th<font color="003366" class="">is task can be further broken in smaller
<font color="003366" class="">pieces.</font></font></font><br class="">
<br class="">
<b class="">1. Add support for TLS in python-k8sclient.</b><br class="">
<div style="margin-left:40px" class=""><font size="2" color="003366" class="">The current auto-generated code doesn't support TLS. So this work will be to add TLS support in kubernetes python APIs.</font><br class="">
</div>
<font size="2" color="003366" class=""><br class="">
<b class="">2. Add support for Barbican in Magnum.</b><br class="">
</font>
<div style="margin-left:40px" class=""><font size="2" color="003366" class="">Barbican will be used to store all the keys and certificates.</font><br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
</span>Keep in mind that not all clouds will support Barbican yet, so this approach could impair adoption of Magnum until Barbican is universally supported. It might be worth considering a solution that would generate all keys on the client, and copy them to
the Bay master for communication with other Bay nodes. This is less secure than using Barbican, but would allow for use of Magnum before Barbican is adopted.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
+1, I agree. One question here, we are trying to secure the communication between magnum-conductor and kube-apiserver. Right?<br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
We need API services that are on public networks to be secured with TLS, or another approach that will allow us to implement access control so that these API’s can only be accessed by those with the correct keys. This need extends to all places in Magnum where
we are exposing native API’s.</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">
<div class="">If both methods were supported, the Barbican method should be the default, and we should put warning messages in the config file so that when the administrator relaxes the setting to use the non-Barbican configuration he/she is made aware that
it requires a less secure mode of operation.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">In non-Barbican support, client will generate the keys and pass the location of the key to the magnum services. Then again heat template will copy and configure the kubernetes services on master node. Same as the below step.<br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
Good!</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">
<div class="">My suggestion is to completely implement the Barbican support first, and follow up that implementation with a non-Barbican option as a second iteration for the feature.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">How about implementing the non-Barbican support first as this would be easy to implement, so that we can first concentrate on Point 1 and 3. And then after it, we can work on Barbican support with more insights.<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">
<div class=""><br class="">
</div>
<div class="">Another possibility would be for Magnum to use its own private installation of Barbican in cases where it is not available in the service catalog. I dislike this option because it creates an operational burden for maintaining the private Barbican
service, and additional complexities with securing it.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
In my opinion, installation of Barbican should be independent of Magnum. My idea here is, if user wants to store his/her keys in Barbican then he/she will install it.<br class="">
We will have a config paramter like "store_secure" when True means we have to store the keys in Barbican or else not.<br class="">
</div>
<div class="">What do you think?<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">
<div class=""><span class=""><br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class="">
<div class=""><font size="2" color="003366" class=""><b class="">3. Add support of TLS in Magnum.</b><br class="">
</font>
<div style="margin-left:40px" class=""><font size="2" color="003366" class="">This work mainly involves supporting the use of key and certificates in magnum to support TLS.</font><br class="">
<font size="2" color="003366" class=""></font><br class="">
<font size="2" color="003366" class="">The user generates the keys, certificates and store them in Barbican. Now there is two way to access these keys while creating a bay.</font><br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
</span>Rather than "the user generates the keys…", perhaps it might be better to word that as "the magnum client library code generates the keys for the user…”.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
It is "user" here. In my opinion, there could be users who don't want to use magnum client rather the APIs directly, in that case the user will generate the key themselves.<br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
Good point.</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="">In our first implementation, we can support the user generating the keys and then later client generating the keys.<br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
Users should not require any knowledge of how TLS works, or related certificate management tools in order to use Magnum. Let’s aim for this.</div>
<div><br class="">
</div>
<div>I do agree that’s a good logical first step, but I am reluctant to agree to it without confidence that we will add the additional security later. I want to achieve a secure-by-default configuration in Magnum. I’m happy to take measured forward progress
toward this, but I don’t want the less secure option(s) to be the default once more secure options come along. By doing the more secure one first, and making it the default, we allow other options only when the administrator makes a conscious action to relax
security to meet their constraints.</div>
<div><br class="">
</div>
<div>So, if our team agrees that doing simple key management without Barbican should be our first step, I will agree to that under the condition that we adjust the default later to require Barbican as soon as that feature is added, and that we commit to implementing
it. It would be a real shame if we got as far as simple ket management, and never implemented Barbican support. What do you all think?</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">
<div class=""><span class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class="">
<div class="">
<div style="margin-left:40px" class=""><font size="2" color="003366" class=""></font><font size="2" color="003366" class="">1. Heat will access Barbican directly.</font><br class="">
<font size="2" color="003366" class="">While creating bay, the user will provide this key and heat templates will fetch this key from Barbican.</font><br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
</span>I think you mean that Heat will use the Barbican key to fetch the TLS key for accessing the native API service running on the Bay.</div>
</div>
</div>
</blockquote>
<div class="">Yes. <br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">
<div class=""><span class=""><br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class="">
<div class="">
<div style="margin-left:40px" class=""><font size="2" color="003366" class="">2. Magnum-conductor access Barbican.</font><br class="">
<font size="2" color="003366" class="">While creating bay, the user will provide this key and then Magnum-conductor will fetch this key from Barbican and provide this key to heat.</font><br class="">
<font size="2" color="003366" class=""></font><br class="">
<font size="2" color="003366" class="">Then heat will copy this files on kubernetes master node. Then bay will use this key to start a Kubernetes services signed with these keys.</font><br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
</span>Make sure that the Barbican keys used by Heat and magnum-conductor to store the various TLS certificates/keys are unique per tenant and per bay, and are not shared among multiple tenants. We don’t want it to ever be possible to trick Magnum into revealing
secrets belonging to other tenants.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">Yes, I will take care of it.<br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
Excellent, thanks!</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""><span class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class=""><font size="2" color="003366" class=""><font color="003366" class=""><font color="003366" class=""><font color="003366" class=""><font color="003366" class=""><font color="003366" class="">After
<font color="003366" class="">discussion when we all come to same point, I will create
<font color="003366" class="">separate</font> blueprint<font color="003366" class="">s for each task.
<br class="">
</font></font>I am currently working on configuring Kubernetes <font color="003366" class="">
services with TLS <font color="003366" class="">keys.<br class="">
</font></font></font></font></font></font></font></font></div>
</div>
</div>
</div>
</div>
</blockquote>
</span></div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
I’m looking forward to more team input on this.</div>
<div><br class="">
</div>
<div>Thanks,</div>
<div><br class="">
</div>
<div>Adrian</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""><span class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class=""><font size="2" color="003366" class=""><font color="003366" class=""><font color="003366" class=""><font color="003366" class=""><font color="003366" class=""><font color="003366" class=""><font color="003366" class=""><font color="003366" class=""><br class="">
</font></font></font></font></font></font></font></font></div>
<font size="2" color="003366" class=""><font color="003366" class="">Please provide your suggest<font color="003366" class="">ions if any.</font></font><br class="">
</font></div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
</span>Thanks for kicking off this discussion.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">
<div class=""><br class="">
</div>
<div class="">Regards,</div>
<div class=""><br class="">
</div>
<div class="">Adrian</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class=""><font size="2" color="003366" class=""><br class="">
<br class="">
</font></div>
<font size="2" color="003366" class=""><font color="003366" class=""><font color="003366" class=""><font color="003366" class=""><font color="003366" class=""><font color="003366" class=""><font color="003366" class=""><font color="003366" class=""><font color="003366" class="">Reg<font color="003366" class="">ar<font color="003366" class="">ds,<br class="">
</font></font></font></font></font></font></font></font></font></font></font></div>
<font size="2" color="003366" class=""><font color="003366" class="">Madhuri</font><br class="">
</font></div>
__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank" class="">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
<br class="">
__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank" class="">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
<br class="">
</blockquote>
</div>
<br class="">
</div>
<div class="gmail_extra">Regards,<br class="">
</div>
<div class="gmail_extra">Madhuri<br class="">
</div>
</div>
</div>
__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>