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

Christopher Armstrong chris.armstrong at rackspace.com
Fri Nov 15 14:54:50 UTC 2013


On Fri, Nov 15, 2013 at 4:16 AM, Zane Bitter <zbitter at redhat.com> wrote:

> 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 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.
>
>
I can get behind the idea of adding timestamp and nonce + signature for the
webhooks, as long as they're handled better than they are now :) i.e., the
webhook handler should assert that the timestamp is recent and
non-repeated. This probably means storing stuff in MySQL (or a centralized
in-memory DB). My understanding is that even though we have signed URLs for
webhooks in the current Heat autoscaling system, they're effectively just
static blobs.

My original proposal for simple webhooks was based entirely around the idea
that the current stuff is too complex, and offers no additional security
over a random string jammed into a URL. (signing a static random string
doesn't make it more guessable than the original random string...)

-- 
IRC: radix
Christopher Armstrong
Rackspace
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131115/56ea5dab/attachment.html>


More information about the OpenStack-dev mailing list