Need to Secure Credentials for Off-Platform Services in PCF? Try the CredHub Service Broker, Now in Beta! We Take an Inside Look.

Pivotal Cloud Foundry manages some of the most critical workloads from the world's largest companies and organizations. Many of those workloads rely on a broad range of services, both on and off platform. Platform engineers secure these interactions with the Open Service Broker API (OSBAPI).

Now, we’ve taken the power of the OSBAPI, and applied it for use with CredHub, Cloud Foundry’s credential management system. The result: the CredHub Service Broker, now in beta!

Customers trust PCF to run their most sensitive workloads, where the privacy of service credentials must be maintained even from the team managing that particular app. To meet this need, service brokers integrate with CredHub to provide those credentials in an obscured way, so that they can never be viewed from outside the platform. The latest versions of Spring Cloud Services, RabbitMQ, and MySQLv2 all take advantage of this feature. And more are integrating with every release.

But how about credentials you manage off-platform today? Operators use the custom user-provided services (CUPS) feature for this use case. The CredHub Service Broker is a security-conscious alternative to consider. Here’s why.

Use the CredHub Service Broker, and Gain Additional Security Protections

The CredHub Service Broker is a lightweight service broker deployed as a tile. It enables an experience almost identical to CUPS — with one very important difference. All credentials created with this service broker are stored securely within PAS's CredHub cluster. The only actors allowed to read those credentials are the applications they're intended for, and the CredHub Service Broker itself.

That means that credentials you create with the CredHub service broker can take advantage of the enterprise-grade encryption that CredHub brings to the platform. Need your external credentials to be encrypted at rest with a Luna HSM or AWS CloudHSM Classic? No problem! Use the CredHub Service Broker instead of CUPS. Just configure Runtime CredHub with HSM integration in the PAS tile config.

How It Works

Another benefit of this integration? Credentials created with the service broker are not presented outside the system. To demonstrate, let's do a little experiment.

First, we'll create a credential service using custom user-provided services:

Now, after uploading the tile to OpsManager and deploying, let's create a credential service with the CredHub service broker:

To help illustrate what's going on here, I will push an application that tells us what the value of VCAP_SERVICES is in its own environment. It simply reads the contents of VCAP_SERVICES, and returns them in response to an HTTP request.

Great. Now, let's bind our two services to blabbermouth:

Now let's check what blabbermouth sees:

As expected, the app is getting credentials from both the CredHub Service Broker and CUPS. Now, let’s take a look at what the platform knows:

Success! We can see that CAPI doesn't know anything about the credentials created with the service broker. In fact, that credhub-ref in application metadata stays exactly like that until we're in the application's container, just before your app is launched. Similarly, in Apps Manager:

And there you have it. We’ve successfully demonstrated that the CredHub Service Broker keeps the platform in the dark about credentials and their values, as intended.

NOTE: While the CredHub Service Broker ensures credentials are only granted to your app, we don't control what an app chooses to do with them. Please take care to avoid common pitfalls like logging environment variables or including environment details in an app health endpoint.

By now, you may have a few questions about the CredHub service broker. Here are a few common inquiries we’ve received from PCF customers so far:

Q: What do I have to change in my application code to migrate from CUPS to the CredHub Service Broker?

A: Nothing! A process in your app's container will automatically fetch credentials out of CredHub. It uses an identity specific to each container, and puts the actual values in the process environment of your server just before it starts. So while the credentials cannot be fetched from outside the container, from your app's perspective, the credentials are in the "VCAP_SERVICES" environment variable, where they've always been.

Q: Can I use the service broker in production?

A: The CredHub Service Broker relies on the CredHub cluster deployed alongside PAS versions 2.0 or later. (We call this “Runtime CredHub.”) We are confident that Runtime CredHub is secure in all scenarios. But while CredHub is highly available in environments without bad actors, it may not be HA in a hostile, multitenant environment. You can always trust CredHub to keep your credentials secure first and foremost. But if you do not trust your workloads to avoid DDoSing CredHub, then you should wait until we've implemented a few more rogue API user controls before using the service broker in production.

Q: How do I get started?

A: First, confirm your scenario is a good fit. If you need to encrypt your off-platform credentials at rest with an HSM, need to comply with rules governing who is able to view credentials in plaintext, or simply want to adhere to the Principle of Least Privilege, the CredHub Service Broker is for you. Download it from PivNet, read the docs, and try it out! We plan to GA the broker soon, so please reach out to your account team with your questions and feedback!