Open Stack

Excerpts from Xav Paice's message of 2015-12-05 13:26:23 -0800:
> >
> >
> > >> SecurityAuditing/Accounting:
> > >> Having a separate internal API (for the OpenStack services) from the
> > >> Public API (for humans and remote automation), allows the operator to
> > >> apply a strict firewall in front of the public API to restrict access
> > >> from outside the cloud. Such a device may also help deflect/absorb a
> > >> DOS attack against the API. This firewall can be an encryption
> > >> endpoint, so the traffic can be unencrypted and examined or logged. I
> > >> wouldn't want the extra latency of such a firewall in front of all my
> > >> OpenStack internal service calls.
> > >>
> > >
> > > This one is rough. One way to do it is to simply host the firewall in
> > > a DMZ segment, setting up your routes for that IP to go through the
> > > firewall. This means multi-homing the real load balancer/app servers to
> > > have an IP that the firewall can proxy to directly.
> > >
> > > But I also have to point out that not making your internal servers pass
> > > through this is another example of a squishy center, trading security
> > > for performance.
> > >
> >
> 
> It's not just the firewall issue though - the Keystone adminurl and
> publicurl is important to us because it allows us to open the publicurl to
> customers, and know that admin actions are protected by another layer.  We
> don't want admin to be available to the public for any service - but we do
> want our customers to have API access.  With fancy url redirects and
> proxies we can achieve this with two sets of API servers, each with their
> own policy.json, but that's larger and more complex than necessary and
> would be better if the individual services were to reject 'admin' calls
> from the publicurl.

I respect that this is what works for you and we shouldn't require you to
change your ways without good reason. However, I just want to point out
that if you don't trust Keystone's own ACL's to prevent administrative
access by users who haven't been granted access, then you also don't
trust Keystone to keep users out of each-others accounts!

That said, if there really is a desire to keep admin functions separate
from user functions, why not formalize that and make it an entirely
separate service in the catalog? So far, Keystone is the only service
to make use of "adminurl". So a valid path forward is to simply make it
a different entry.