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

[Adam Young]

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-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

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

[Ton Ngo]

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,
__
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