<div dir="ltr"><pre>Thanks Adrian for description.<br></pre><pre>If i could understand correctly,magnum clients will be use barbican for authentication as coes dont support keystone for operations like pod-creation<br></pre><pre>etc and for rest of the project clients like nova/glance pythonclients, keystone will continue to serve.<br><br></pre><pre>Please correct me.<br></pre><pre> <br></pre><pre>-Vikas<br></pre><pre><br>_________________________________________________________________________________________________________<br><i>Simply put, Keystone is designed to generate  tokens that are to be used for authentication and RBAC. Systems like Kunernetes do not support Keystone auth, but do support TLS. Using TLS provides a solution that is compatible with using these systems outside of an OpenStack cloud.

Barbican is designed for secure storage of arbitrary secrets, and currently also has a CA function. The reason that is compelling is that you can have Barbican generate, sign, and store a keypair without transmitting the private key over the network to the client that originates the signing request. It can be directly stored, and made available only to the clients that need access to it.

We are taking an iterative approach to TLS integration, so we can gradually take advantage of both keystone and Barbican features as they allow us to iterate toward a more secure integration.

Adrian

> On Aug 31, 2015, at 9:05 PM, Vikas Choudhary <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">choudharyvikas16 at gmail.com</a>> wrote:
> 
> Hi,
> 
> Can anybody please point me out some etherpad discussion page/spec  that can help me understand why we are going to introduce barbican  for magnum when we already had keystone for security management?
> 
> 
> 
> 
> -Vikas Choudhary
> 
> 
> __________________________________________________________</i></pre></div>