On 15/11/13 11:58, Steven Hardy wrote:
On Fri, Nov 15, 2013 at 11:16:19AM +0100, Zane Bitter wrote:
On 14/11/13 19:58, Christopher Armstrong wrote:
On 14/11/13 18:51, Randall Burt wrote:
Perhaps, but I also miss important information as a legitimate
caller as
to whether or not my scaling action actually happened or I've been a
little too aggressive with my curl commands. The fact that I get
anything other than 404 (which the spec returns if its not a
legit hook)
means I've found *something* and can simply call it endlessly in
a loop
causing havoc. Perhaps the web hooks *should* be authenticated? This
seems like a pretty large hole to me, especially if I can max
someone's
resources by guessing the right url.
Web hooks MUST be authenticated.
Do you mean they should have an X-Auth-Token passed? Or an X-Trust-ID?
Maybe an X-Auth-Token, though in many cases I imagine it would be
derived from a Trust. In any event, it should be something provided
by Keystone because that is where authentication implementations
belong in OpenStack.
The idea was that webhooks are secret (and should generally only be
passed around through automated systems, not with human interaction).
This is usually how webhooks work, and it's actually how they work now
in Heat -- even though there's a lot of posturing about signed requests
and so forth, in the end they are literally just secret URLs that give
you the capability to perform some operation (if you have the URL, you
don't need anything else to execute them). I think we should simplify
this to to just be a random revokable blob.
This is the weakest possible form of security - the whole secret
gets passed on the wire for every request and logged in innumerable
places. There's no protection at all against replay attacks (other
than, hopefully, SSL).
A signature, a timestamp and a nonce all seem like prudent
precautions to add.
So maybe we just use tokens and drop the whole pre-signed URL thing -
ceilometer can obtain a token, and call the AS API via the normal method
(i.e a call to a client lib, providing a token)
The main case where tokens are inconvenient is in-instance, where we'll
have to refresh them before they expire (24 hours by default), but
in-instance agents won't talk to the AS API directly, so why don't we just
simplify the discussion and say the AS API has to use normal token auth?
+1. Not having PKI sucks, but using the standard Keystone mechanisms
like this leaves the autoscaling API no more exposed than any other in
OpenStack.
I guess Ceilometer would have to acquire a trust from the user in order
to generate tokens for this callback?
cheers,
Zane.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
