Thanks,
Kevin
------------------------------------------------------------------------
*From:* Adrian Otto [adrian.o...@rackspace.com
<mailto:adrian.o...@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.ra...@gmail.com <mailto:madhuri.ra...@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-requ...@lists.openstack.org
<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
