Hi all

Currently, the CF ecosystem supports two deployment architectures of Credhub (https://docs.cloudfoundry.org/credhub/#deployment-architecture ):

• Colocated with BOSH, used for the secrets of the BOSH director
• Deployed standalone as its own deployment (“Runtime Credhub”), used for the secrets of service brokers, supported by CF for https://github.com/cloudfoundry-incubator/credhub/blob/master/docs/secure-service-credentials.md to interpolate creds.
  Currently, Diego only supports one credhub endpoint for the Runtime Credhub (which is injected via CloudController in the VCAP_PLATFORM_OPTIONS env var). It does not support multiple Credhubs.

However, we have two use cases that would profit if we could add support for CF/Diego so that it can interpolate credentials also from a different credhub url, which could for example be passed as part of the service binding/VCAP_SERVICES.

• Use case 1: Service brokers running outside of CF:
  Since we use our Service brokers also for other platforms than CF (namely k8s and our IaaS offerings), the service brokers run outside of CF. Thus, they do not use CF’s Runtime Credhub but a dedicated one (since we still want to store the creds securely).
  Thus, CF can’t interpolate the credentials because it can only do this for the Runtime Credhub. If we could pass the SB’s credhub URL as part of the service binding, CF could interpolate the credentials from the 3^rd party SB’s credhub.
• Use case 2: Credhub as a Service: Some customers are asking for a dedicated Credhub instance, since Credhub currently does not offer strong multi-tenancy. So we plan to deploy dedicated Credhubs as a service (pushed as an App to CF).
  CF can also not interpolate the credentials, since it can only do this for the Runtime Credhub – and we could solve that by passing the Credhub URL as part of the service binding, as above.
  We’re aware that Credhub will eventually get stronger multi-tenancy, so Use case 2 might be solved with a shared Credhub (i.e. the Runtime Credhub). However, the need for multiple Credhubs remains with Use case 1.

I already reached out on the #credhub Slack (https://cloudfoundry.slack.com/archives/C3EN0BFC0/p1531942967000203) and on the Diego repo (https://github.com/cloudfoundry/diego-release/issues/401).

However, I was told to reach out on a more generic channel since this is a cross-cutting concern.

What do you think? Is multiple Credhub something that CF could profit in the future? If yes, we’re happy to provide a PR (see implementation suggestions in the Diego issue).

CCed Erich as the PM of Diego.

Best regards

Matthias

Matthias Winzeler

Application Cloud

https://developer.swisscom.com 

^{___________________________________________________________________________}
Mobile  +41 79 664 96 16

matthias.winzeler@...
^{___________________________________________________________________________}
Swisscom (Switzerland) Ltd