[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