[openstack-dev] [Heat] rough draft of Heat autoscaling API

Zane Bitter zbitter at redhat.com
Fri Nov 15 10:16:19 UTC 2013

On 14/11/13 19:58, Christopher Armstrong wrote:
> On Thu, Nov 14, 2013 at 10:44 AM, Zane Bitter <zbitter at redhat.com
> <mailto:zbitter at redhat.com>> 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 

> 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.


More information about the OpenStack-dev mailing list