Discuss: Credential expiry policies

[JohannesRudolph]

We sometimes encounter use cases where it's demanded that credentials created by service bindings carry an explicit expiry policy. For example, a credential created for a database must be rotated at least every 180 days. A similar issue exists around service keys (though they are Cloud Foundry specific and mostly unnecessary in my experience when cf ssh tunnels are available).

I see this has not been discussed before within the context of the OSB API spec and want to check in with the community to see if there's a wider demand/recognition of this topic?

There are multiple ways to attack this i.e. the responsibility matrix [expiry policy configuration, expiry enforcement] * [service broker, platform] but I think it makes sense to gather a few other interested parties first before discussing this in detail.

[mattmcneeney]

Hey @JohannesRudolph
You're right that this has been discussed before in this group! From what I remember, the last time we chatted about this we came to the following conclusions:

• Service brokers using credential stores (like CredHub) don't really need any support from the spec. here, as those credential stores can take care of rotating things (although in CF, additional tooling needs to be built to restart apps using those credentials)
• Credential rotation can be performed by unbinding a service instance and then creating a new binding to it, since each binding should contain unique credentials (platform-side automation could be built to handle this)

Typically, the credential rotation policy would be set by a service operator / admin, rather than the service provider, and therefore I'm not sure how we could add this into the service broker side of OSBAPI. Happy to hear ideas on this though!

[JohannesRudolph]

hey @mattmcneeney, great to hear that. We were exactly thinking about going the second route. We also feel this is much more a platform side of thing (the platform is the source of truth after all) and it has much better ways to control rotation and e.g. notify users about it etc. I do also agree that re-creating bindings is the best way to go.

I think a potential touch-point with OSBAPI would be for brokers to be able to define sort of a desired credential rotation policy in their catalog (usually on a per service level). The marketplace may or may not decide to stick to that. For now, we're thinking about solving this by storing an expiry policy at a per-broker level in our platform.

Do you think that "binding expiry" would have a place in the catalog API? It could also be part of an informal metadata convention (like pricing info currently is).

[mattmcneeney]

Thanks for the info! This sounds like something that could go in the Catalog Extensions section of the profile.md doc. This could be a CF-specific thing, but I'm interested if any of the Kuberenetes/service-catalog folks have heard of a similar requirement? @duglin @pmorie etc (feel free to tag others)

Are there any service authors out there who have wanted to be able to define recommended credential rotation policies for their service offerings?