Rotating OAuth2 client credentials on Pivotal Cloud Foundry.

One of the biggest challenges in regards to information security is passwords and client secrets that never gets rotated, Not true any longer for Pivotal Cloud Foundry.

Attribution: Pivotal Software

I recently talked to a security architect that told me about a project in a large bank he was involved in. He told me that one of the projects they were starting now was to manually rotate the credentials for all the 900 systems the bank was using. This was the first time they would be doing this even though the bank has been around for 30 years. Timeframe for the project? 1 year.

This illustrates everything that is wrong with the way we approach information security in today’s world. Frankly, if it takes 1 year to rotate the credentials for all the systems you have, then you don’t take information security seriously. I am not sure you should be allowed to do internet banking at all.

Pivotal Cloud Foundry recently released v1.10 of their Single-Sign-On service.
One of the advantages of using Pivotal Cloud Foundry is the easy way you can automate the security configuration and deployment of your services. You need to have the SSO tile installed in order to follow the demonstration in this blog post. First download the Identity Sample App for demonstration of the client credentials.

1. Using the CF CLI, login and target the space where you’d like the sample app to reside.

Using the plan created as part of the Prerequisites, create a service instance in your space if you have not done so already

cf create-service p-identity <plan-name> sso-instance

2. Instead of using your manifest.yml to bind to SSO, as outlined in the second step of setting up the sample app, we will be binding our application using an extra bind step when deploying the application. The reason for this is that the environment variables you’re using will only apply for the first push of an application, not the first push after binding. That means once the app exists on the foundation, the env variables are no longer used. so after we have done the first cf push we will do cf bind to bind to SSO. This will allow us to rotate the OAuth2 client credentials after we have pushed the app whenever we want.

Create a bind_sso.json file like this:

{
 “grant_types”: [“client_credentials”],
 “scopes”: [“uaa.resource”, “todo.read”, “todo.write”],
 “authorities”: [“uaa.resource”, “todo.read”, “todo.write”],
 “identity_providers”: [“todo”],
 “resources”: {
   “todo.read”: “Read Objects”,
   “todo.write”: “Write Objects”
 },
 “access_token_lifetime”: 300
}

3. Remove everything from the manifest.yml this is what you should have in the manifest.yml:

---
applications:
 - name: client-credentials-sample
   memory: 1G
   instances: 1
   path: build/libs/client-credentials.jar

4. Follow step 4 in the README of the sample app, but after the sample app has been deployed, do this:

cf bind-service client-credentials-sample sso-instance -c bind_sso.json

The app should now be bound to the sso service with a set of client credentials which it can use to communicate with the resource server application. Set up the resource server to test that it is actually working.

The advantage of this approach is that when you want to rotate your OAuth2 client credentials you can do like this:

cf unbind-service client-credentials-sample sso-instance
cf bind-service client-credentials-sample sso-instance -c bind_sso.json
Use 'cf restage client-credentials-sample' to ensure your env variable changes take effect'

Doing this will ensure that you can automate the rotation of your client credentials. Pivotal Cloud Foundry use Envoy and Istio on the inside to improve it’s routing layer. This means that they also have a programmatic setup of RSA certificates which means you can secure the traffic between services using mTLS. Read more about this here. It makes the manual rotation of mTLS certificates a thing of the past.