<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 12, 2017 at 5:34 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Excerpts from Dave McCowan (dmccowan)'s message of 2017-12-12 21:36:51 +0000:<br>
><br>
> On 12/12/17, 3:15 PM, "Doug Hellmann" <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br>
><br>
> >Excerpts from Dave McCowan (dmccowan)'s message of 2017-12-12 19:56:49<br>
> >+0000:<br>
> >><br>
> >> On 12/12/17, 10:38 AM, "Doug Hellmann" <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br>
> >><br>
> >> ><br>
> >> >> On Dec 12, 2017, at 9:42 AM, Paul Bourke <<a href="mailto:paul.bourke@oracle.com">paul.bourke@oracle.com</a>><br>
> >>wrote:<br>
> >> >><br>
> >> >> From my understanding it would be a cleanup operation - which to be<br>
> >> >>honest, would be very much welcomed. I recently did a little work with<br>
> >> >>Castellan to integrate it with Murano and found the auth code to be<br>
> >>very<br>
> >> >>messy, and flat out broken in some cases. If it's possible to let the<br>
> >> >>barbican client take care of this that sounds good to me.<br>
> >> >><br>
> >> >> > Which mode is used the most in the services that consume castellan<br>
> >> >> > today?<br>
> >> >><br>
> >> >> Afaik Barbican is the only backend that currently exists in Castellan<br>
> >> >>[0]. Looking again it seems some support has been added for vault<br>
> >>which<br>
> >> >>is great, but I reckon Barbican would still be the primary use.<br>
> >> >><br>
> >> >> I haven't been hugely active in Castellan but if the team would like<br>
> >> >>some more input on this or reviews please do ping me, I'd be glad to<br>
> >> >>help.<br>
> >> ><br>
> >> >What I mean is, in the services consuming Castellan, how do they expect<br>
> >> >it to authenticate to Barbican? As the current user or as a hard-coded<br>
> >> >fixed user controlled by the deployer? I would think most services<br>
> >>would<br>
> >> >need to connect as the ³current² user talking to them so they can<br>
> >>access<br>
> >> >that user¹s secrets from Barbican. Removing the keystoneauth stuff from<br>
> >> >the driver would therefore break all of those applications.<br>
> >> ><br>
> >> >Doug<br>
> >><br>
> >> We're a mix right now.  Nova and Cinder pass through the a user's token<br>
> >>to<br>
> >> retrieve the user's key for encrypted volumes.  Octavia uses its service<br>
> >> account to retrieve certificates for load balancing TLS connections.<br>
> >> Users must grant Octavia read permissions in advance.<br>
> ><br>
> >OK, so it sounds like we do need to continue to support both<br>
> >approaches to authentication.<br>
> ><br>
> >> Keystone is currently the only authentication option for Barbican.  I<br>
> >> believe the proposal to decouple keystoneauth is advance work for adding<br>
> >> new auth methods and backends as future work.  Vault and Custodia are<br>
> >>two<br>
> >> such backends in progress.  They don't support keystoneauth and likely<br>
> >> won't, so we'll need alternatives.<br>
> ><br>
> >Each driver manages its own authentication, right? Why do we need to<br>
> >remove the keystoneauth stuff in the barbican driver in order to enable<br>
> >other drivers?<br>
><br>
> I would use the word "decouple", with the intent to give the option of<br>
> using Castellan without having a dependency on keystoneauth.  But, I don't<br>
> want to speak for original posters who used the word "remove" in case they<br>
> have other ideas.<br>
><br>
> Until recently Barbican was the only secret store and Keystone was the<br>
> only authentication service, so we didn't have to sort through the<br>
> modularity.<br>
<br>
I'm sorry that I missed the conversation about this in Denver.  It<br>
seems like everyone else understands what's being proposed in a way<br>
very different than I do, so I apologize for continuing to just ask<br>
the same questions.  I'll try rephrasing, but it would be *very*<br>
helpful if someone would summarize that discussion and lay out the<br>
plan in more detail than "we want to remove the use of keystoneauth."<br>
If we can't do it by email, then maybe via an Oslo spec.<br>
<br>
<br>
The barbican driver has 2 modes for using keystoneauth. One is to<br>
use the use the execution context to authenticate using the same<br>
token that the current user passed in to the service calling into<br>
castellan. The other is to use credentials from the configuration<br>
file.<br>
<br>
Those options seem to be pretty well abstracted in the API, so that<br>
the application using castellan can just pass the right sort of<br>
context and get the right behavior from the driver, without having<br>
to know what the driver is. We currently only have a barbican driver,<br>
and that driver uses keystoneauth directly because that is the only<br>
way to control which authentication mode is used. Other drivers<br>
would presumably use some means other than keystoneauth to authenticate<br>
to the backends they talk to, with the difference in behavior (acting<br>
like the current user or acting like a service user) triggered by<br>
the context passed in.<br>
<br>
If we don't use keystoneauth inside the castellan driver before<br>
creating the barbican client, how will we support both modes in the<br>
castellan API without exposing to the application which secret store<br>
driver is being used? We can't, for example, require that an<br>
application configured to use the barbican driver pass more (or<br>
different) information to castellan than it would pass if castellan<br>
was configured to use custodia, because that would break the<br>
abstraction.<br></blockquote><div><br></div><div>I wonder if we could make keystoneauth a soft requirement instead for those using</div><div>the Barbican driver as a way to de-couple it?  Then if one were to use a different</div><div>backend (Vault/Custodia/etc.) it wouldn't be needed.</div><div><br></div><div>Not sure how having different backends will be though (Barbican/Vault/Custodia) in terms</div><div>of breaking abstraction.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Are there more extensive changes planned for the public API of<br>
castellan, to use different mechanisms to get a driver handle for<br>
the different modes?  Given our backwards-compatibility constraints,<br>
we can't change the API of the library in a breaking way without<br>
also updating the consuming apps, so we would have to *add* an API<br>
and deprecate the old one. I haven't seen anyone talk about a new<br>
API, though.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Are we planning to drop support for one access mode, and change the<br>
way castellan works more fundamentally? This possibility raises the<br>
same questions as changing the API does.  Based on the compatibility<br>
constraints for an Oslo library, we need to continue to support<br>
both of modes until we are sure they are not being used by any of<br>
our applications.<br></blockquote><div><br></div><div>I'm not sure about these, maybe someone on the Castellan team could chime in here.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Doug<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br></div></div>