[openstack-dev] [Magnum][Kuryr][Keystone] Securing services in container orchestration

Adam Young ayoung at redhat.com
Thu Oct 20 16:44:38 UTC 2016


On 10/09/2016 10:57 PM, Ton Ngo wrote:
>
> Hi Keystone team,
> We have a scenario that involves securing services for container and 
> this has
> turned out to be rather difficult to solve, so we would like to bring 
> to the larger team for
> ideas.
> Examples of this scenario:
> 1. Kubernetes cluster:
> To support the load balancer and persistent storage features for 
> containers, Kubernetes
> needs to interface with Neutron and Cinder. This requires the user 
> credential to establish
> a session and request Openstack services. Currently this is done by 
> requiring the
> user to manually enter the credential in a Kubernetes config file and 
> restarting some
> of the Kubernetes services.
> 2. Swarm cluster:
> To support the Swarm networking for container, the Kuryr libnetwork 
> agent needs to
> interface with the Kuryr driver, so the agent needs a service 
> credential to establish
> a session with the driver running on some controllers.
>
> The problem is in handling and storing these credential on the user 
> VMs in the cluster.
>
> For #1, Magnum deploys the Kubernetes cluster but does not handle the
> user credential, so the automation is not complete and the user needs 
> to perform
> some manual steps. Even this is not desirable since if the cluster is 
> shared within
> a tenant, the user credential can be exposed to other users. Token 
> does not work
> well since token would expire and the service is required for the life 
> of the cluster.
> For #2, storing a Kuryr service credential on the user VM is a 
> security exposure
> so we are still looking for a solution.
>
> The Magnum and Kuryr teams have been discussing this topic for some time.
> We would welcome any suggestion.
>
> Ton Ngo,
>

Create a service user in a service domain, and grant a trust to the 
service user. This is what Heat does.


>
>
>
> __________________________________________________________________________
> 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/20161020/07610ecd/attachment.html>


More information about the OpenStack-dev mailing list