Date   
Headless browser support in nodejs-buildpack

Pietsch, Mathias (Allianz Deutschland, externer Mitarbeiter) <EXTERN.PIETSCH_MATHIAS@...>
 

Hello Cloudfoundry-Support team,

 

in our project we have the following issue:

 

we would like to generate a PDF-File with screenshots of our angular-html application. Therefore we need a buildpack with a headless browser support.

 

We already tried to generate screenshots with headless-chrome and phantomjs with the standard nodejs-buildpack. For  the headless-chrome we received an error-message that the shared library libnss3.so is missing. The phantomjs process terminated immediately.

 

Do you have a solution for us to solve our problem? This would be very helpful for finishing our project.

 

Thank in advance and best regards.

 

Mathias Pietsch

 

dienstleistend für Allianz Deutschland AG, Grafische Oberflächen für ROPO

Externer Brückenkopf: Darko Pelikan

 

Erreichbarkeit während des Projekts:

   Telefon:             +49 (0) 711 6 63 - 1537

   E-Mail:                EXTERN.PIETSCH_MATHIAS@...

 

------------------------------------------------------------------

 

Telefon: +49 (0) 711 6 63 - 1537

E-Mail: Mathias.Pietsch@...

 

PASS Consulting Group

Schwalbenrainweg 24

D-63741 Aschaffenburg

 

PASS IT-Consulting Dipl.-Inf. G. Rienecker GmbH & Co. KG, Handelsregister: Amtsgericht Aschaffenburg HRA 2921, Sitz der Gesellschaft: Aschaffenburg, Komplementärin: Rienecker Beteiligungs-GmbH, Handelsregister: Amtsgericht Aschaffenburg HRB 7619, Sitz der Gesellschaft: Aschaffenburg, Geschäftsführer: Dipl. Inf. Gerhard Rienecker

 

Re: cf-acceptance-tests moving to development/master --> PR into develop please :)

Iryna Shustava
 

Hey all,

We just created develop and RC branches in the CATs repository. Please make all pull requests on develop going forward. Thanks!

Sebastian Vidrio & Iryna Shustava
CF Release Integration Team


On Fri, Jul 27, 2018 at 1:14 PM Josh Collins <jcollins@...> wrote:
Hello (again) My Cloud Foundrians,

Some changes are coming soon that are likely to impact you and I wanted to give you a heads up in advance...

RelInt has kicked off a tract of work to improve the acceptance test suite that's run by (hopefully) all component teams before they cut releases for integration to cf-deployment.

Cf-acceptance-tests a.k.a. CATs are going to get a iterative makeover.

CATs changes are likely to be released in fits and starts because of the RelInt team's distributed focus across marshalling PR's from component teams and continual fixing of broken builds as changes come into our pipelines, but please know we are focusing a portion of our attention on CATs because we care.

Making irregular, and possibly dramatic, changes to the CATs suite could have negative impacts for all of us, so before we really get into things we're making some changes:
  1. We're going to move to a develop/master split.
  2. We'll validate changes to CATs in CI (against the latest cf-deployment release).
  3. We'll apply semantic versioning practices to our releases.
We're just about to make the switch over to develop/master so I wanted to give you a heads up so you'll know to submit PR's to the develop branch soon rather than master.

************************************
We'll focus initially on making improvements aimed at:
  1. reducing false negatives (flakes)
  2. increasing the ease and efficiency of failure diagnosis
Subsequent improvement steps will be based on learnings from executing on the above and talking to CATs consumers, like you.
***********************************

I'll send another note when we've officially made the switch to develop. 'Till then, keep submitting PRs to master.

If you have any questions, concerns, or suggestions related to CATs, please don't hesitate to reach out to @jcollins or @relint-team ion the cats-users slack.

We're always interested in what you have to say.

Thanks very much!

Josh Collins
PM - Release Integration
--
Josh Collins
PM - CF R&D Release Integration

Re: Deprecate route-sync from CFCR to CFAR

Guillaume Berche
 

Hi Oleksandr and Shannon,

I wonder what's the current plan for routing to CFCR workloads from CFAR ? Is there a concensus towards the proposed usage of TCP router [1] with an associated CloudFoundryRouteController component, or rather leverage K8S cloud providers ?

Which team would be working on this as I could not yet find related stories in the routing/tcp-routing/kubo pivotal trackers [2][3][4]

Thanks in advance,

Guillaume.


On Mon, Jul 16, 2018 at 12:57 PM, Oleksandr Slynko <oslynko@...> wrote:
Hi Arghya,

