cloud native pivotal_cloud_foundry security

Pivotal Cloud Foundry and Cloud-Native Security

The word "Heartbleed” still brings back memories of lost sleep and productivity. WannaCry caused an enormous impact simply by exploiting a vulnerability in the Windows SMB Server that had a patch issued a month earlier. And without even naming names, you probably have a certain attack in mind that impacted 143 million US citizens, leaking their names, social security numbers, birth dates, addresses and driver's license numbers.

The Day 2 story for Cloud Foundry has always been an important one. It's a huge reason that BOSH exists. While new features are always wonderful, what's often overlooked is security. Not just defensive but also offensive, proactive steps and procedures that can be implemented to tighten up your security.

Awhile back, Justin Smith did a presentation at Summit on cloud-native security that really stuck with me and I loved how it applied to the changing model of cloud-native development and operations. It made me reflect on how security has changed just in the recent years. In his presentation, Justin presents the "Three R's" of cloud-native security: Rotate, Repair, Repave.

With PCF 1.12's recent release and its focus on security, I thought it might be good to take a look at where Pivotal is at on delivering on these points today as well as plans to continue improving on them in the future.

 

Repair

Patch early, patch often.

For all of their offerings, Pivotal puts out a report of every known vulnerability, the affected components as well as proper mitigation. This includes products such as Spring or Cloud Foundry, or even for a dependency such as the underlying OS of a stemcell. These patches are quickly implemented, tested and published by a dedicated team.

Ease of upgrades and patching isn't limit to just BOSH operators, however. Those using Ops Manager, the in-browser UI to manage PCF and service installations, can easily import and upgrade all of their deployments. Operators are notified when new versions of the products are made available and can be downloaded and installed straight from the main Ops Manager page.

updates.png

Taking it a step further, those that are Concourse users can even configure a pipeline to automatically pull updates and roll them through their various environments, testing it with their applications along the way. If you're unfamiliar with Concourse, it's a pluggable CI/CD solution built on the concept of pipelines. Taking a collection of jobs (tasks to perform as steps to the pipeline, such as build or test an application) and resources (inputs into and outputs from jobs, such as pulling from a git repo, uploading to an s3 bucket or deploying to Cloud Foundry), a pipeline can be constructed to define a process. Below, for example, is a pipeline to deploy PCF, responsible for building the infrastructure in GCP and then configuring and deploying both Ops Manager and PCF.

embed.png

These pipelines are being invested in at Pivotal and constantly improved upon. Even if you're managing a CF deployment with BOSH today, a pipeline can be put together to deploy every time a new release or stemcell is made available on bosh.io, using the bosh-io-release-resource and bosh-io-stemcell-resource respectively.

This only addresses the platform and underlying OS, though. Vulnerabilities within dependencies and runtimes can be just as dangerous, but luckily this is where buildpacks in Cloud Foundry come in. Since the buildpack brings the frameworks, dependencies, and runtimes, these can all be patched with the latest updates, brought into your environment to be tested and audited, then used to restage your application.

 

Repave

What better way to make a hostile environment for long-running persistent threats than to blow the whole thing away and rebuild it from a verified source. The ability to rebuild a VM from scratch (either on purpose or as a recovery mechanism for something like an IaaS failure) was an early feature of BOSH. As BOSH was created to deploy and manage complex distributed systems, so long as your deployment is built to be highly available, this is also a no-downtime operation. This is even an option in OpsMan, where operators can choose to recreate all VMs every time a deployment is performed. From here, a simple Concourse pipeline could even be constructed to run this and rebuild the whole environment on a regular schedule.