[Openstack-operators] Service Catalog TNG urls

Xav Paice xavpaice at gmail.com
Sat Dec 5 21:26:23 UTC 2015


>
>
> >> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151206/630d142c/attachment.html>


More information about the OpenStack-operators mailing list