Open Stack

Tom,

> On Jun 15, 2015, at 10:59 AM, Tom Cammann <tom.cammann at hp.com> wrote:
> 
> My main issue with having the user generate the keys/certs for the kube nodes
> is that the keys have to be insecurely moved onto the kube nodes. Barbican can
> talk to heat but heat must still copy them across to the nodes, exposing the
> keys on the wire. Perhaps there are ways of moving secrets correctly which I
> have missed.

When we create a bay, we have an ssh keypair that we use to inject the ssh public key onto the nova instances we create. We can use scp to securely transfer the keys over the wire using that keypair.

> I also agree that we should opt for a non-Barbican deployment first.
> 
> At the summit we talked about using Magnum as a CA and signing the
> certificates, and we seemed to have some consensus about doing this with the
> possibility of using Anchor. This would take a lot of the onus off of the user to
> fiddle around with openssl and craft the right signed certs safely. Using
> Magnum as a CA the user would generate a key/cert pair, and then get the
> cert signed by Magnum, and the kube node would do the same. The main
> downside of this technique is that the user MUST trust Magnum and the
> administrator as they would have access to the CA signing cert.
> 
> An alternative to that where the user holds the CA cert/key, is to have the user:
> 
> - generate a CA cert/key (or use existing corp one etc)
> - generate own cert/key
> - sign their cert with their CA cert/key
> - spin up kubecluster
> - each node would generate key/cert
> - each node exposes this cert to be signed
> - user signs each cert and returns it to the node.
> 
> This is going quite manual unless they have a CA that the kube nodes can call
> into. However this is the most secure way I could come up with.

Perhaps we can expose a “replace keys” feature that could be used to facilitate this after initial setup of the bay. This way you could establish a trust that excludes the administrator. This approach potentially lends itself to additional automation to make the replacement process a bit less manual.

Thanks,

Adrian

> 
> Tom
> 
> On 15/06/15 17:52, Egor Guz 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.
>> 
>> —
>> 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
> 
> 
> __________________________________________________________________________
> 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