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