Re: [openstack-dev] [keystone][monasca][congress][senlin][telemetry] authenticated webhook notifications
Thank you, Zane for the discussion. Point taken about sending webhook notifications. Primarily I want Congress to consume webhook notifications from the openstack services which already send them (monasca, vitrage, etc.). Most of them do not currently support sending appropriate keystone tokens with the notifications, but some are open to doing it. The aodh and zaqar references are exactly what I was hoping to find. I couldn't find a reference to it in aodh docs or much on google, so many thanks for the pointer! Eric On 5/8/18, 1:20 PM, "Zane Bitter" wrote: >If the caller is something that is basically trusted, then you should >prefer regular keystone auth. If you need to make sure that the caller >can only use that one API, signed URLs are still the only game in town >for now (but we hope this is very temporary). > >> I know some people are working on adding the keystone auth option to >> Monasca's webhook framework. If there is a project that already does it, >> it could be a very helpful reference. > >There's a sort of convention that where you supply a webhook URL with a >scheme trust+https:// then the service creates a keystone trust and uses >that to get keystone tokens which are then used to authenticate the >webhook request. Aodh and Zaqar at least follow this convention. The >trust part is an important point that you're overlooking: (from your >other message) __ 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][monasca][congress][senlin][telemetry] authenticated webhook notifications
On 03/05/18 15:49, Eric K wrote: Question to the projects which send or consume webhook notifications (telemetry, monasca, senlin, vitrage, etc.), what are your supported/preferred authentication mechanisms? Bearer token (e.g. Keystone)? Signing? Signed URLs and regular Keystone auth are both options, and both used in various places as Thomas said. Any time you can not implement your own signed URL thing, it's better that you don't though. Security-sensitive things like authentication should be implemented as few times as possible. Eventually we should be able to mostly eliminate the need for signed URLs with http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/capabilities-app-creds.html but we're not there yet. If the caller is something that is basically trusted, then you should prefer regular keystone auth. If you need to make sure that the caller can only use that one API, signed URLs are still the only game in town for now (but we hope this is very temporary). Any pointers to past discussions on the topic? My interest here is having Congress consume and send webhook notifications. Please don't. Webhooks are a security nightmare. They can be used to enlist the OpenStack infrastructure in mounting attacks on other random sites, or to attack the OpenStack operator themselves if everything is not properly secured. Ideally there should be only one place in OpenStack that can send webhooks, so that there's only one thing for operators to secure. (IMHO since that thing will need to keep a queue of pending webhooks to send, the logical place would be Zaqar notifications.) Obviously that's not the case today - we already send webhooks from Aodh, Mistral, Zaqar and others. But at least we can avoid adding more. I know some people are working on adding the keystone auth option to Monasca's webhook framework. If there is a project that already does it, it could be a very helpful reference. There's a sort of convention that where you supply a webhook URL with a scheme trust+https:// then the service creates a keystone trust and uses that to get keystone tokens which are then used to authenticate the webhook request. Aodh and Zaqar at least follow this convention. The trust part is an important point that you're overlooking: (from your other message) I'm thinking about the situation where the sending service can obtain tokens directly from keystone. If you haven't stored the user's password then you cannot, in fact, obtain more tokens from keystone. You only have the one they gave you with the initial request, and that will soon expire. So you have to create a trust (which doesn't expire) and store the trust ID, which you can then use in combination with the service token to get additional user tokens from when required. Don't do that though. Just create a Zaqar queue, store a pre-signed URL that allows you to post to it, and set up a Zaqar notification for the webhook URL you want to hit (which can be a trust+https:// URL). Avoid being the next project to reinvent the wheel :) cheers, Zane. __ 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][monasca][congress][senlin][telemetry] authenticated webhook notifications
To clarify, one of the reasons I'd like to accept webhook notifications authenticated with keystone tokens is that I don't want the access to expire, but of course it's poor practice to use a signed URL that never expires. Eric On 5/8/18, 12:29 PM, "Eric K" wrote: >Thanks, Thomas! > >I see the point that it is impractical to configure a service with a fixed >keystone token to use in webhook notifications because they expire fairly >quickly. > >I'm thinking about the situation where the sending service can obtain >tokens directly from keystone. In that case I'm guessing the main reason >it hasn't been done that way is because it does not generalize to most >other services that don't connect to keystone? > >On 5/6/18, 9:30 AM, "Thomas Herve" wrote: > >>On Sat, May 5, 2018 at 1:53 AM, Eric K wrote: >>> Thanks a lot Witold and Thomas! >>> >>> So it doesn't seem that someone is currently using a keystone token to >>> authenticate web hook? Is is simply because most of the use cases had >>> involved services which do not use keystone? >>> >>> Or is it unsuitable for another reason? >> >>It's fairly impractical for webhooks because >> >>1) Tokens expire fairly quickly. >>2) You can't store all the data in the URL, so you need to store the >>token and the URL separately. >> >>-- >>Thomas >> >>_ >>_ >>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][monasca][congress][senlin][telemetry] authenticated webhook notifications
Thanks, Thomas! I see the point that it is impractical to configure a service with a fixed keystone token to use in webhook notifications because they expire fairly quickly. I'm thinking about the situation where the sending service can obtain tokens directly from keystone. In that case I'm guessing the main reason it hasn't been done that way is because it does not generalize to most other services that don't connect to keystone? On 5/6/18, 9:30 AM, "Thomas Herve" wrote: >On Sat, May 5, 2018 at 1:53 AM, Eric K wrote: >> Thanks a lot Witold and Thomas! >> >> So it doesn't seem that someone is currently using a keystone token to >> authenticate web hook? Is is simply because most of the use cases had >> involved services which do not use keystone? >> >> Or is it unsuitable for another reason? > >It's fairly impractical for webhooks because > >1) Tokens expire fairly quickly. >2) You can't store all the data in the URL, so you need to store the >token and the URL separately. > >-- >Thomas > >__ >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][monasca][congress][senlin][telemetry] authenticated webhook notifications
On Sat, May 5, 2018 at 1:53 AM, Eric K wrote: > Thanks a lot Witold and Thomas! > > So it doesn't seem that someone is currently using a keystone token to > authenticate web hook? Is is simply because most of the use cases had > involved services which do not use keystone? > > Or is it unsuitable for another reason? It's fairly impractical for webhooks because 1) Tokens expire fairly quickly. 2) You can't store all the data in the URL, so you need to store the token and the URL separately. -- Thomas __ 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][monasca][congress][senlin][telemetry] authenticated webhook notifications
Thanks a lot Witold and Thomas! So it doesn't seem that someone is currently using a keystone token to authenticate web hook? Is is simply because most of the use cases had involved services which do not use keystone? Or is it unsuitable for another reason? On 5/4/18, 2:36 AM, "Thomas Herve" wrote: >On Thu, May 3, 2018 at 9:49 PM, Eric K wrote: >> Question to the projects which send or consume webhook notifications >> (telemetry, monasca, senlin, vitrage, etc.), what are your >> supported/preferred authentication mechanisms? Bearer token (e.g. >> Keystone)? Signing? >> >> Any pointers to past discussions on the topic? My interest here is >>having >> Congress consume and send webhook notifications. >> >> I know some people are working on adding the keystone auth option to >> Monasca's webhook framework. If there is a project that already does it, >> it could be a very helpful reference. > >Hi, > >I'll add a few that you didn't mention which consume such webhooks. > > * Heat has been using EC2 signatures basically since forever. It >creates EC2 credentials for a Keystone user, and signs URL that way. > * Zaqar has signed URLs >(https://developer.openstack.org/api-ref/message/#pre-signed-queue) >which allows sharing queues without authentication. > * Swift temp URLs >(https://docs.openstack.org/swift/latest/middleware.html#tempurl) is a >good mechanism to share information as well. > >I'd say application credentials would make those operations a bit >nicer, but they are not completely there yet. Everybody not >reinventing its own wheel would be nice too :). > >-- >Thomas > >__ >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][monasca][congress][senlin][telemetry] authenticated webhook notifications
On Thu, May 3, 2018 at 9:49 PM, Eric K wrote: > Question to the projects which send or consume webhook notifications > (telemetry, monasca, senlin, vitrage, etc.), what are your > supported/preferred authentication mechanisms? Bearer token (e.g. > Keystone)? Signing? > > Any pointers to past discussions on the topic? My interest here is having > Congress consume and send webhook notifications. > > I know some people are working on adding the keystone auth option to > Monasca's webhook framework. If there is a project that already does it, > it could be a very helpful reference. Hi, I'll add a few that you didn't mention which consume such webhooks. * Heat has been using EC2 signatures basically since forever. It creates EC2 credentials for a Keystone user, and signs URL that way. * Zaqar has signed URLs (https://developer.openstack.org/api-ref/message/#pre-signed-queue) which allows sharing queues without authentication. * Swift temp URLs (https://docs.openstack.org/swift/latest/middleware.html#tempurl) is a good mechanism to share information as well. I'd say application credentials would make those operations a bit nicer, but they are not completely there yet. Everybody not reinventing its own wheel would be nice too :). -- Thomas __ 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
