Removing Keystoneauth Dependency in Castellan Discussion

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Removing Keystoneauth Dependency in Castellan Discussion

ARORA, ROHAN

Wanted to start a thread to discuss the potential removal of the Keystoneauth dependency from Castellan. Whether it is needed or not, approaches we might want to take, etc.

From my understanding, Tin, Gage, and Ade discussed this at the Sydney summit, so we were hoping for some details/clarifications before getting to work on it.

 

Best,

Rohan


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing Keystoneauth Dependency in Castellan Discussion

Doug Hellmann-2
Excerpts from ARORA, ROHAN's message of 2017-12-04 21:47:45 +0000:
> Wanted to start a thread to discuss the potential removal of the Keystoneauth dependency from Castellan. Whether it is needed or not, approaches we might want to take, etc.
> From my understanding, Tin, Gage, and Ade discussed this at the Sydney summit, so we were hoping for some details/clarifications before getting to work on it.
>
> Best,
> Rohan

My understanding is that keystone is used when the barbican driver
is invoked. So I don't understand how we can remove the dependency
completely. We could possibly make it an "extras" so that it is
only installed if the barbican driver is going to be used. Is that
what you mean?

Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing Keystoneauth Dependency in Castellan Discussion

ARORA, ROHAN
I do believe that was something Tin mentioned after I had talked to him after our IRC chat last week. Seems like the right way to go. Tin?

Best,
Rohan

-----Original Message-----
From: Doug Hellmann [mailto:[hidden email]]
Sent: Monday, December 04, 2017 4:00 PM
To: openstack-dev <[hidden email]>
Subject: Re: [openstack-dev] Removing Keystoneauth Dependency in Castellan Discussion

Excerpts from ARORA, ROHAN's message of 2017-12-04 21:47:45 +0000:
> Wanted to start a thread to discuss the potential removal of the Keystoneauth dependency from Castellan. Whether it is needed or not, approaches we might want to take, etc.
> From my understanding, Tin, Gage, and Ade discussed this at the Sydney summit, so we were hoping for some details/clarifications before getting to work on it.
>
> Best,
> Rohan

My understanding is that keystone is used when the barbican driver
is invoked. So I don't understand how we can remove the dependency
completely. We could possibly make it an "extras" so that it is
only installed if the barbican driver is going to be used. Is that
what you mean?

Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=HrszLFXMaQd7t9slUzbd4w&m=FujA9G4eVEAZYg6NIXvhNicVpcBdHJAIW-ZRJ2yeNjs&s=3x2COEHUcYS41wWEg97O9AmICZre8dUTMw_77FOWpeU&e= 
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing Keystoneauth Dependency in Castellan Discussion

ARORA, ROHAN
In reply to this post by Doug Hellmann-2
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.

Best,
Rohan

-----Original Message-----
From: Doug Hellmann [mailto:[hidden email]]
Sent: Monday, December 04, 2017 4:00 PM
To: openstack-dev <[hidden email]>
Subject: Re: [openstack-dev] Removing Keystoneauth Dependency in Castellan Discussion

Excerpts from ARORA, ROHAN's message of 2017-12-04 21:47:45 +0000:
> Wanted to start a thread to discuss the potential removal of the Keystoneauth dependency from Castellan. Whether it is needed or not, approaches we might want to take, etc.
> From my understanding, Tin, Gage, and Ade discussed this at the Sydney summit, so we were hoping for some details/clarifications before getting to work on it.
>
> Best,
> Rohan

My understanding is that keystone is used when the barbican driver
is invoked. So I don't understand how we can remove the dependency
completely. We could possibly make it an "extras" so that it is
only installed if the barbican driver is going to be used. Is that
what you mean?

Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=HrszLFXMaQd7t9slUzbd4w&m=FujA9G4eVEAZYg6NIXvhNicVpcBdHJAIW-ZRJ2yeNjs&s=3x2COEHUcYS41wWEg97O9AmICZre8dUTMw_77FOWpeU&e= 
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing Keystoneauth Dependency in Castellan Discussion

Doug Hellmann-2
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: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing Keystoneauth Dependency in Castellan Discussion

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

