The question now: what action do you take to improve your security posture? What do you do differently to reduce risk? For many Pivotal Cloud Foundry (PCF) customers, the answer is surprisingly simple.

Go faster.

Quickly repair your systems with patches as they become available. Repave your systems from a known good state often. Rapidly rotate credentials. This is cloud-native security.

Speed: The Foundation of Security in Pivotal Cloud Foundry

To wit: Pivotal Cloud Foundry 1.12, now GA. Many new features help security teams go faster (and breathe a little easier). Here’s a look at what’s most relevant to InfoSec teams in the release.

System credentials move to CredHub

We recently announced CredHub in PCF 1.11. Now, several secrets for intra-component communication are hosted in this secure repository. That means operations teams no longer use credentials stored as clear text in manifest files. Instead, secrets are replaced with a credential reference that gets resolved by the platform securely.

But the job’s not done until CredHub stores all PCF secrets. So, we’ve introduced migration tools to help tile authors perform this task.

Eventually, the secrets in CredHub will be rapidly rotated. This will then dramatically reduce the risk posed by leaked passwords.

Automate platform updates at scale with Concourse for PCF

Are you tracking mean-time-to-patch as a KPI? You should. The shorter the metric, the lower your risk.

The hacker's job gets harder and harder as the vulnerability window shrinks. That's why you should apply patches and security updates as fast as possible. The same approach helps you protect against advanced persistent threats (APTs). When you “repave” your platform from a known good state often, APTs are far less likely to do harm. Concourse for PCF helps ops teams do both.

First, we shipped CredHub as part of PCF. Now, we’ve moved credentials to it.

Some Elastic Runtime (ERT) credentials are now stored and managed in CredHub. Browse the full list here. You’ll notice they pertain to databases and intra-component communication. You can use the CredHub cli to manage credentials stored in a CredHub server.

In this release, we have a new tool to help tile authors migrate their secrets into CredHub. Once an author moves credentials to CredHub, they are no longer stored as clear text in the BOSH manifest. Check out the documentation for a complete run-down on how to perform this migration.

Using Ops Manager just to generate manifests? CredHub is now supported for your workflow too.

A perfect example of "if it hurts, do it often". CredHub just made things a lot less painful. Need not sacrifice security for convenience. https://t.co/fBouTXKoKW

Continuous integration (CI) and continuous delivery (CD) are crucial to modern business. These practices help you get custom code into production quickly, often many times a day.

You deploy your underlying platform just as often. And you should use the same tooling and principles. That’s exactly what Concourse for PCF does.

Let’s start with the “repair” and “repave” scenario. Operators can use this tool to automate installations, updates, and cross-deployment tasks. Concourse handles configuration differences across deployments as text. From there, Concourse versions them in source-code repositories.

Most enterprises are building microservices these days. And they are building a lot of them! As a result, apps are interacting with clients and services in complex ways. Apps need an easier way to assert their identity to external, dependent components.

A major security building block for this scenario comes in PCF 1.12. The platform now includes a new instance identity system for microservices. Each application instance now has a unique set of credentials: an X.509 certificate and key pair. Both values rotate every 24 hours. Services can use these creds to make the appropriate authentication and authorization decisions on either end of a communication.

Each certificate contains the IP of the container on the container network. Developers that use Spring Cloud Services and other IP-based discovery methods will want to take a close look at this feature.

Security teams often require mutual authentication between client and app. This means apps need access to TLS certificate metadata from the originating client. From there, apps can proceed to allow clients that provide valid certificates. This can be a challenge when TLS is terminated at multiple hops along the way.

PCF 1.12 offers a solution for this scenario. Now PCF passes metadata from the client certificate (received in a TLS handshake) to the application in a HTTP header. Further, PCF strips this header from client requests for additional security.

The initial install of PCF is at least 30 VMs for a highly available configuration, a hefty footprint to be sure. We often remind folks that PCF is a full-featured platform. It's optimized for enterprise availability, horizontal scalability, and Day 2 operations. Even with this explanation, we heard a common follow-up question.

“Can you make the PCF install smaller?”

Yes we can! A Small Footprint ERT tile will be available in the coming days. It features a lean-and-mean footprint of only four VMs!

PCF is now much more applicable in these scenarios:

Evaluating PCF for the first time. Ready to take the leading cloud-native platform for a spin? Download Small Footprint, and deploy it anywhere you like.

A different team within a PCF adopter wants to try out the product. Hearing good things about PCF from your colleagues? Want to help your co-workers down the hall get better at software? Use Small Footprint!

A few caveats apply. There’s no supported migration path from Small Footprint to the standard ERT tile. You’ll need a blob store for droplets and other components to object storage somewhere. And you’re limited to a maximum of 10 Diego cells for running your apps. Finally, we make no guarantees for Control Plane uptime during Small Footprint upgrades. You can expect your apps to be available while you upgrade, however.

