5 Security Myths of Pivotal Cloud Foundry

The use of public and private clouds is now a cornerstone of an enterprise’s ability to innovate and operate with agility in an evolving business landscape. The challenge has been maximizing that ability while minimizing costs, vendor lock-in, and security issues that are inherent to the public cloud at scale.

With the growing adoption of Pivotal Cloud Foundry, countless enterprises have found the solution to those challenges. Still, cloud computing has a number of ongoing security concerns, such as those laid out in the Cloud Security Alliance (CSA) Industry Insights report. Although many of those security concerns persist with those that are unfamiliar with PCF, it’s best to start with some background before debunking five of the platform’s most persistent security myths.

Back to The Beginning

Cloud Foundry was originally created by VMware in 2011, and then became a part of Pivotal Software, whose parent company is Dell Technologies. Its growth and evolution since 2015 has been driven by the Cloud Foundry Foundation with the help of the Linux Foundation.

Considered by many to be the first true open source cloud platform as a service (PaaS), Pivotal Cloud Foundry (PCF) delivers a high-level abstraction of cloud-native application development. Its capabilities range from understanding application dependencies to container building and scaling to wiring up networking and routing.

What organizations and DevOps teams talk about most is its ability to move workloads between any public or private cloud provider based on application need, which makes multi-cloud management simple and agile. PCF-run applications are deployed, scaled, and maintained by the infrastructure management component called BOSH.

The PCF BOSH Command Line Interface (CLI) is the foundation for installing and managing deployments and is the source of PCF’s multi cloud agility. With the growth of containers, Elastic Runtime containerizes the code and automates container integration with other services. Other major features of PCF include:

• Cloud Controller to direct application deployment
• Deployment using Docker Images and Buildpacks
• Automated routing of all incoming traffic to appropriate component
• Instant (vertical or horizontal) application scaling
• Cluster scheduler
• Load balancer and DNS
• “Loggregator” – Logging and metrics aggregation

Half of the Fortune 500 now use PCF to develop software more quickly, use multiple clouds, and seamlessly integrate applications and platforms. Despite that adoption rate, a number of common IT security myths still persists among those still contemplating adoption. However, many of those myths can be debunked with a quick dive into some of the features of PCF.

Common Security Myths That Can Be Debunked

PCF’s security is defined by its “three Rs” approach to security (Repair, Repave, and Refresh), which is baked into the holistic stack as well as the entire support and development ecosystem. Refresh refers to the platform’s ability to refresh the application's environment after application-specific service or environment changes. The platform’s repair and repave approach to security is based on constantly disrupting the ability of malware and persistent threats to have the time they need to learn systems and become active security threats. This approach provides the answers that debunk commons security myths around cloud foundry.

Myth #1. Prioritizing Patch Management in the Cloud is Challenging

The PCF Concourse continuous integration/continuous deployment (CI/CD) tool automates the process of loading, testing, and applying security patches in the OS and application stacks within hours of release. This constant and rapid release schedule gives attackers no time to learn and exploit system vulnerabilities.

Myth #2. Cloud Foundry Has Limited Ability to Block Advanced Persistent Threats

PCF operates on the model of the minimum amount of time that a server can operate before it is repaved. To do this, it uses the Bosh recreate commands, which can rebuild VMs from scratch without downtime across an entire cluster on an automated interval. This establishes a constant state of entropy that makes it extremely hard for attackers to gain a foothold.

Myth #3. Cloud Foundry has Numerous Attack Surfaces Due to the Nature of the Cloud

Cloud Foundry deployments generally run on virtual machines (VMs), but there are only two potential public network access points, which severely limits possible security vulnerabilities. The first is via a load balancer mapped to PCF routers, while the second might include an optional Network Address Translation (NAT) VM and a jumpbox for managing devices in a separate security zone.

Myth #4. Containerization in Cloud Foundry Cannot be Secured

According to the NIST Application Security Container Guide, the primary threat scenarios to containers are through image vulnerability exploitation, container runtime, and running poisoned images. PCF secures containers by running application instances in unprivileged containers by default and hardening containers by limiting functionality and access rights. Application containers only have outbound connections to public addresses as the default, which can be changed by administrators through Application Security Groups configuration.

Myth #5. Access and User Authentication Changes are Difficult to Verify and Leave Vulnerabilities

PCF’s User Account and Authentication (UAA) service issues OAuth 2.0 tokens for client applications that work with user credentials from a login server. Centrally assigned, hierarchical role-based access control (RBAC) can be assigned via application-specific security groups designated by the administrator with granular roles and permissions.

UAA can connect to enterprise user stores using SAML, OpenID Connect, LDAP, or OAuth to pull user identity and user attributes. A self-service UI for administrators enables simple identity provider onboarding. Automated SSO and identity provider provisioning for developers based on chosen permissions for each application and the service takes care of the rest. UAA uses an agile, holistic, and robust token and key verification lifecycle management backend. This ensures highly adaptable and automatically evolving access as well as highly developed authentication security for enterprises.

As PCF continues to gain converts and debunk myths about its functionality and its impact on security, it also continues to evolve with the latest updates, such as Kubernetes-powered container service and the launch of a new serverless effort. As enterprises increase their understanding of how best to implement and use PCF with experienced platform-as-a-service partners, they come one step closer to providing the best fit for every given use case.