Re: [openstack-dev] Stepping down as keystone core

[Gage Hugo]

Thanks for all the help Samuel.  I remember a couple instances when I first
started contributing to keystone where you helped me out and I am extremely
grateful.  It was great working with you, and hopefully we will still see
you around!

On Wed, Aug 29, 2018 at 2:33 PM Lance Bragstad  wrote:

> Samuel,
>
> Thanks for all the dedication and hard work upstream. I'm relieved that
> you won't be too far away and that you're still involved with the Outreachy
> programs. You played an instrumental role in getting keystone involved with
> that community.
>
> As always, we'd be happy to have you back in the event your work involves
> keystone again.
>
> Best,
>
> Lance
>
> On Wed, Aug 29, 2018 at 2:25 PM Samuel de Medeiros Queiroz <
> samuel...@gmail.com> wrote:
>
>> Hi Stackers!
>>
>> It has been both an honor and privilege to serve this community as a
>> keystone core.
>>
>> I am in a position that does not allow me enough time to devote reviewing
>> code and participating of the development process in keystone. As a
>> consequence, I am stepping down as a core reviewer.
>>
>> A big thank you for your trust and for helping me to grow both as a
>> person and as professional during this time in service.
>>
>> I will stay around: I am doing research on interoperability for my
>> masters degree, which means I am around the SDK project. In addition to
>> that, I recently became the Outreachy coordinator for OpenStack.
>>
>> Let me know if you are interested on one of those things.
>>
>> Get in touch on #openstack-outreachy, #openstack-sdks or
>> #openstack-keystone.
>>
>> Thanks,
>> Samuel de Medeiros Queiroz (samueldmq)
>> __
>> 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
>
__
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

Re: [openstack-dev] [keystone] Signing off

[Gage Hugo]

It was great working with you Henry.  Hope to see you around sometime and
wishing you all the best!

On Wed, May 30, 2018 at 3:45 AM, Henry Nash  wrote:

> Hi
>
> It is with a somewhat heavy heart that I have decided that it is time to
> hang up my keystone core status. Having been involved since the closing
> stages of Folsom, I've had a good run! When I look at how far keystone has
> come since the v2 days, it is remarkable - and we should all feel a sense
> of pride in that.
>
> Thanks to all the hard work, commitment, humour and support from all the
> keystone folks over the years - I am sure we will continue to interact and
> meet among the many other open source projects that many of us are becoming
> involved with. Ad astra!
>
> Best regards,
>
> Henry
> Twitter: @henrynash
> linkedIn: www.linkedin.com/in/henrypnash
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> __
> 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

[openstack-dev] [security sig] No meeting May 24th

[Gage Hugo]

Hello,

Due to members attending the OpenStack summit in Vancouver, we will be
canceling the Security SIG meeting on May 24th.
__
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

Re: [openstack-dev] [security] Tomorrow's meeting and LCOO

[Gage Hugo]

Hey Luke,

I can chair the meeting tomorrow if that works.

I will also ping eeiden about getting some LCOO discussion going as well.

On Wed, Mar 14, 2018 at 1:35 PM, Luke Hinds  wrote:

> Hello,
>
> Something has come up that determines I won't be able to attend the
> meeting tomorrow and more importantly chair it.
>
> However I would not want to be a bottleneck to good progress underway.
>
> If someone would like to step up and chair for just this meeting, the
> agenda is below:
>
> https://etherpad.openstack.org/p/security-agenda
>
> Also keep in mind, we now meet in #openstack-meeting at 15:00, instead of
> 17:00.
>
> If not, we will defer and meet the week after.
>
> Last point, someone called eeiden pinged me on IRC, but have since logged
> out. They LCOO has an interest in working with the security SIG, which is
> most welcome. If anyone knows eeiden, can you ask him / her to contact us
> on this list and we can get initial discussions going and hopefully bring
> them into the meeting too.
>
> Cheers,
>
> Luke
>
__
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

Re: [openstack-dev] [castellan] Removing Keystoneauth Dependency in Castellan Discussion

[Gage Hugo]

On Tue, Dec 12, 2017 at 5:34 PM, Doug Hellmann 
wrote:

> Excerpts from Dave McCowan (dmccowan)'s message of 2017-12-12 21:36:51
> +:
> >
> > On 12/12/17, 3:15 PM, "Doug Hellmann"  wrote:
> >
> > >Excerpts from Dave McCowan (dmccowan)'s message of 2017-12-12 19:56:49
> > >+:
> > >>
> > >> On 12/12/17, 10:38 AM, "Doug Hellmann"  wrote:
> > >>
> > >> >
> > >> >> On Dec 12, 2017, at 9:42 AM, Paul Bourke 
> > >>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 

Re: [openstack-dev] 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 
wrote:

> Excerpts from ARORA, ROHAN's message of 2017-12-05 14:37:49 +:
> > 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-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

Re: [openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

[Gage Hugo]

This spec was discussed at the keystone meeting today and during the
conversation that continued afterwards, an idea of using the keystone
configuration to set a list of keys was mentioned.

The idea is that a cloud admin could define a list of keys that they need
for their setup within keystone's configuration file, then only those keys
will be valid for storing values in the project properties table.  Then
each call would check against the list of valid keys and deny any calls
that are sent with an invalid key.

This idea seems to help with the issue to avoid allowing anyone to throw
any arbitrary values into these project properties vs just a set number of
values.

On Sun, Nov 6, 2016 at 6:25 PM, Matt Riedemann 
wrote:

> On 11/4/2016 7:15 PM, Steve Martinelli wrote:
>
>> The keystone team has a new spec being proposed for the Ocata release,
>> it essentially boils down to adding properties / metadata for projects
>> (for now) [1].
>>
>> We have somewhat had support for this, we have an "extras" column
>> defined in our database schema, whatever a user puts in a request that
>> doesn't match up with our API, those key-values are dumped into the
>> "extras" column. It's not a pleasant user experience, since you can't
>> really "unset" the data easily, or grab it, or update it. There's
>> actually been patches to keystoneclient for getting around this, but its
>> rather hacky and hardcodes a lot of values [2] [3]
>>
>> I've added nova and cinder here since the APIs that are being proposed
>> are more or less carbon copies of what is available through their APIs
>> (for server and volumes, respectively). What has been your project's
>> experience with handling metadata / properties? I assume that its been
>> there a while and you can't remove it. If you could go back and redo
>> things, would you do it another way? Would you take a more purist stance
>> and enforce more strict APIs, metadata be damned?
>>
>> I also added horizon because i'm curious about the impact this causes
>> when representing a resource.
>>
>> Personally, I am for the idea, we've had numerous requests from
>> operators about providing this support and I like to make them happy.
>>
>> [1] https://review.openstack.org/#/c/36/
>> [2] https://review.openstack.org/#/c/375239/
>> [3] https://review.openstack.org/#/c/296246/
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> If you're going to do it, restrict the case and characters in the keys
> because if you don't you can get fits in the backend database wrinkles. See
> this nova spec for details:
>
> https://specs.openstack.org/openstack/nova-specs/specs/newto
> n/approved/lowercase-metadata-keys.html
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> 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