Stay tuned for more details in the coming weeks! [UPDATE October 17: Small footprint is now GA, check out the blog post embedded in the tweet below.]

Steeltoe is how .NET teams build microservices on Pivotal Cloud Foundry. The project has over 95,000 downloads! With Steeltoe 1.1, there’s even more to get excited about:

Hystrix Circuit Breaker. This is a complete .NET port of the popular pattern from NetflixOSS. Use it to help prevent cascading failures when there’s a hiccup with a given microservice. The tool also provides rich metrics & dashboarding to monitor how your microservices are performing in the real world. As a result, your apps can gracefully handle failures while you investigate the issue.

Support for Cloud Foundry’s new Container Networking stack. Eureka now supports direct addressing. It can now connect to dependent microservices by IP address - even when they don’t have public routes.

Support for Config Server, backed by Hashicorp Vault. Spring Cloud Services recently released support for Vault. Now with Steeltoe 1.1, you can use Vault as a config repo for .NET apps as well.

Ready to get trained up on Steeltoe? Check out the hands-on bootcamp at SpringOne Platform in December, registration link below:

Securing enterprise apps with identity management can be hard. Thankfully, standards have emerged to make it easier for developers. Pivotal’s Single Sign-On (SSO) service has embraced SAML, OpenID, and OAuth 2.0 to help engineers ensure transparent authentication and authorization.

SSO 1.5 extends its OpenID Connect (OIDC) support to include AzureAD. Now, developers can enable Azure AD SSO for their apps and APIs using the OIDC authentication layer.

Historically, developers have had to fork supported buildpacks, or use community buildpacks to deploy polyglot apps to PCF. The same was true for apps that use tech from many vendors. This is useful for the developer, but not ideal for InfoSec compliance.

Thanks to multi-buildpack support in PCF 1.12, you don’t need to rely on DIY buildpacks (or docker packaging) as much. The familiar, supported buildpack flow now applies in more scenarios. This helps you go faster.

You’ll start to see PCF Marketplace tiles support this model. Look for buildpacks from the Pivotal ecosystem in the coming months.

Thinking about running Pivotal Cloud Foundry on AWS? We now support more regions, including Canada (ca-central-1), Ohio (us-east-2), and London (eu-west-2). Choose from over 13 different regions for PCF on AWS!

Do you work for the government, or maybe a federal contractor? AWS GovCloud is a popular target. You can now deploy PCF there too. Just search for the Ops Manager AMI ID within GovCloud, and you’re ready to go!

If you’re running PCF on Google Cloud Platform, you’ll appreciate our new support for GCP Shared VPC Networks. This makes it easier to share GCP resources across projects.

Faster Upgrades of Ops Manager Appliance

You can now upgrade Ops Manager much faster than ever before. We’ve slimmed down the installation.zip. Now this file only includes critical upgrade information. (Before, it bundled in the actual releases for ERT and other tiles.)

As a result, the zip file shrinks from over 5 GB down to just a few megabytes. The new file size is much easier (and faster) to work with. NOTE: This feature only exists in PCF 1.12 and above. Make sure you to use BOSH Backup and Restore as part of your upgrade flow.

Container Networking

Network administrators will appreciate several container networking updates. First, container-to-container networking replaces the legacy networking stack in PCF 1.12. (There is no option to disable this feature.) Also, the cf CLI now includes networking commands for policy management. Finally, operators and developers can specify port ranges for their policies, instead of doing it one-by-one.

Global Logging of Application Traffic & App/Space/Org GUIDs

Want a more complete view of traffic within Cloud Foundry? Enable global logging! This option captures logs for accepted packets, and denied packets. Operators can now get more insight into the packets turned away by ASGs and container networking policies.

The HAProxy BOSH release replaces the previous version of HAProxy in the ERT and Isolation Segment tiles.

Partitioned Routing in Elastic Runtime & Isolation Segment Tiles

By default, Isolation Segment routers now reject requests that are not for apps on the same Isolation Segment. You can opt to configure these routers to guide traffic to apps in the "shared" isolation segment of the ERT tile. This option is useful when the ERT routers are only used for the system domain. This way, only trusted networks are permitted management access.

Similarly, ERT routers continue to support routing of all registered routes by default, but can be configured to reject requests for isolation segments. We recommend this only when operators have deployed dedicated routers for every isolation segment.

Apps Manager: A Faster Way to Add & Create Services for Your Apps

Need to add a service to your app? Now, you can do so without leaving the app (or space) view! There’s a new overlay that will show in your browser where you can perform this task, see below. It’s a same workflow you’re accustomed to, just a lot faster. Select, configure, and bind your service - all inside the new overlay workflow!