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

Zane Bitter zbitter at redhat.com
Fri Nov 15 11:33:38 UTC 2013

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 

I guess Ceilometer would have to acquire a trust from the user in order 
to generate tokens for this callback?


More information about the OpenStack-dev mailing list