Note: lists.cloudfoundry.org will be down for maintenance on Monday, September 26th, starting at 9AM Pacific Time (4PM Monday September 26, 2022 UTC), for approximately one hour.
- Add support for multiple Credhubs to CF/Diego
Re: Add support for multiple Credhubs to CF/Diego
Dr Nic Williams <drnicwilliams@...>
toggle quoted messageShow quoted text
Will we be making credhub indirectly available to developers so they can populate secret variables for use with their manifest?
Currently if a developer wants secrets passed they need to store them locally/local env vars, and pass them via cf push —var or —var-file.
Will we be enabling developers to store secrets (or secrets setup by their organization) that are loaded by Diego like currently exists only for service bindings?
From: 30111273100n behalf of
Sent: Thursday, July 26, 2018 3:39 pm
Subject: Re: [cf-dev] Add support for multiple Credhubs to CF/Diego
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 3rd 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.
Mobile +41 79 664 96 16
Swisscom (Switzerland) Ltd
Join firstname.lastname@example.org to automatically receive all group messages.