Thanks Egor. On Tue, Jun 16, 2015 at 1:52 AM, Egor Guz <e...@walmartlabs.com> wrote:
> +1 for non-Barbican support first, unfortunately Barbican is not very well > adopted in existing installation. > > Madhuri, also please keep in mind we should come with solution which > should work with Swarm and Mesos as well in further. > Good point. It will be the same, just the difference will be configuring the respective services with signed certs and keys. > — > Egor > > From: Madhuri Rai <madhuri.ra...@gmail.com<mailto:madhuri.ra...@gmail.com > >> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org > >> > Date: Monday, June 15, 2015 at 0:47 > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org > >> > Subject: Re: [openstack-dev] [Magnum] TLS Support in Magnum > > Hi, > > Thanks Adrian for the quick response. Please find my response inline. > > On Mon, Jun 15, 2015 at 3:09 PM, Adrian Otto <adrian.o...@rackspace.com > <mailto:adrian.o...@rackspace.com>> wrote: > Madhuri, > > On Jun 14, 2015, at 10:30 PM, Madhuri Rai <madhuri.ra...@gmail.com<mailto: > madhuri.ra...@gmail.com>> wrote: > > Hi All, > > This is to bring the blueprint secure-kubernetes< > https://blueprints.launchpad.net/magnum/+spec/secure-kubernetes> in > discussion. I have been trying to figure out what could be the possible > change area to support this feature in Magnum. Below is just a rough idea > on how to proceed further on it. > > This task can be further broken in smaller pieces. > > 1. Add support for TLS in python-k8sclient. > The current auto-generated code doesn't support TLS. So this work will be > to add TLS support in kubernetes python APIs. > > 2. Add support for Barbican in Magnum. > Barbican will be used to store all the keys and certificates. > > 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. > > +1, I agree. One question here, we are trying to secure the communication > between magnum-conductor and kube-apiserver. Right? > > > 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. > > 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. > > > 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. > > 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. > > 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. > > 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. > We will have a config paramter like "store_secure" when True means we have > to store the keys in Barbican or else not. > What do you think? > > 3. Add support of TLS in Magnum. > This work mainly involves supporting the use of key and certificates in > magnum to support TLS. > > The user generates the keys, certificates and store them in Barbican. Now > there is two way to access these keys while creating a bay. > > 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…”. > > 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. > > In our first implementation, we can support the user generating the keys > and then later client generating the keys. > > 1. Heat will access Barbican directly. > While creating bay, the user will provide this key and heat templates will > fetch this key from Barbican. > > 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. > Yes. > > 2. Magnum-conductor access Barbican. > 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. > > 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. > > 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. > > Yes, I will take care of it. > > After discussion when we all come to same point, I will create separate > blueprints for each task. > I am currently working on configuring Kubernetes services with TLS keys. > > Please provide your suggestions if any. > > Thanks for kicking off this discussion. > > Regards, > > Adrian > > > > Regards, > Madhuri > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto: > openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > Regards, > Madhuri > > __________________________________________________________________________ > 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 > Regards, Madhuri
__________________________________________________________________________ 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
