Open Stack

> On Dec 12, 2017, at 9:42 AM, Paul Bourke <paul.bourke at oracle.com> wrote:
> 
> From my understanding it would be a cleanup operation - which to be honest, would be very much welcomed. I recently did a little work with Castellan to integrate it with Murano and found the auth code to be very messy, and flat out broken in some cases. If it's possible to let the barbican client take care of this that sounds good to me.
> 
> > Which mode is used the most in the services that consume castellan
> > today?
> 
> Afaik Barbican is the only backend that currently exists in Castellan [0]. Looking again it seems some support has been added for vault which is great, but I reckon Barbican would still be the primary use.
> 
> I haven't been hugely active in Castellan but if the team would like some more input on this or reviews please do ping me, I'd be glad to help.

What I mean is, in the services consuming Castellan, how do they expect it to authenticate to Barbican? As the current user or as a hard-coded fixed user controlled by the deployer? I would think most services would need to connect as the “current” user talking to them so they can access that user’s secrets from Barbican. Removing the keystoneauth stuff from the driver would therefore break all of those applications.

Doug

> 
> -Paul
> 
> [0] https://github.com/openstack/castellan/tree/master/castellan/key_manager
> 
> On 06/12/17 22:12, Doug Hellmann wrote:
>> Excerpts from Gage Hugo's message of 2017-12-06 15:16:14 -0600:
>>> It's been a bit since the summit but I believe this was also discussed at
>>> the Denver PTG as well:  https://etherpad.openstack.org/p/oslo-ptg-queens
>>> 
>>> The keystoneauth stuff seems to be more from Sydney, but if I remember
>>> correctly, Castellan authenticates through keystoneauth and passes the
>>> session to barbicanclient.  This is the only use of keystoneauth within
>>> Castellan, so one idea that was mentioned was to see if Castellan could
>>> simply pass the credentials to barbicanclient, which would auth through
>>> keystoneauth instead, removing the dependency from Castellan.
>> It looks like Castellan tries to authenticate using the token from
>> the context in two separate cases [1]. That would cause the service
>> using castellan to connect to barbican as the user making the API
>> request. Removing the use of keystoneauth would mean that feature
>> would no longer work, and all requests to barbican would be made
>> as a hard-coded user.  That seems like a pretty fundamental difference
>> in behavior.
>> Which mode is used the most in the services that consume castellan
>> today?
>> I'm still not understanding the real motivation for removing the
>> dependency. Is it just someone's notion of cleaning things up? Or is
>> there a runtime issue of some sort?
>> Doug
>> [1] http://git.openstack.org/cgit/openstack/castellan/tree/castellan/key_manager/barbican_key_manager.py#n140
>>> 
>>> On Tue, Dec 5, 2017 at 10:54 AM, Doug Hellmann <doug at doughellmann.com>
>>> wrote:
>>> 
>>>> Excerpts from ARORA, ROHAN's message of 2017-12-05 14:37:49 +0000:
>>>>> So from my understanding now, we are wanting to remove the HARD
>>>> dependency on Keystoneauth, not to remove it completely since that would
>>>> break the barbican client. Currently seeing if we just remove the
>>>> dependency from requirements.txt, if that stops Keystoneauth from being
>>>> used until you try to use the barbican.
>>>> 
>>>> There would need to be more changes than that, because we still need the
>>>> package to be installed for testing the Barbican driver.
>>>> 
>>>> Maybe if someone could explain what the issue is, I can offer more
>>>> detailed advice. What is wrong with having the keystoneauth dependency?
>>>> Is it breaking something? Is it interfering with some other library?
>>>> 
>>>> Doug
>>>> 
>>>> __________________________________________________________________________
>>>> 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
>>>> 
>> __________________________________________________________________________
>> 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
> 
> __________________________________________________________________________
> 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