Open Stack

Excerpts from Stephen Balukoff's message of 2014-04-18 10:36:11 -0700:
> Dang.  I was hoping this wasn't the case.  (I personally think it's a
> little silly not to trust your service provider to secure a network when
> they have root access to all the machines powering your cloud... but I
> digress.)
> 

No one person or even group of people on the operator's network will have
full access to everything. Security is best when it comes in layers. Area
51 doesn't just have a guard shack and then you drive right into the
hangars with the UFO's and alien autopsies. There are sensors, mobile
guards, secondary checkpoints, locks on the outer doors, and locks on
the inner doors. And perhaps most importantly, the MP who approves your
entry into the first gate, does not even have access to the next one.

Your SSL terminator is a gate. What happens once an attacker (whoever
that may be, your disgruntled sysadmin, or rogue hackers) is behind that
gate _may_ be important.

> Part of the reason I was hoping this wasn't the case, isn't just because it
> consumes a lot more CPU on the load balancers, but because now we
> potentially have to manage client certificates and CA certificates (for
> authenticating from the proxy to back-end app servers). And we also have to
> decide whether we allow the proxy to use a different client cert / CA per
> pool, or per member.
> 
> Yes, I realize one could potentially use no client cert or CA (ie.
> encryption but no auth)...  but that actually provides almost no extra
> security over the unencrypted case:  If you can sniff the traffic between
> proxy and back-end server, it's not much more of a stretch to assume you
> can figure out how to be a man-in-the-middle.
>

A passive attack where the MITM does not have to witness the initial
handshake or decrypt/reencrypt to sniff things is quite a bit easier to
pull off and would be harder to detect. So "almost no extra security"
is not really accurate. But this is just one point of data for risk
assessment.

> Do any of you have a use case where some back-end members require SSL
> authentication from the proxy and some don't? (Again, deciding whether
> client cert / CA usage should attach to a "pool" or to a "member.")
> 
> It's a bit of a rabbit hole, eh.
>

Security turns into an endless rat hole when you just look at it as a
product, such as "A secure load balancer."

If, however, you consider that it is really just a process of risk
assessment and mitigation, then you can find a sweet spot that works
in your business model. "How much does it cost to mitigate the risk
of unencrypted backend traffic from the load balancer?  What is the
potential loss if the traffic is sniffed? How likely is it that it will
be sniffed?" .. Those are ongoing questions that need to be asked and
then reevaluated, but they don't have a fruitless stream of what-if's
that have to be baked in like the product discussion. It's just part of
your process, and processes go on until they aren't needed anymore.

IMO a large part of operating a cloud is decoupling the ability to setup
a system from the ability to enable your business with a system. So
if you can communicate the risks of doing without backend encryption,
and charge the users appropriately when they choose that the risk is
worth the added cost, then I think it is worth it to automate the setup
of CA's and client certs and put that behind an API. Luckily, you will
likely find many in the OpenStack community who can turn that into a
business opportunity and will help.