You have mentioned in Github that you were able to overcome this issue.

For everyone else, here is the context and a bit more information.

History
In very early CFCR days, we did not support cloud provider and basically could not give access to the applications and API outside of the cluster. We had HA Proxies to give access to workloads and API.  At that point, several early adopters told us that they would like to try exposing routes in more dynamic way a-la CFAR and possibly reuse existing routing layer. The main point was that we would like to provision multiple clusters with ease and without changed to Cloud Config.
As result we created a route-sync. 

What is does
It solves two problems:
- have stable and known URL for the API, so we can use to sign the certificate
- have a way to expose applications

How we solve it now
For API, we suggest people to wire their load balancers directly and then add the URL to the manifest. For example, check how BBL does it https://github.com/cloudfoundry/bosh-bootloader/tree/master/plan-patches/cfcr-gcp

Are we diverging further from CFAR?
Yes, CFCR team is moving further to the "vanilla" Kubernetes. But we expect other team to provide solutions for both worlds. We don't have enough deep knowledge of CFAR components and getting this knowledge will slow us down in improving Kubernetes experience. 

We are ready to help anyone to understand Kubernetes more and provide better experience with both runtimes.

Sincerely,
Oleksandr


Re: cf-deployment 3.0

Marco Voelz
 

Dear Josh, dear David,


Thanks David for sharing your past experiences in the RelInt team. I can sympathize with the stories you shared and understand the motivation for the planned changes better.


Now that cf-deployment 3.0 is there, let me tell you "how it went": It now means you have to switch to bosh-dns to receive security updates.


There is a number of reasons why we didn't introduce bosh-dns yet in our production system:

  • This ~200 lines of .yml just for aliasing DNS names [1], as the story making this obsolete isn't done yet [2]
  • This needs to be replicated e.g. in the ops-file to rename the network [3] which makes it even more terrible to maintain
  • There were open issues [4] that are important for larger-scale deployments. I give you that this is fixed now with dns-release 1.8.0 – but this came after you released cf-deployment 3.0
  • Parts of the above issue try a fix by introducing an experimental flag to get feedback from teams. Given this actually *is* an issue, I'd want to wait what comes out of this.
  • Other teams are still surprised from time to time by bosh-dns behavior and are looking into whether this might have implications they need to deal with [5]

Moreover, I think although everyone knew that bosh-dns was going to be a requirement at some point in time, the fact that this would be 3.0 was poorly communicated (I might have missed a mail there, but I cannot remember this. I would have raised my concerns earlier if that would have been the case).

For our production environment, we now have a few choices, all of them bring me headaches:
  • adopt bosh-dns *right now* although we don't feel good about it, 
  • try to bring back consul for a while (not even sure that's possible) and otherwise follow cf-deployment 3.0
  • backport security fixes only to a cf-deployment 2.x based production env

All of this brings me back to: As someone responsible for a cf-deployment production environment, I find it incredibly difficult having to deal with breaking changes like this on a regular basis to get security fixes. 

Warm regards
Marco




From: cf-dev@... <cf-dev@...> on behalf of Josh Collins <jcollins@...>
Sent: Wednesday, July 18, 2018 11:54:06 PM
To: cf-dev@...
Subject: Re: [cf-dev] cf-deployment 3.0
 

Thanks Geoff, Marco, Chip, Jesse, Bernd, and David for sharing your feedback and thoughts. You’ve expressed valid concerns and provided valuable context that I take to heart. I really appreciate the time and effort required for meaningful dialogue about the impacts of the proposed release cadence.


While the RelInt team's primary goal remains supporting the CF Foundation engineering teams and their ability to validate their commits in CI, your points underscore a tension we’re acutely aware of.


We’re trying to meet the needs of both the CFF Contributor and Operator and the ‘trick’ is to find a sustainable balance between the two. However, on occasions where we must prioritize one over the other we’re going to favor the CFF Contributor.  


I mentioned this earlier, but it’s worth restating that the RelInt team doesn’t have any plans provide LTS support and as Chip and Jesse pointed out that has traditionally been a value-added service provided by commercial vendors.  


In the spirit of iteration, I’d like to propose we proceed with the release cadence I originally outlined and see how it goes.


Again, thank you for providing such valuable feedback.


Cheers,


Josh Collins

_Current_ PM of CF Release Integration

Re: DNS takeover

Guillaume Berche
 


Maybe a hint similar to what DNS providers gave to to DNS zone records owners in the blog you referenced (see image copied below) could be added to CF CLI cf delete-domain confirmation prompt

such as "If you want to use this domain within CF in the future, we recommend that you either keep this domain, or update DNS entry, in order to avoid HTTP requests to be misrouted in the future if someone else creates a domain with the same name. Really delete domain X? "




Guillaume.

On Thu, Jul 26, 2018 at 4:40 PM, <adrian.kurt@...> wrote:

Hi Dan

 

Correct, it's exactly that case I'm talking about. If a DNS record pointing to a public CF cloud is not cleaned up properly an attacker can then take over that domain without any issues.

 

My idea would be to add a feature (which can be enabled on public CF offerings) that would verify the ownership of a domain using a TXT record. Of course you don't need that on private CF installations. There this step would be rather annoying.

 

Kind regards

Adrian

 

From: cf-dev@... [mailto:cf-dev@...dry.org] On Behalf Of Daniel Mikusa
Sent: Donnerstag, 26. Juli 2018 14:55
To: CF Developers Mailing List <cf-dev@...>
Subject: Re: [cf-dev] DNS takeover

 

I'm curious, how do you think this attack could be applied to CF (unless you're sitting on an actual attack, then don't post in here publicly and notify the security team)? 

 

CF isn't performing DNS management.  I can add any domain I want using `cf create-domain` or `cf create-shared-domain` (ex: `cf create-shared-domain google.com`), but unless there are wildcard DNS records, set up externally, for that domain pointing to the LB for my CF installation, I can't do anything with that domain (you technically can use it within CF, but no traffic will route to CF).

 

The only case where I could see this happening is if someone used a public CF provider, like PWS or Bluemix, then stopped using it but didn't clean up their DNS.  At that point, the DNS would be pointing to the public provider, but if the user deleted their account, including the org & custom domain, then the domain would not be in use.  I think (haven't tested) CF would permit some other user to add the domain to their account & deploy apps using that domain.

 

