+1 Kevin. We will make Barbican a dependency to make it the default option to secure keys.
Regards, Madhuri On Tue, Jun 16, 2015 at 12:48 AM, Fox, Kevin M <kevin....@pnnl.gov> wrote: > If your asking the cloud provider to go through the effort to install > Magnum, its not that much extra effort to install Barbican at the same > time. Making it a dependency isn't too bad then IMHO. > > Thanks, > Kevin > ------------------------------ > *From:* Adrian Otto [adrian.o...@rackspace.com] > *Sent:* Sunday, June 14, 2015 11:09 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Magnum] TLS Support in Magnum > > Madhuri, > > On Jun 14, 2015, at 10:30 PM, Madhuri Rai <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. > > 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. > > 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. > > 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. > > *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…”. > > 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. > > 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. > > 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?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://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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev