Adrian, On Tue, Jun 16, 2015 at 2:39 AM, Adrian Otto <adrian.o...@rackspace.com> wrote:
> Madhuri, > > On Jun 15, 2015, at 12:47 AM, Madhuri Rai <madhuri.ra...@gmail.com> > wrote: > > 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> > wrote: > >> 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. >> > > +1, I agree. One question here, we are trying to secure the communication > between magnum-conductor and kube-apiserver. Right? > > > We need API services that are on public networks to be secured with TLS, > or another approach that will allow us to implement access control so that > these API’s can only be accessed by those with the correct keys. This need > extends to all places in Magnum where we are exposing native API’s. > Ok, I understand. > > 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. > > > Good! > > 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. > > > Good point. > > In our first implementation, we can support the user generating the > keys and then later client generating the keys. > > > Users should not require any knowledge of how TLS works, or related > certificate management tools in order to use Magnum. Let’s aim for this. > > I do agree that’s a good logical first step, but I am reluctant to agree > to it without confidence that we will add the additional security later. I > want to achieve a secure-by-default configuration in Magnum. I’m happy to > take measured forward progress toward this, but I don’t want the less > secure option(s) to be the default once more secure options come along. By > doing the more secure one first, and making it the default, we allow other > options only when the administrator makes a conscious action to relax > security to meet their constraints. > Barbican will be the default option. > > So, if our team agrees that doing simple key management without Barbican > should be our first step, I will agree to that under the condition that we > adjust the default later to require Barbican as soon as that feature is > added, and that we commit to implementing it. It would be a real shame if > we got as far as simple ket management, and never implemented Barbican > support. What do you all think? > Let's wait for more inputs. > > 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. > > > Excellent, thanks! > > 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. > > > I’m looking forward to more team input on this. > > Thanks, > > Adrian > > > 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://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 > > > > __________________________________________________________________________ > 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