Dan

 

 

On Thu, Jul 26, 2018 at 2:23 AM, <adrian.kurt@...> wrote:

Hi

 

I just stumbled on an article about DNS takeover attacks (https://thehackerblog.com/the-orphaned-internet-taking-over-120k-domains-via-a-dns-vulnerability-in-aws-google-cloud-rackspace-and-digital-ocean/index-2.html).

Are there any plans to add features to CF that would prevent this? E.g. do some txt DNS entry to verify the ownership of a domain on creation of new domains in CF.

 

Kind regards

Adrian

 


Re: cf-d 3.0 impact to your CI

Josh Collins
 

I mentioned I'd call a retro to discuss how things went and what we can do to make the transition to cf-d 4.0 better and wanted to follow up with details.

When: Wednesday August 1st @ 11am PST
Where: Pivotal SF, Andromeda conference room or Zoomhttps://pivotal.zoom.us/my/relint   
Retro Board: https://retros.cfapps.io/retros/cf-rel-int

I look forward to it!

Josh Collins 
PM - Release Integration

Variable susbtitution in manifest.yml in jenkins job #cf

kvemula15@...
 

Hi All,
I'm trying to get some examples to do variable substitution in App manifest.yml files which replaces the manifest inheritance feature (https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#variable-substitution). And how this could be done in a jenkins job. I would appreciate any suggestions  on it.
Regards,
Karthik.

cf-acceptance-tests moving to development/master --> PR into develop please :)

Josh Collins
 

Hello (again) My Cloud Foundrians,

Some changes are coming soon that are likely to impact you and I wanted to give you a heads up in advance...

RelInt has kicked off a tract of work to improve the acceptance test suite that's run by (hopefully) all component teams before they cut releases for integration to cf-deployment.

Cf-acceptance-tests a.k.a. CATs are going to get a iterative makeover.

CATs changes are likely to be released in fits and starts because of the RelInt team's distributed focus across marshalling PR's from component teams and continual fixing of broken builds as changes come into our pipelines, but please know we are focusing a portion of our attention on CATs because we care.

Making irregular, and possibly dramatic, changes to the CATs suite could have negative impacts for all of us, so before we really get into things we're making some changes:
  1. We're going to move to a develop/master split.
  2. We'll validate changes to CATs in CI (against the latest cf-deployment release).
  3. We'll apply semantic versioning practices to our releases.
We're just about to make the switch over to develop/master so I wanted to give you a heads up so you'll know to submit PR's to the develop branch soon rather than master.

************************************
We'll focus initially on making improvements aimed at:
  1. reducing false negatives (flakes)
  2. increasing the ease and efficiency of failure diagnosis
