Open Stack

+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.Fox at 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.otto at 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.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.
>
>  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-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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150616/18aa81ac/attachment.html>