Open Stack

> > So here's a random half-formed thought, suppose the nova-compute
> > service exposed a public REST API directly for purposes such as
> > these? So that diagnostics could be retrieved directly from the
> > nova-compute nodes without either involving nova-api or using the
> > internal RPC mechanism.
> 
> nova-compute is the least trusted part of nova.  Because of this,
> we're doing work to lock it down and isolate it the best we can from
> the rest of the system, so that we can limit the potential affects
> of compromising a compute node.  This includes removing direct
> database access and adding much richer security to the rpc layer.
> 
> My concern with adding a REST API directly to compute nodes would be
> that it opens up a new interface we have to figure out a security
> model for.

That's an interesting thought - up to now the ceilometer agents have
been an considered an "implicitly trusted" part of the internal fabric
that didn't need explicit auth. 

So clearly if we were to use a ceilo->nova conduit that also allowed
actions to be initiated (e.g. by exposing the nova-compute RPC API to 
the ceilo compute agent) then yep, we'd need to bring auth into the
equation with all that entails in terms of overhead and additional hops
to keystone.

But suppose for a second that we conceived a purely read-only REST API
for nova-compute, that exposed no more information than could be gleaned
directly from the hypervisor driver, and didn't allow any potentially
destructive actions to be initiated.

In that case, would we still require a fully formed security model?

(Say we were also happy enough with simple local rate limiting to protect
the service from DoSing).

Cheers,
Eoghan