There’s a common culprit behind many IT breaches: stale credentials.
A bad actor will often get a hold of usernames, passwords, and other “secrets.” From there, hacking enterprise systems is a relative breeze.
As Pivotal Chief Security Officer Justin Smith points out, credentials are often long-lived, meaning in the event of a credential leak, attackers could have prolonged access to your environment. Even if the credentials aren’t used for an initial point of entry, they could be used to expand what attackers have access to once inside your environment. So how can you reduce the value of credentials? With rapid, frequent rotation.
Clearly, a robust security posture in 2018 needs to include some mitigation of the threat posed by leaked credentials.
Enter CredHub, which generates, stores and manages the lifecycle of credentials in Cloud Foundry. From cradle to grave, CredHub is the centralized solution for all secrets in Cloud Foundry. While CredHub has existed within PCF since v1.11, it continues protect more and more secrets in the platform with each and every release (see Table 1 for a rundown of the most recent feature releases.) We wanted to take a look at the ways Credhub is already helping improve PCF, and even a couple of things to look for in the future.
|
Version |
Feature |
|
CredHub co-located on the BOSH Director VM. |
|
|
Migration of Internal Credentials to CredHub |
|
|
Configure an External CredHub Encryption Provider |
|
|
Runtime CredHub Can Use HSMs |
|
|
Ops Manager Credentials Stored in CredHub |
|
|
Operators can store service credentials in runtime CredHub |
|
|
Beta support for secure credentials in CredHub |
|
|
Spring Cloud Services service broker and worker apps now can use the Runtime CredHub to store service instance credentials |
|
|
Provides secure access to service credentials for services that are not running on Pivotal Application Service |
Table 1: The latest CredHub feature releases for Pivotal Cloud Foundry and related services.
First, operators that are familiar with BOSH manifests may have noticed a very important change with v262: sensitive credentials from the manifest have been replaced with variables. In many cases, operators never see these passwords. Instead, passwords and certificates are generated, encrypted, and stored by CredHub at deployment time. The BOSH Director then communicates with CredHub as needed to provide these credentials to new or existing deployments.
Variables can be parameterized and generated at deployment time
Many service tiles now work with CredHub as well, including MySQL, RabbitMQ and Spring Cloud Services. For tile developers, there’s already great documentation on how you can update your tile to take advantage of all that CredHub has to offer. Once updated, all service bindings will provide their credentials to applications via CredHub. Make sure to keep an eye on future PCF releases to see more and more services integrating with CredHub.
Finally, last month we extended the power and security of CredHub to operators and developers alike with the addition of the CredHub Service Broker. This service broker provides an easy and secure way for apps running on the Pivotal Application Service (PAS) to read credentials from CredHub and offers an alternative to user-provided services. Instead of storing sensitive data in the Cloud Controller database and being made available to applications as plaintext metadata, the CredHub Service Broker stores them in CredHub, only making them available to application containers with authorized access. To ensure the identity is correct, every application container in PAS includes a signed certificate and key, which is used to communicate with CredHub and provide its identity. Be sure to check out two great blogs by our own Colin Jackson on how developers can use CredHub as well as a great look on how CredHub provides credentials to applications.
Creating a new set of credentials in the CredHub Service Broker is as simple as a single command-line call:
cf create-service credhub default my-credhub -c '{"my-cred": "my value"}'When the service is bound to the application, the credentials are made available just as any other set of service credentials in PAS. However, only the application instances bound to the service have access. Any operation from outside of the application simply sees a reference to the credential:
➜ ~ cf env my-app
Getting env variables for app my-app in org dev / space dev as admin...
OK
System-Provided:
{
"VCAP_SERVICES": {
"credhub": [
{
"binding_name": null,
"credentials": {
"credhub-ref": "/credhub-service-broker/credhub/92896866-dec7-4655-ba30-dbb06c8f8709/credentials"
},
"instance_name": "my-credhub",
"label": "credhub",
"name": "my-credhub",
"plan": "default",
[...]
The Road to Credential Rotation
With each release, CredHub continues to expand its reach across PCF, truly embracing security by default. That’s not to say that security doesn’t continue to be something that should be at the front of everyone’s mind, but rather provides the means to improve and adapt to new enterprise security best practices. With the building blocks of the Three R’s, it’s easy to see just how important a solution like CredHub is in helping mitigate modern threats. Make sure to watch for new releases of CredHub, PCF and your favorite services to see the latest CredHub integrations!
Learn about enterprise security at the cloud event of the year: SpringOne Platform, Sept 24-27 in Washington, DC. Register now!
