Secure All the Services! How Banks Use Pivotal Cloud Foundry and the Open Service Broker API to Make It Happen.

[Editor’s Note: This is the second in a series of posts describing how banks are modernizing with Pivotal Cloud Foundry. The first post detailed identity management. Here, we review how to secure the services that touch the platform.]

What’s the architecture of choice for high-velocity development teams? Microservices! Naturally, many banks have adopted this pattern.

With microservices, teams can use the right technology for the job. Each microservice operates independently, so you are free to choose the right stack for your scenario. Considering a relational database, NoSQL store, caching, or messaging queue? Go for it. Use what works best!

Now, let’s consider the InfoSec implications of this flexibility. With traditional systems, you'd want uniformity and consistency where possible. Conventional wisdom states that conformity reduces risk. So does this newfound diversity of choice pose a security risk? Nope. In fact, when you use microservices – along with a modern platform – you can actually improve your security posture.

How is this possible?

It’s all thanks to the Open Service Broker API (OSBAPI). This simple, elegant mechanism is used by banks the world over to lock-down services that interact with Pivotal Cloud Foundry (PCF). At the same time, developers are empowered to use their preferred services.

Let’s review common business requirements for add-on services. Then, we’ll dive into why the service broker model works so well for banks.

Common Enterprise Requirements Drove the Creation of the Open Service Broker API

When Pivotal works with a bank, we help its leaders carefully navigate many important decisions. Standardizing on a modern platform is a great choice, but it’s not one to make lightly! Here are a few of the larger requirements banks typically consider:

• Apps and their associated services must be able to move easily across data centers, including from on-prem to the public cloud.

• The platform will run hundreds – and eventually thousands – of apps. That means there’s an incredible diversity of backing services that need to be supported. This includes everything from legacy systems (DB2, Oracle) to popular microservices management tools (Spring Cloud Services, Steeltoe).

• Abstractions should make life easy for the entire IT organization. Physical and network security should “just work.” And ideally, the service integration model would be flexible enough to support many services, even different types of platforms. Wouldn’t it be great to have one mechanism for both Cloud Foundry and Kubernetes?

• Enable sharing of service instances between related apps. Data-centric applications will often need access to the same RabbitMQ stream, for example.

With these requirements in mind, let’s explore the mechanics of service brokers.

An Inside Look at Service Brokers

A service broker is a component that advertises a catalog of service offerings and service plans. It manages the lifecycle of every instance of a service that it is asked to provision, including giving and revoking access to each instance.

A  service offering (or "service") is a software or system that applications depend on for various capabilities, either as an external dependency or platform-level capability provided to the application. Service plans are a useful way to “size” the resources consumed by a given instance type. You’ll often see “T-Shirt” sizes: small, medium, and large. Each plan fits a given scenario.

What a broker does with each call can vary between services. In general, ‘provision’ reserves resources on a service. 'Bind’ delivers information to an application necessary for accessing the resource. We call the reserved resource a service instance. What a service instance represents can vary by service. It could be a single database on a multi-tenant server, a dedicated cluster, or even just an account on a web application.

To create a service instance, the user can provide parameters such as quality of service, size, maximum cost or anything the service broker can use in determining what result to return in response to the request.

Now, we can discuss how the OSBAPI and CredHub deliver ease-of-use and security (respectively) for your backing services.

APIs Rule Everything Around Me

To build a service broker, you must implement the required endpoints as defined in the OSBAPI specification.

The Open Service Broker API is designed to simplify service interactions for developers. It’s an efficient, secure, and elegant way to deliver backing services to applications running within cloud-native platforms. It is a clean abstraction that allows services to expose a catalog of capabilities, as well as the ability to create, use, and delete those services.

An overview of the Open Service Broker API.

Each service broker built to the Open Service Broker API spec has the same intuitive set of lifecycle commands. Developers using cloud-native platforms love this consistency, as they can use the same commands to provision and get access to thousands of different types of backing service!

CredHub: Breakthrough Credential Management for Pivotal Cloud Foundry

With all these service instances, there has to be a way to secure access to them, right? Yes indeed. Meet CredHub, the mechanism for managing credentials in Cloud Foundry.

At the highest level, CredHub centralizes and secures credential generation, storage, lifecycle management, and access. It handles creds for platform components as well as service instances.

Service brokers can store binding credentials as secure service instance credentials in CredHub. Apps can then retrieve these credentials from CredHub. This workflow secures service instance credentials in three ways:

• There are no leaks of environment variables to logs.

• There are no credentials are sent between components.

• Users aren’t required to rotate credentials through the environment.

When PCF binds an app to an instance of a service, the broker retrieves the credentials from CredHub, and delivers them to the Cloud Controller. This enables the app to access the service.

