Open Stack

Excerpts from Dave McCowan (dmccowan)'s message of 2017-12-12 21:36:51 +0000:
> 
> On 12/12/17, 3:15 PM, "Doug Hellmann" <doug at doughellmann.com> wrote:
> 
> >Excerpts from Dave McCowan (dmccowan)'s message of 2017-12-12 19:56:49
> >+0000:
> >> 
> >> On 12/12/17, 10:38 AM, "Doug Hellmann" <doug at doughellmann.com> wrote:
> >> 
> >> >
> >> >> 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
> >> 
> >> We're a mix right now.  Nova and Cinder pass through the a user's token
> >>to
> >> retrieve the user's key for encrypted volumes.  Octavia uses its service
> >> account to retrieve certificates for load balancing TLS connections.
> >> Users must grant Octavia read permissions in advance.
> >
> >OK, so it sounds like we do need to continue to support both
> >approaches to authentication.
> >
> >> Keystone is currently the only authentication option for Barbican.  I
> >> believe the proposal to decouple keystoneauth is advance work for adding
> >> new auth methods and backends as future work.  Vault and Custodia are
> >>two
> >> such backends in progress.  They don't support keystoneauth and likely
> >> won't, so we'll need alternatives.
> >
> >Each driver manages its own authentication, right? Why do we need to
> >remove the keystoneauth stuff in the barbican driver in order to enable
> >other drivers?
> 
> I would use the word "decouple", with the intent to give the option of
> using Castellan without having a dependency on keystoneauth.  But, I don't
> want to speak for original posters who used the word "remove" in case they
> have other ideas.
> 
> Until recently Barbican was the only secret store and Keystone was the
> only authentication service, so we didn't have to sort through the
> modularity.

I'm sorry that I missed the conversation about this in Denver.  It
seems like everyone else understands what's being proposed in a way
very different than I do, so I apologize for continuing to just ask
the same questions.  I'll try rephrasing, but it would be *very*
helpful if someone would summarize that discussion and lay out the
plan in more detail than "we want to remove the use of keystoneauth."
If we can't do it by email, then maybe via an Oslo spec.


The barbican driver has 2 modes for using keystoneauth. One is to
use the use the execution context to authenticate using the same
token that the current user passed in to the service calling into
castellan. The other is to use credentials from the configuration
file.

Those options seem to be pretty well abstracted in the API, so that
the application using castellan can just pass the right sort of
context and get the right behavior from the driver, without having
to know what the driver is. We currently only have a barbican driver,
and that driver uses keystoneauth directly because that is the only
way to control which authentication mode is used. Other drivers
would presumably use some means other than keystoneauth to authenticate
to the backends they talk to, with the difference in behavior (acting
like the current user or acting like a service user) triggered by
the context passed in.

If we don't use keystoneauth inside the castellan driver before
creating the barbican client, how will we support both modes in the
castellan API without exposing to the application which secret store
driver is being used? We can't, for example, require that an
application configured to use the barbican driver pass more (or
different) information to castellan than it would pass if castellan
was configured to use custodia, because that would break the
abstraction.

Are there more extensive changes planned for the public API of
castellan, to use different mechanisms to get a driver handle for
the different modes?  Given our backwards-compatibility constraints,
we can't change the API of the library in a breaking way without
also updating the consuming apps, so we would have to *add* an API
and deprecate the old one. I haven't seen anyone talk about a new
API, though.

Are we planning to drop support for one access mode, and change the
way castellan works more fundamentally? This possibility raises the
same questions as changing the API does.  Based on the compatibility
constraints for an Oslo library, we need to continue to support
both of modes until we are sure they are not being used by any of
our applications.

Doug