<html><body><p>Hi Vikas,<br> It's correct that once the password is saved in the k8s master node, then it would have the same security as the nova-instance. The issue is as Hongbin noted, the password is exposed along the chain of interaction between magnum and heat. Users in the same tenant can potentially see the password of the user who creates the cluster. The current k8s mode of operation is k8s-centric, where the cluster is assumed to be managed manually so it is reasonable to configure with one OpenStack user credential. With Magnum managing the k8s cluster, we add another layer of management, hence the complication. <br> <br>Thanks Hongbin, Steve for the suggestion. If we don't see any fundamental flaw, we can proceed with the initial sub-optimal implementation and refine it later with the service domain implementation.<br><br>Ton Ngo,<br><br><br><img width="16" height="16" src="cid:1__=07BBF454DF8B16CD8f9e8a93df938690918c07B@" border="0" alt="Inactive hide details for Vikas Choudhary ---09/20/2015 09:02:49 PM---Hi Ton, kube-masters will be nova instances only and beca"><font color="#424282">Vikas Choudhary ---09/20/2015 09:02:49 PM---Hi Ton, kube-masters will be nova instances only and because any access to</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Vikas Choudhary <choudharyvikas16@gmail.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">openstack-dev@lists.openstack.org</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">09/20/2015 09:02 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">[openstack-dev] [magnum] Handling password for k8s</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><font size="4" color="#535353" face="Lucida Console">Hi Ton,</font><br><font size="4" color="#535353" face="Lucida Console">kube-masters will be nova instances only and because any access to nova-instances is already being secured using keystone, I am not able to understand what are the concerns in storing password on master-nodes.</font><br><font size="4" color="#535353" face="Lucida Console">Can you please list down concerns in our current approach?</font><br><tt><font size="4">-Vikas Choudhary</font></tt><br><i><font size="2" color="#535353" face="Lucida Console">Hi<br>everyone,</font></i><br><tt><font size="4" color="#535353"> </font></tt><i><font size="2" color="#535353" face="Lucida Console">I<br>am running into a potential issue in implementing the support for</font></i><br><i><font size="2" color="#535353" face="Lucida Console">load<br>balancer in k8s services. After a chat with sdake, I would like to</font></i><br><i><font size="2" color="#535353" face="Lucida Console">run<br>this by the team for feedback/suggestion.</font></i><br><i><font size="2" color="#535353" face="Lucida Console">First<br>let me give a little background for context. In the current k8s</font></i><br><i><font size="2" color="#535353" face="Lucida Console">cluster,<br>all k8s pods and services run within a private subnet (on Flannel)</font></i><br><i><font size="2" color="#535353" face="Lucida Console">and<br>they can access each other but they cannot be accessed from external</font></i><br><i><font size="2" color="#535353" face="Lucida Console">network.<br> The way to publish an endpoint to the external network is by</font></i><br><i><font size="2" color="#535353" face="Lucida Console">specifying<br>this attribute in your service manifest:</font></i><br><tt><font size="4" color="#535353"> </font></tt><i><font size="2" color="#535353" face="Lucida Console">type:<br>LoadBalancer</font></i><br><tt><font size="4" color="#535353"> </font></tt><i><font size="2" color="#535353" face="Lucida Console">Then<br>k8s will talk to OpenStack Neutron to create the load balancer</font></i><br><i><font size="2" color="#535353" face="Lucida Console">pool,<br>members, VIP, monitor. The user would associate the VIP with a</font></i><br><i><font size="2" color="#535353" face="Lucida Console">floating<br>IP and then the endpoint of the service would be accessible from</font></i><br><i><font size="2" color="#535353" face="Lucida Console">the<br>external internet.</font></i><br><tt><font size="4" color="#535353"> </font></tt><i><font size="2" color="#535353" face="Lucida Console">To<br>talk to Neutron, k8s needs the user credential and this is stored in</font></i><br><i><font size="2" color="#535353" face="Lucida Console">a<br>config file on the master node. This includes the username, tenant<br>name,</font></i><br><i><font size="2" color="#535353" face="Lucida Console">password.<br> When k8s starts up, it will load the config file and create an</font></i><br><i><font size="2" color="#535353" face="Lucida Console">authenticated<br>client with Keystone.</font></i><br><tt><font size="4" color="#535353"> </font></tt><i><font size="2" color="#535353" face="Lucida Console">The<br>issue we need to find a good solution for is how to handle the</font></i><br><i><font size="2" color="#535353" face="Lucida Console">password.<br> With the current effort on security to make Magnum</font></i><br><i><font size="2" color="#535353" face="Lucida Console">production-ready,<br>we want to make sure to handle the password properly.</font></i><br><tt><font size="4" color="#535353"> </font></tt><i><font size="2" color="#535353" face="Lucida Console">Ideally,<br>the best solution is to pass the authenticated token to k8s to</font></i><br><i><font size="2" color="#535353" face="Lucida Console">use,<br>but this will require sizeable change upstream in k8s. We have good</font></i><br><i><font size="2" color="#535353" face="Lucida Console">reason<br>to pursue this but it will take time.</font></i><br><tt><font size="4" color="#535353"> </font></tt><i><font size="2" color="#535353" face="Lucida Console">For<br>now, my current implementation is as follows:</font></i><br><tt><font size="4" color="#535353"> </font></tt><i><font size="2" color="#535353" face="Lucida Console">In<br>a bay-create, magnum client adds the password to the API call</font></i><br><tt><font size="4" color="#535353"> </font></tt><i><font size="2" color="#535353" face="Lucida Console">(normally<br>it authenticates and sends the token)</font></i><br><tt><font size="4" color="#535353"> </font></tt><i><font size="2" color="#535353" face="Lucida Console">The<br>conductor picks it up and uses it as an input parameter to the heat</font></i><br><tt><font size="4" color="#535353"> </font></tt><i><font size="2" color="#535353" face="Lucida Console">templates</font></i><br><tt><font size="4" color="#535353"> </font></tt><i><font size="2" color="#535353" face="Lucida Console">When<br>configuring the master node, the password is saved in the config</font></i><br><tt><font size="4" color="#535353"> </font></tt><i><font size="2" color="#535353" face="Lucida Console">file<br>for k8s services.</font></i><br><tt><font size="4" color="#535353"> </font></tt><i><font size="2" color="#535353" face="Lucida Console">Magnum<br>does not store the password internally.</font></i><br><tt><font size="4"><br><br></font></tt><br><tt><font size="4" color="#535353"> </font></tt><i><font size="2" color="#535353" face="Lucida Console">This<br>is probably not ideal, but it would let us proceed for now. We</font></i><br><i><font size="2" color="#535353" face="Lucida Console">can<br>deprecate it later when we have a better solution. So leaving aside</font></i><br><i><font size="2" color="#535353" face="Lucida Console">the<br>issue of how k8s should be changed, the question is: is this<br>approach</font></i><br><i><font size="2" color="#535353" face="Lucida Console">reasonable<br>for the time, or is there a better approach?</font></i><br><tt><font size="4"><br><br></font></tt><br><i><font size="2" color="#535353" face="Lucida Console">Ton<br>Ngo,</font></i><tt>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br></tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br></tt><br><BR>
</body></html>