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? Steve _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
