Open Stack

On Tue, Dec 12, 2017 at 5:34 PM, Doug Hellmann <doug at doughellmann.com>
wrote:

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

I wonder if we could make keystoneauth a soft requirement instead for those
using
the Barbican driver as a way to de-couple it?  Then if one were to use a
different
backend (Vault/Custodia/etc.) it wouldn't be needed.

Not sure how having different backends will be though
(Barbican/Vault/Custodia) in terms
of breaking 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.
>

I'm not sure about these, maybe someone on the Castellan team could chime
in here.


>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171219/d302a116/attachment.html>