application_security cloud_foundry cloud_native cloud_native_security microservices network network_security PCF pivotal_cloud_foundry security

Pivotal Cloud Foundry 1.12: A Boost for InfoSec Teams and Cloud-Native Security

Nothing erodes a brand like a security hack.

We’ve all read the recent headlines. Millions of customer records leaked. Billions lost in market cap. Once you lose the public trust, it’s hard to get it back.

It’s been a sobering few weeks for InfoSec teams. Then again, InfoSec is a serious job.

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.

Going faster doesn’t guarantee you’ll stay ahead of bad actors. But it sure beats the alternative.

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.

Pivotal Cloud Foundry 1.12 has plenty of features for developers and operators too. Let’s get right to it!

ERT Creds Stored in CredHub, Plus New Migration Tools for Tile Authors

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.

Concourse for PCF: Because Ops Teams Need CI/CD Too

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.

Platform operators also use this tool to:

  • Create dependable, consistent automated pipelines that span multiple deployments.
  • Achieve consistent installs of multiple Pivotal Cloud Foundry deployments on different infrastructure.
  • Automate of backup, restore, and smoke tests.
  • Automate uptake of latest minor releases, hotfixes, and stemcells.

Concourse for PCF automatically applies new updates and patches to Pivotal Cloud Foundry.

This is how you keep Pivotal Cloud Foundry patched and updated. Run your most important apps with confidence when you use Concourse for PCF!

Ready to learn more? Check out the documentation.

Use mTLS with App Instance Identity Credentials

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.

Use these credentials to enable mutually authenticated TLS for all your app interactions!

Improved mTLS Support Between Clients & Apps

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.

What’s more: using mTLS client certs is transparent to Spring apps. The Java Buildpack conveniently forwards cert metadata in a Spring-friendly way.

Small Footprint Eases PCF Trials & PoCs

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!
  • Sandbox environments for test pipelines. Lower your infrastructure cost for dev & test workloads.

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 1.1: Hystrix Circuit Breaker for .NET Goes GA

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.
  • Spring Boot Actuator for .NET apps: info, health, loggers, trace. Actuator helps developers speed troubleshooting for their production Java apps. Now, with Steeltoe, .NET devs can do the same. View and analyse vital telemetry within Apps Manager for Pivotal Cloud Foundry!
  • 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:

New Tools for Windows Operators in PCF Runtime for Windows

Customers are bring their .NET apps to PCF. Why? The platform delivers a first-class experience for these workloads. PCF supports apps powered by Hosted Web Core and .NET Core. We’ve integrated PCF with the .NET ecosystem too (e.g. Steeltoe, Visual Studio integrations, Azure Service Broker).

In PCF 1.12, we turn to the Windows operator experience. The good news here: Windows Event Logs are now consumable via syslog.

Windows Event Logs help you understand what’s happening with the OS at any given time. Now, operators can access these consolidated, system logs through a syslog endpoint.

Operators will find it much easier to troubleshoot applications with these logs. And there’s no need to use RDP, because the logs are already available via the common BOSH mechanisms.

Other highlights for Windows ops teams:

  • BOSH Windows supports SSH. Use the bosh ssh command to start terminal session on a BOSH-deployed Windows cell. Use Powershell if you prefer!
  • Manage Windows admin password on Windows cells. Apply your corporate password policies to these PCF components. Randomize passwords or select one for each cell.

Use AzureAD with Single Sign-On 1.5 to Simplify Identity Management

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.

We’ve also updated seven integration guides for popular enterprise IdM systems (Active Directory, AzureAD, CA Single Sign-On, GCP OpenID Connect, Okta, PingFederate, PingOne Cloud). It’s never been easier to secure apps and APIs with SSO for PCF!

Want to know more about how SSO works with ODIC? This epic tutorial by Tian Wang shows you how to secure your apps with AzureAD and SSO for PCF.

Multi-Buildpack Support – Use System Buildpacks More Often

Buildpacks make life easier for everyone. When devs use Cloud Foundry's supported buildpacks, InfoSec always knows what’s running on the platform.

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.

Metrics Forwarder: Send Custom Metrics to Your Preferred Tools

Metrics Forwarder for PCF allows apps to emit custom metrics to Loggregator. Other systems can then consume these custom metrics from the Loggregator Firehose.

With the Metrics Forwarder tile, you can do two interesting things.

  • Configure apps to emit custom metrics to Loggregator. Metrics Forwarder provides an HTTP API that accepts these user-defined metrics.
  • Read custom metrics from the Loggregator Firehose. Select a Firehose consumer of your choice, including community and third-party nozzles.

As the second point suggests, you can wire up your chosen logging tool to ingest custom metrics. Splunk, Honeycomb, and InfluxDB are common choices.

And PCF Metrics will soon support custom metrics “out of the box.” More details coming very soon!

Other Highlights

Infrastructure Choice: AWS GovCloud, More AWS Regions, and Deeper Integration with GCP

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.

Also, packet logs now include app/space/org information. This helps operators troubleshoot and audit application traffic more effectively.

Now Part of PCF: the HAProxy BOSH Release

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!

ICYMI – Other Recent PCF Releases

Reduce Risk by Going Faster

Vigilant security teams are always asking themselves the hard questions like:

  • Are my systems at risk due to the patching we are intentionally not doing?
  • Is my organization designed to react to threats, rather than prevent them? What about  my processes and tooling?
  • Are my security vendors only offering incremental improvements?
  • Am I prevented from updating production systems frequently?

If you don’t like your responses to this self-assessment, it’s time for a new approach.

Read the documentation below. Find ways to bring cloud-native security practices to your organization. The future of your company may very well depend on it!

Advance your cloud-native security skills at SpringOnePlatform. Register before October 22, use the promo code  S1P200_JRuckle, and save $400!

Related Articles