Subsequent improvement steps will be based on learnings from executing on the above and talking to CATs consumers, like you.
***********************************

I'll send another note when we've officially made the switch to develop. 'Till then, keep submitting PRs to master.

If you have any questions, concerns, or suggestions related to CATs, please don't hesitate to reach out to @jcollins or @relint-team ion the cats-users slack.

We're always interested in what you have to say.

Thanks very much!

Josh Collins
PM - Release Integration
--
Josh Collins
PM - CF R&D Release Integration

Re: cf-d 3.0 impact to your CI

Josh Collins
 

Hey Julian,

As you probably know we published cf-deployment 3.0 yesterday and one of the things I'll be doing for future major releases will be to pre-publish information about the contents so folks like you can prepare.

Thanks for your feedback!

Josh (and the rest of the RelInt team)

Windows Server 1709 Stemcells for AWS Available on bosh.io

Kartik Lunkad
 

Hi all,
This is Kartik, PM for the BOSH Windows team that builds and ships Windows stemcells! We are extremely happy to announce that we have published Windows Server 1709 Stemcells for AWS on bosh.io.

This could happen because AWS provided published 1709 AMIs recently that allowed us to build official Windows Server 1709 Stemcells on top of those AMIs. 

Please give it a try and let us know if you have any feedback for us in the #bosh channel on slack! 

Thanks,
---
Kartik Lunkad
Senior Product Manager
Pivotal  :: pivotal.io
email: klunkad@...
mobile: 4129614215

CF-Deployment ALWAYS pulls your latest release from www.bosh.io

Josh Collins
 

Hello Fellow Cloud Foundrians,

You probably already know this but I wanted to send out a quick note on the off chance someone new has joined us.

The Release Integration teams cf-deployment CI pipelines are hooked up to www.bosh.io and will automatically trigger a new build/validation workflow whenever any cf-d component is published to bosh.io. We try to publish cf-deployment releases bi-weekly to get your components out to customers and other cf-deployment developers as soon as possible.

This is wonderful of course.
However, there can be the RARE occasion a component team publishes a new release to bosh.io and then uncovers a significant issue that may not have been caught in acceptance tests due to amount of time or load required for the issue to present itself, or some other condition that's difficult to emulate in dev/testing environments. So it happens sometimes.

In the event that this does happen with a component you're working on (or know about), please take an extra minute to let Release Integration know right away so we can pin our pipelines to the last stable version of your component.

We'd like to publish only the finest and most stable cf-bits for general consumption and thank you for helping us to do just that.

I appreciate that you've read this message!

Cheers,

Josh Collins
PM - Release Integration 
--
Josh Collins
PM - CF R&D Release Integration

Re: cf-d 3.0 impact to your CI

Hjortshoj, Julian <Julian.Hjortshoj@...>
 

We're using the master branch, so we haven't hit this yet, but it sounds like it is coming our way soon.  So...is there a list of breaking changes somewhere that we can refer to in order to prepare ourselves?

Thanks much,
-Julian (and the rest of the persi team)


From: cf-dev@... [cf-dev@...] on behalf of Josh Collins [jcollins@...]
Sent: Thursday, July 26, 2018 8:47 AM
To: cf-dev@...
Subject: [cf-dev] cf-d 3.0 impact to your CI

Hello Folks - 

The cf-deployment 3.0 changes which were checked into our `release-candidate` branch yesterday broke the CI pipelines of several component teams. I wanted to let you know that the @relint-team and I are aware of the impact and are very interested in minimizing such disturbances in the force in the future.

I didn't realize how many teams were consuming the RC branch!!! At any rate, once 3.0 is out the door, I'd like to call a retro discussion and invite any/all folks to discuss how things went and what we can do to make 4.0 moar better. 

Thanks so much, apologies and...Looking forward!

Josh Collins
PM - Release Integration,  Pivotal CF R&D 

cf-d 3.0 impact to your CI

Josh Collins
 

Hello Folks - 

The cf-deployment 3.0 changes which were checked into our `release-candidate` branch yesterday broke the CI pipelines of several component teams. I wanted to let you know that the @relint-team and I are aware of the impact and are very interested in minimizing such disturbances in the force in the future.

I didn't realize how many teams were consuming the RC branch!!! At any rate, once 3.0 is out the door, I'd like to call a retro discussion and invite any/all folks to discuss how things went and what we can do to make 4.0 moar better. 

Thanks so much, apologies and...Looking forward!

Josh Collins
PM - Release Integration,  Pivotal CF R&D 

Re: DNS takeover

