Friday, 28 November 2014

Cloud Paranoia? - Cloud Foundry, Confidential data, Public clouds.


I've been working with Cloud Foundry (CF) & BOSH for close to two years now. One repeating theme I've seen is customers asking for more and more protection for their data and network traffic, especially when CF is running in third party Cloud Infrastructure environments outside of their direct control.

There are two security scenarios I want to focus on, but this applies to almost all CF components, in both Public and Private infrastructure


Scenario 1 - Sensitive CF Application traffic.


CFs primary function is to allow Developers to build, run and scale applications easily, and it does an excellent job at this.

But what if you want to handle sensitive information with the applications you run on CF?

Here's a simplified diagram of the network interactions inside CF, and their protection.

We can see that a malicious cloud infrastructure provider (or a disgruntled employee, or talented blackhat with an APT) could intercept all the application traffic as it passes through the CF router in plain text. You're relying on the security of the infrastructure provider to protect your traffic.

Convincing auditors and security teams that credit card information, bank details, etc. are adequately protected could be problematic.



Scenario 2 - Admin/Developer Security


CF by default uses the same channels for Admin and Developer access as it does serving Application traffic. It's susceptible to network sniffing at the CF router, or the UAA.

If UAA tokens or user credentials are obtained through this method, this gives an attacker access to the CF API to make whatever changes the captured credentials have permission for.


Perimeter Security vs Defense in Depth


CF uses traditional perimeter security models, with some exceptions for internal(-ish) login and UAA calls.

We can enhance security by not trusting the internal networks and encrypting everything.

There are two ways we can do this. The first is the way CF has been evolving so far, with application protocol level encryption. This is effective, but the implementation of SSL in different components and frameworks varies enormously, and maintaining SSL keychains for all components if a maintenance headache.

The second way is ....


IPSEC


IPSEC has been around in it's current form since the early 2000s, it's mature and is supported natively by the Linux kernel. It's most well known as the basis for remote-access VPNs, but a
lesser known use is encrypting traffic between computers on the same network.



How does IPSEC work with Cloud Foundry?


I've developed a BOSH release that enforces IPSEC communication between BOSH deployed systems. Deployed on VMs alongside CF components, it transparently encrypts all traffic in transit.

No CF code changes are necessary, just a co-located IPSEC release alongside CF, and a customised deployment manifest.

An IPSEC policy is added for each member that is participating in the IPSEC mesh. This makes it possible to be selective about what is protected, as well as keeping traffic to unrelated systems (DNS, log servers, etc.) unencrypted.

An IKE daemon is used to rotate the encryption keys on a user defined schedule. The exact encryption policies are configurable through the BOSH manifest.

Future Cloud Foundry security features by CloudCredo.


CloudCredo are continually working on  features to improve the security and usability of Cloud Foundry.

No comments:

Post a comment