Open Stack

Hi Ton,

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.

Can you please list down concerns in our current approach?

-Vikas Choudhary

*Hi
everyone,*

    *I
am running into a potential issue in implementing the support for*

*load
balancer in k8s services.  After a chat with sdake, I would like to*

*run
this by the team for feedback/suggestion.*

*First
let me give a little background for context.  In the current k8s*

*cluster,
all k8s pods and services run within a private subnet (on Flannel)*

*and
they can access each other but they cannot be accessed from external*

*network.
 The way to publish an endpoint to the external network is by*

*specifying
this attribute in your service manifest:*

        *type:
LoadBalancer*

   *Then
k8s will talk to OpenStack Neutron to create the load balancer*

*pool,
members, VIP, monitor.  The user would associate the VIP with a*

*floating
IP and then the endpoint of the service would be accessible from*

*the
external internet.*

   *To
talk to Neutron, k8s needs the user credential and this is stored in*

*a
config file on the master node.  This includes the username, tenant
name,*

*password.
 When k8s starts up, it will load the config file and create an*

*authenticated
client with Keystone.*

    *The
issue we need to find a good solution for is how to handle the*

*password.
 With the current effort on security to make Magnum*

*production-ready,
we want to make sure to handle the password properly.*

    *Ideally,
the best solution is to pass the authenticated token to k8s to*

*use,
but this will require sizeable change upstream in k8s.  We have good*

*reason
to pursue this but it will take time.*

    *For
now, my current implementation is as follows:*

   *In
a bay-create, magnum client adds the password to the API call*

   *(normally
it authenticates and sends the token)*

   *The
conductor picks it up and uses it as an input parameter to the heat*

   *templates*

   *When
configuring the master node, the password is saved in the config*

   *file
for k8s services.*

   *Magnum
does not store the password internally.*


     *This
is probably not ideal, but it would let us proceed for now.  We*

*can
deprecate it later when we have a better solution.  So leaving aside*

*the
issue of how k8s should be changed, the question is:  is this
approach*

*reasonable
for the time, or is there a better approach?*


 *Ton
Ngo,*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150921/435da034/attachment.html>