[cf-dev] Add support for multiple Credhubs to CF/Diego

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[cf-dev] Add support for multiple Credhubs to CF/Diego

Matthias.Winzeler

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 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.

 

Best regards

Matthias

 

Matthias Winzeler

Application Cloud

https://developer.swisscom.com 

___________________________________________________________________________
Mobile  +41 79 664 96 16

<a href="applewebdata://953E86CB-EFAA-4902-8201-7AAE1BA35F4D/matthias.winzeler@swisscom.com">matthias.winzeler@...
___________________________________________________________________________
Swisscom (Switzerland) Ltd

_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8195) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] Add support for multiple Credhubs to CF/Diego

Matthias.Winzeler

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 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.

 

Best regards

Matthias

 

Matthias Winzeler

Application Cloud

https://developer.swisscom.com 

___________________________________________________________________________
Mobile  +41 79 664 96 16

<a href="applewebdata://953E86CB-EFAA-4902-8201-7AAE1BA35F4D/matthias.winzeler@swisscom.com">matthias.winzeler@...
___________________________________________________________________________
Swisscom (Switzerland) Ltd

_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8175) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] Add support for multiple Credhubs to CF/Diego

Dr Nic Williams
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?

Nic

 

From: 30111273100n behalf of
Sent: Thursday, July 26, 2018 3:39 pm
To: [hidden email]
Cc: [hidden email]
Subject: Re: [cf-dev] Add support for multiple Credhubs to CF/Diego
 

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 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.

 

Best regards

Matthias

 

Matthias Winzeler

Application Cloud

https://developer.swisscom.com 

___________________________________________________________________________
Mobile  +41 79 664 96 16

matthias.winzeler@...
___________________________________________________________________________
Swisscom (Switzerland) Ltd

_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8176) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] Add support for multiple Credhubs to CF/Diego

Matthias Winzeler
Nic,

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?


-Matthias

2018-07-26 7:48 GMT+02:00 Dr Nic Williams <[hidden email]>:
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?

Nic

 

From: 30111273100n behalf of
Sent: Thursday, July 26, 2018 3:39 pm
To: [hidden email]
Cc: [hidden email]
Subject: Re: [cf-dev] Add support for multiple Credhubs to CF/Diego
 

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 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.

 

Best regards

Matthias

 

Matthias Winzeler

Application Cloud

https://developer.swisscom.com 

___________________________________________________________________________
Mobile  +41 79 664 96 16

[hidden email]
___________________________________________________________________________
Swisscom (Switzerland) Ltd




--
Matthias Winzeler
Mattenenge 8
3011 Bern
mailto: [hidden email]
_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8177) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] Add support for multiple Credhubs to CF/Diego

Dr Nic Williams
To confirm: no better/nicer UX implementation will be provided to developers than for them to author bespoke service brokers to inject secrets into credhub and have client apps have to parse them out of VCAP_SERVICE?

 

From: 30501346560n behalf of
Sent: Thursday, July 26, 2018 3:52 pm
To: [hidden email]
Cc: [hidden email]
Subject: Re: [cf-dev] Add support for multiple Credhubs to CF/Diego
 
Nic,

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?


-Matthias

2018-07-26 7:48 GMT+02:00 Dr Nic Williams <[hidden email]>:
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?

Nic

 

From: 30111273100n behalf of
Sent: Thursday, July 26, 2018 3:39 pm
To: [hidden email]
Cc: [hidden email]
Subject: Re: [cf-dev] Add support for multiple Credhubs to CF/Diego
 

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 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.

 

Best regards

Matthias

 

Matthias Winzeler

Application Cloud

https://developer.swisscom.com 

___________________________________________________________________________
Mobile  +41 79 664 96 16

[hidden email]
___________________________________________________________________________
Swisscom (Switzerland) Ltd




--
Matthias Winzeler
Mattenenge 8
3011 Bern
mailto: [hidden email]
_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8178) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_