Open Stack

Thanks Egor.

On Tue, Jun 16, 2015 at 1:52 AM, Egor Guz <EGuz at 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.rai07 at gmail.com<mailto:madhuri.rai07 at gmail.com
> >>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org
> >>
> Date: Monday, June 15, 2015 at 0:47
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org<mailto:openstack-dev at 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.otto at rackspace.com
> <mailto:adrian.otto at rackspace.com>> wrote:
> Madhuri,
>
> On Jun 14, 2015, at 10:30 PM, Madhuri Rai <madhuri.rai07 at gmail.com<mailto:
> madhuri.rai07 at 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-request at lists.openstack.org<mailto:
> OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Regards,
Madhuri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150616/8bc6ca39/attachment.html>