adrian.kurt@...
 

Hi Dan

 

Correct, it's exactly that case I'm talking about. If a DNS record pointing to a public CF cloud is not cleaned up properly an attacker can then take over that domain without any issues.

 

My idea would be to add a feature (which can be enabled on public CF offerings) that would verify the ownership of a domain using a TXT record. Of course you don't need that on private CF installations. There this step would be rather annoying.

 

Kind regards

Adrian

 

From: cf-dev@... [mailto:cf-dev@...] On Behalf Of Daniel Mikusa
Sent: Donnerstag, 26. Juli 2018 14:55
To: CF Developers Mailing List <cf-dev@...>
Subject: Re: [cf-dev] DNS takeover

 

I'm curious, how do you think this attack could be applied to CF (unless you're sitting on an actual attack, then don't post in here publicly and notify the security team)? 

 

CF isn't performing DNS management.  I can add any domain I want using `cf create-domain` or `cf create-shared-domain` (ex: `cf create-shared-domain google.com`), but unless there are wildcard DNS records, set up externally, for that domain pointing to the LB for my CF installation, I can't do anything with that domain (you technically can use it within CF, but no traffic will route to CF).

 

The only case where I could see this happening is if someone used a public CF provider, like PWS or Bluemix, then stopped using it but didn't clean up their DNS.  At that point, the DNS would be pointing to the public provider, but if the user deleted their account, including the org & custom domain, then the domain would not be in use.  I think (haven't tested) CF would permit some other user to add the domain to their account & deploy apps using that domain.

 

Dan

 

 

On Thu, Jul 26, 2018 at 2:23 AM, <adrian.kurt@...> wrote:

Hi

 

I just stumbled on an article about DNS takeover attacks (https://thehackerblog.com/the-orphaned-internet-taking-over-120k-domains-via-a-dns-vulnerability-in-aws-google-cloud-rackspace-and-digital-ocean/index-2.html).

Are there any plans to add features to CF that would prevent this? E.g. do some txt DNS entry to verify the ownership of a domain on creation of new domains in CF.

 

Kind regards

Adrian

 

Re: DNS takeover

Daniel Mikusa
 

I'm curious, how do you think this attack could be applied to CF (unless you're sitting on an actual attack, then don't post in here publicly and notify the security team)? 

CF isn't performing DNS management.  I can add any domain I want using `cf create-domain` or `cf create-shared-domain` (ex: `cf create-shared-domain google.com`), but unless there are wildcard DNS records, set up externally, for that domain pointing to the LB for my CF installation, I can't do anything with that domain (you technically can use it within CF, but no traffic will route to CF).

The only case where I could see this happening is if someone used a public CF provider, like PWS or Bluemix, then stopped using it but didn't clean up their DNS.  At that point, the DNS would be pointing to the public provider, but if the user deleted their account, including the org & custom domain, then the domain would not be in use.  I think (haven't tested) CF would permit some other user to add the domain to their account & deploy apps using that domain.

Dan


On Thu, Jul 26, 2018 at 2:23 AM, <adrian.kurt@...> wrote:

Hi

 

I just stumbled on an article about DNS takeover attacks (https://thehackerblog.com/the-orphaned-internet-taking-over-120k-domains-via-a-dns-vulnerability-in-aws-google-cloud-rackspace-and-digital-ocean/index-2.html).

Are there any plans to add features to CF that would prevent this? E.g. do some txt DNS entry to verify the ownership of a domain on creation of new domains in CF.

 

Kind regards

Adrian


DNS takeover

adrian.kurt@...
 

Hi

 

I just stumbled on an article about DNS takeover attacks (https://thehackerblog.com/the-orphaned-internet-taking-over-120k-domains-via-a-dns-vulnerability-in-aws-google-cloud-rackspace-and-digital-ocean/index-2.html).

Are there any plans to add features to CF that would prevent this? E.g. do some txt DNS entry to verify the ownership of a domain on creation of new domains in CF.

 

Kind regards

Adrian

Re: 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: cf-dev@...
Cc: emalm@...
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 <drnicwilliams@...>:
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: cf-dev@...
Cc: emalm@...
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




--
Matthias Winzeler
Mattenenge 8
3011 Bern
mailto: matthias.winzeler@...

Re: 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 <drnicwilliams@...>:

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: cf-dev@...
Cc: emalm@...
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




--
Matthias Winzeler
Mattenenge 8
3011 Bern
mailto: matthias.winzeler@...

Re: 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: cf-dev@...
Cc: emalm@...
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

Re: 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

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