Use CredHub to secure service credentials and protect service instance credentials from leaking through environment variables. This way, only the app and platform administrators can access unencrypted service credentials. And developers never see credentials in plain text.

When your credentials are stored in this way, life gets a little easier for InfoSec teams. Compliance with financial industry regulations is simpler too.

Using Service Brokers

So far, we’ve discussed the importance of the API and CredHub. What about actually using service brokers? Let’s dig into the day-to-day experience. (Check out the excellent documentation if you’d like to learn more.)

Add Approved Services to Your Apps via Self-Service with the Services Marketplace

We know that self-service teams are also high-velocity teams. Pivotal Cloud Foundry adopts the OSBAPI service marketplace idea to give developers self-service access to a collection of approved add-on services. Here’s what a sample services marketplace looks like:

Platform engineers can advertise a catalog of custom service offerings and service plans. Developers can bind them to their apps instantly, via self-service.

What kind of services can show up here? Every conceivable piece of tech an enterprise would want or need. Add dozens of different data and backing services. Spring Cloud Services for microservices management are popular. (Check out the Pivotal Services Marketplace for more details). You can even add your own services to the marketplace. Many customers “unlock” the data from their legacy databases via a custom service broker. Modern apps can then securely interact with this business data in new and exciting ways.

Adding Service Instances to Your Apps

Developer convenience is paramount. With service brokers, service instances are created as quickly as possible with the least amount of effort. It’s just a few simple cli commands. To add a MySQL instance to your app, you simply type:

Here, PLAN is the name of the MySQL for PCF plan you want to use (usually “small”, “medium”, or “large”.) SERVICE-INSTANCE is a name you choose to identify the service instance.

Then, you bind the instance to your app:

APP is the app you want to use the MySQL service instance. (SERVICE-INSTANCE is the name you supplied when you ran cf create-service above.)

These operations are typically done in minutes. Your devs can remain highly productive!

Pricing and Rating: Chargeback/Showback for Services

How do you assign a cost to the services consumed by apps on the platform? Service brokers accomplish this with the aforementioned concept of plans. 

The consumption of service instances (and their associated plans) is tallied by PCF, and included in a few helpful reports. For more on chargeback and showback in PCF, check out this whitepaper.)

Best Practices for Implementing Service Brokers

What else can you learn from how banks use service brokers? Here are a few final considerations.

Configure Egress Rules with ASGs

Application Security Groups (ASGs) are collections of egress rules that specify the protocols, ports, and IP address ranges where app instances send traffic. Most banks prefer to set the default ASG egress policy to DENY. Your service broker can use the Security Group API to manage these egress rules if you’d like to allow connections to your service instances. (NOTE: this only works if you are writing your own service broker, and you're happy to give it admin API credentials.)

Use the PCF Permissions Model with Your Service Plans

Do you only want certain teams to have access to certain services? You’re in luck! Service plans support Cloud Foundry’s permissions model. That means you can publish service plans to specific orgs in your PCF foundation. Of course, you can publish them to all your orgs, too!

Use the Right Deployment Model for Your Scenario

You can choose how service brokers get deployed. Given how many services you’ll be adding to the platform, there’s a good chance you’ll use all four of these models:

1. The entire service packaged and deployed by BOSH alongside PCF. Use this when you need the Day 2 benefits offered by BOSH. (Many tiles authored by Pivotal use this approach.)

2. The service broker is packaged and deployed by BOSH alongside PCF. Meanwhile,  the service is deployed and maintained by other means. This is a good option if your service happens to be in a secured network zone. Only the broker is allowed access to it, and the broker manages credentials on behalf of apps.

3. The service broker (and optionally the service itself) are pushed as an application to a PCF user space. Developers should go this route when they want to securely share a service with other apps in your cf org.

4. The entire service, including the broker, is deployed and maintained outside of PCF by other means. Use this to integrate legacy systems, highly regulated environments, and highly sensitive information.

Build Service Brokers!

The Cloud Foundry and Kubernetes communities have many service brokers for adding backing services to your apps and containers. Use them!

Our experience with banks also tells us that you’re going to build your own service brokers. This is something you should encourage your teams to do. Why? It’s very easy to automate onboarding and offboarding system access for apps. This is an important thing to get right when you have thousands of engineers to look after.

Service brokers help InfoSec teams:

• Control connection points

• Control credentials

• Ensure visibility

• Ensure consistency

And that’s what makes them such a game-changer for enterprise IT.

Want to learn more about service brokers and how they can help your team build better apps? Join us at SpringOne Platform 2018 in Washington, D.C., September 24 to 27. Register now.