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,*
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
