<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<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:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
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.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US">I think this is an interesting if somewhat difficult to follow thread.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US">It’s worth keeping in mind that there are more ways to handle certificates in OpenStack than just Barbican, though there are often
good reasons to use it. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US">Is there a blueprint or scheduled IRC meeting to discuss the options? If useful I’d be happy to arrange for some folks from the Security
Project to take a look, we spend a lot of time collectively dealing with TLS issues and might be able to help with the path-finding for TLS in Magnum.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US">-Rob<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif""> Adrian Otto [mailto:adrian.otto@rackspace.com]
<br>
<b>Sent:</b> 17 June 2015 06:12<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Magnum] TLS Support in Magnum<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Clint, <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Hi! It’s good to hear from you!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jun 16, 2015, at 8:58 PM, Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">I don't understand at all what you said there.<br>
<br>
If my kubernetes minions are attached to a gateway which has a direct<br>
route to Magnum, let's say they're at, 192.0.2.{100,101,102}, and<br>
Magnum is at 198.51.100.1, then as long as the minions' gateway knows<br>
how to find 198.51.100.0/24, and Magnum's gateway knows how to route to<br>
192.0.2.0/24, then you can have two-way communication and no floating<br>
ips or NAT. This seems orthogonal to how external users find the minions.</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">That’s correct. Keep in mind that large clouds use layer 3 routing protocols to get packets around, especially for north/south traffic where public IP addresses are typically used. Injecting new routes into the network fabric each time
we create a bay might cause reluctance from network administrators to allow the adoption of Magnum. Pre-allocating tons of RFC-1918 addresses to Magnum may also be impractical on networks that use those addresses extensively. Steve’s explanation of using routable
addresses as floating IP addresses is one approach to leverage the prevailing SDN in the cloud’s network to address this concern.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Let’s not get too far off topic on this thread. We are discussing the implementation of TLS as a mechanism of access control for API services that run on networks that are reachable by the public. We got a good suggestion to use an approach
that can work regardless of network connectivity between the Magnum control plane and the Nova instances (Magnum Nodes) and the containers that run on them. I’d like to see if we could use cloud-init to get the keys into the bay nodes (docker hosts). That
way we can avoid the requirement for end-to-end network connectivity between bay nodes and the Magnum control plane.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Adrian<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">Excerpts from Steven Dake (stdake)'s message of 2015-06-16 19:40:25 -0700:<br style="orphans: auto;text-align:start;widows: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">Clint,<br>
<br>
Answering Clint’s question, yes there is a reason all nodes must expose a floating IP address.<br>
<br>
In a Kubernetes cluster, each minion has a port address space. When an external service contacts the floating IP’s port, the request is routed over the internal network to the correct container using a proxy mechanism. The problem then is, how do you know
which minion to connect to with your external service? The answer is you can connect to any of them. Kubernetes only has one port address space, so Kubernetes suffers from a single namespace problem (which Magnum solves with Bays).<br>
<br>
Longer term it may make sense to put the minion external addresses on a RFC1918 network, and put a floating VIF with a load balancer to connect to them. Then no need for floating address per node. We are blocked behind kubernetes implementing proper support
for load balancing in OpenStack to even consider this work.<br>
<br>
Regards<br>
-steve<br>
<br>
From: <Fox>, Kevin M <<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a><<a href="mailto:Kevin.Fox@pnnl.gov">mailto:Kevin.Fox@pnnl.gov</a>>><br>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><<a href="mailto:openstack-dev@lists.openstack.org">mailto:openstack-dev@lists.openstack.org</a>>><br>
Date: Tuesday, June 16, 2015 at 6:36 AM<br>
To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><<a href="mailto:openstack-dev@lists.openstack.org">mailto:openstack-dev@lists.openstack.org</a>>><br>
Subject: Re: [openstack-dev] [Magnum] TLS Support in Magnum<br>
<br>
Out of the box, vms usually can contact the controllers though the routers nat, but not visa versa. So its preferable for guest agents to make the connection, not the controller connect to the guest agents. No floating ips, security group rules or special networks
are needed then.<br>
<br>
Thanks,<br>
Kevin<br>
<br>
________________________________<br>
From: Clint Byrum<br>
Sent: Monday, June 15, 2015 6:10:27 PM<br>
To: openstack-dev<br>
Subject: Re: [openstack-dev] [Magnum] TLS Support in Magnum<br>
<br>
Excerpts from Fox, Kevin M's message of 2015-06-15 15:59:18 -0700:<br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">No, I was confused by your statement:<br>
"When we create a bay, we have an ssh keypair that we use to inject the ssh public key onto the nova instances we create."<br>
<br>
It sounded like you were using that keypair to inject a public key. I just misunderstood.<br>
<br>
It does raise the question though, are you using ssh between the controller and the instance anywhere? If so, we will still run into issues when we go to try and test it at our site. Sahara does currently, and we're forced to put a floating ip on every instance.
Its less then ideal...<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
Why not just give each instance a port on a network which can route<br>
directly to the controller's network? Is there some reason you feel<br>
"forced" to use a floating IP?<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe:<span class="apple-converted-space"> </span></span><a href="mailto:OpenStack-dev-request@lists.openstack.org"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">OpenStack-dev-request@lists.openstack.org</span></a><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">?subject:unsubscribe<br>
</span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>