compliance containers microservices network_security operations pivotal_cloud_foundry security

6 Ways Pivotal Cloud Foundry 1.10 Improves Your Security Posture

Teams perform at their best when doing the easy thing is also the right thing. Doing the right thing means the secure and compliant thing too.

This philosophy is core to the design and architecture of Pivotal Cloud Foundry. We've detailed 6 ways the new version of the product helps your teams go fast while going secure.

1. Isolation Segments Simplify Compliance and Workload Isolation

Regulations and compliance rules may require you to run some apps isolated from the rest. That is now much easier in Pivotal Cloud Foundry with isolation segments.

Isolation segments direct a set of applications to a specific set of host VMs. This isolates the apps and their data from other workloads.

Before, this separation required creating new foundries. This workaround introduced its own set of complexities for operators. Isolation segments are a much better option.

Before – Separate Foundations

With Isolation Segments,

A Single Foundation

Ready to get started with isolation segments? It's easy because the feature is integrated into the platform. Just install the PCF Isolation Segment Tile (shown below). Then configure your networks, VM types, and specify your desired quantities of Gorouters and cells. From there, you can use the CLI to manage different segments.

Isolation segments in PCF mesh well with network virtualization tools like VMware NSX. Administrators can use use isolation segments in conjunction with NSX to verify that network traffic is in fact isolated as intended.

2. Enforce Granular Security Policies with Container-to-Container Networking

Container-to-container (C2C) networking is a beta feature in PCF 1.10. It uses the new networking stack in Cloud Foundry, first discussed here.

The genesis of this new approach: feedback from the community. Application Security Groups (ASGs), the legacy model, were deemed too broad and static. C2C networking offers many advantages, summarized in this table.

  ASGs

CF Networking Policies

Policy granularity From a space to an IP address range From a source app to a destination app
Scope For a space, org, or deployment For app to app only
Traffic direction Outbound control Policies apply for incoming packets from other app instances
Source app Is not known Is identified because of direct addressability
Policies take effect After app restart Immediately

C2C networking is a beta feature in PCF 1.10. It can be enabled via self-service.

NOTE: Policies, configurations, settings, and other implementation details of your usage during this beta period may not be automatically migrated when this feature goes GA. Contact your Pivotal account team with questions.

3. App-to-App Networking Policies Boost Security and Compliance

It's noted in the "policy granularity" row above, but it's worth a drill down. With C2C Networking, developers have a flat network across containers. This new network supports firewall rules at an app-level.

Use it to build and enforce policies that reject traffic from all sources other than pre-approved apps. Before, developers had to trust all inbound traffic from a network. The new approach, as shown below, offers far more security and control.

Container-to-container networking is a pluggable network stack. All containers have a single network interface and a single IP address on the overlay network. Policies control communication between apps – and they can be applied immediately, without a restart.

What's more, this feature supports workloads running HTTP/S and those running TCP/UDP. Move towards a zero-trust model for all your apps!

For even more protection, combine C2C networking with OAuth2 verification and app-level encryption.

4. Private Microservices can Use Private Routes

If you have a sneaking suspicion that we built C2C networking for microservices, you're right!

With C2C networking, microservices can now connect to each other directly. Register direct routes with client-side load balancing. Previously, traffic between apps needed to communicate through external load balancers and firewalls. Keep your topologies private to reduce the attack surface for your apps!

Want more info on how to use this feature in your Spring apps? Check out this tutorial:

And here's a quick GIF with a demo of how it works in the real world.

5. BOSH Add-Ons

Three optional modules for BOSH can improve your security posture:

  • Encryption in transit – now with support for PCF on Azure. The IPsec Add-on now supports Azure. Apply this module, and the traffic within your PCF components is encrypted in transit. This is a key enabler for PCI scenarios and other enterprise requirements.

  • ClamAV & File Integrity Monitoring, now in open beta. If you work in government or other highly regulated environments, the ClamAV Add-on is worth a look. This module, in open beta, adds optional anti-virus scanning to your stemcell. File Integrity Monitoring – also in open beta – adds important protection for enterprises.

6. New Banking Reference Architectures Incorporate Best Practices for Secure Setup

OK, not technically a feature, but it's still useful. Nearly all enterprises understand that being good at software is a requirement for relevance in the decades to come. Market conversations have shifted from "why do I need to do this?" to "how do I do this?" and "how do I do this safely and securely?"

A new Pivotal white paper aims to answer part of this question for the banking industry.

A logical reference architecture for Pivotal Cloud Foundry atop VMware vSphere with NSX, featuring three clusters.

Pivotal's engineers and architects have worked with seven of the top banks in recent years. Our team has refined "best practices" for how to best deploy PCF, and how to best develop modern apps. This insight helps customers reduce risk, and deliver high-quality software faster.

Our learnings are encapsulated in the white paper as reference architectures. These designs help banks deliver software continuously, in a secure and scalable way.

Read the paper to learn detailed answers to questions like:

  • What's included in Pivotal Cloud Foundry? How does it help my organization develop software faster and run more securely? How can I extend the platform with the data services I need? And how does the Spring framework fit into all this?

  • How should I deploy PCF in my datacenter? What about the public cloud? How can I get multi-site availability for my apps?

  • How do you run microservices and event-driven architectures on Pivotal Cloud Foundry?

  • What does an actual banking app look like on Pivotal Cloud Foundry and Spring Cloud Services?

Download the paper here (gated link).

Day 2 and Beyond

Our friends at VMware recently wrote about the hard reality of trying out new tech in an enterprise. A common stumbling block is what happens on day 2:

This is by far the number 1 challenge I hear about from customers considering how to move to a microservices application architecture. In fact, I recently had a Fortune 50 financial customer tell me they have more than 20 proof of concept projects around their company evaluating different platform, container, function as-a-service offering...most of them are stuck on security, networking and day 2 requirements like visibility, compliance, tenant isolation and availability.

These are hard problems. Pivotal spent the last several years solving these problems, in partnership with the largest companies around the world. The new features of Pivotal Cloud Foundry are just the latest milestone, with much more to yet to be done. Join us, and let's move forward together into the world of Day 2.

Learn more about other new features in Pivotal Cloud Foundry 1.10.