Open Stack

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.