On Tue, Dec 12, 2017 at 5:34 PM, Doug Hellmann <d...@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" <d...@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" <d...@doughellmann.com> wrote: > > >> > > >> > > > >> >> On Dec 12, 2017, at 9:42 AM, Paul Bourke <paul.bou...@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-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
