On Sat, Dec 5, 2015 at 2:26 PM, Xav Paice <xavpa...@gmail.com> wrote: >> >> >> 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. >
That is a great point, and I agree that there needs to be a way to filter admin requests. Thanks, Curtis. > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > -- Blog: serverascode.com _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
