Open Stack

On Sat, Dec 5, 2015 at 2:26 PM, Xav Paice <xavpaice at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Blog: serverascode.com