Open Stack

Adrian,

On Tue, Jun 16, 2015 at 2:39 AM, Adrian Otto <adrian.otto at rackspace.com>
wrote:

>  Madhuri,
>
>  On Jun 15, 2015, at 12:47 AM, Madhuri Rai <madhuri.rai07 at 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.otto at rackspace.com>
> wrote:
>
>> 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.
>>
>
> +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-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
>
>
>
> __________________________________________________________________________
> 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/85f183ba/attachment.html>