Open Stack

On 06/15/2015 08:45 PM, Madhuri wrote:
> +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 
> <mailto: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.
>

Please use Certmonger on the the Magnum side, with an understanding that 
the Barbican team is writing a Certmonger plugin.

Certmonger can do self signed, and can talk to Dogtag if you need a real 
CA.  If we need to talk to other CAs, you write a helper script that 
Certmonger calls to post the CSR and fetch the signed Cert, but 
certmonger does the openssl/NSS work to properly mange the signing requests.

>
>     Thanks,
>     Kevin
>     ------------------------------------------------------------------------
>     *From:* Adrian Otto [adrian.otto at rackspace.com
>     <mailto: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 <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.
>
>     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
>>     <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
>
>
>
>
> __________________________________________________________________________
> 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/20150615/b06fd0f7/attachment.html>