On Tue, Dec 5, 2017 at 10:54 AM, Doug Hellmann <[hidden email]> 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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing Keystoneauth Dependency in Castellan Discussion

Doug Hellmann-2
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 <[hidden email]>
> 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: [hidden email]?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [castellan] Removing Keystoneauth Dependency in Castellan Discussion

Paul Bourke-3
 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.

-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 <[hidden email]>
>> 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: [hidden email]?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [castellan] Removing Keystoneauth Dependency in Castellan Discussion

Doug Hellmann-2

> On Dec 12, 2017, at 9:42 AM, Paul Bourke <[hidden email]> 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 <[hidden email]>
>>> 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: [hidden email]?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: [hidden email]?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [castellan] Removing Keystoneauth Dependency in Castellan Discussion

Dave McCowan (dmccowan)


On 12/12/17, 10:38 AM, "Doug Hellmann" <[hidden email]> wrote:

>
>> On Dec 12, 2017, at 9:42 AM, Paul Bourke <[hidden email]> 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.

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.

Reviews and contributions to Castellan and Barbican have been light over
the last cycle, while deployment interest and feature requests have been
high.  Any help will be appreciated!

--Dave


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [castellan] Removing Keystoneauth Dependency in Castellan Discussion

Doug Hellmann-2
Excerpts from Dave McCowan (dmccowan)'s message of 2017-12-12 19:56:49 +0000:

>
> On 12/12/17, 10:38 AM, "Doug Hellmann" <[hidden email]> wrote:
>
> >
> >> On Dec 12, 2017, at 9:42 AM, Paul Bourke <[hidden email]> 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?

>
> Reviews and contributions to Castellan and Barbican have been light over
> the last cycle, while deployment interest and feature requests have been
> high.  Any help will be appreciated!
>
> --Dave
>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [castellan] Removing Keystoneauth Dependency in Castellan Discussion

Dave McCowan (dmccowan)


On 12/12/17, 3:15 PM, "Doug Hellmann" <[hidden email]> 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" <[hidden email]> wrote:
>>
>> >
>> >> On Dec 12, 2017, at 9:42 AM, Paul Bourke <[hidden email]>
>>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.


>
>>
>> Reviews and contributions to Castellan and Barbican have been light over
>> the last cycle, while deployment interest and feature requests have been
>> high.  Any help will be appreciated!
>>
>> --Dave
>>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [castellan] Removing Keystoneauth Dependency in Castellan Discussion

Doug Hellmann-2
Excerpts from Dave McCowan (dmccowan)'s message of 2017-12-12 21:36:51 +0000:

>
> On 12/12/17, 3:15 PM, "Doug Hellmann" <[hidden email]> 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" <[hidden email]> wrote:
> >>
> >> >
> >> >> On Dec 12, 2017, at 9:42 AM, Paul Bourke <[hidden email]>
> >>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

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [castellan] Removing Keystoneauth Dependency in Castellan Discussion

Gage Hugo


On Tue, Dec 12, 2017 at 5:34 PM, Doug Hellmann <[hidden email]> 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" <[hidden email]> 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" <[hidden email]> wrote:
> >>
> >> >
> >> >> On Dec 12, 2017, at 9:42 AM, Paul Bourke <[hidden email]>
> >>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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [castellan] Removing Keystoneauth Dependency in Castellan Discussion

Doug Hellmann-2
Excerpts from Gage Hugo's message of 2017-12-19 11:14:18 -0600:

> On Tue, Dec 12, 2017 at 5:34 PM, Doug Hellmann <[hidden email]>
> 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" <[hidden email]> 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" <[hidden email]> wrote:
> > > >>
> > > >> >
> > > >> >> On Dec 12, 2017, at 9:42 AM, Paul Bourke <[hidden email]>
> > > >>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.

I hope it doesn't break anything. The point of Castellan was to provide
that abstraction, right? :-)

We could work on making keystoneauth a driver-specific requirement for
castellan during rocky. Effectively it's not going to make much
difference, because currently everything that uses casetellan also
relies on talking to keystone for other reasons so keystoneauth is still
going to need to be installed. But we can adjust the requirements using
the "extras" feature of setuptools to clarify which drivers use each
dependency.

>
> >
> > 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: [hidden email]?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev