Date   
Re: cf-deployment 3.0

Jesse T. Alford
 

I don't agree with the claim that we didn't introduce major breaking changes in the past - we did. Routinely.

`cf-release` was sem-ver only insofar as every version was a major version. Changes just as dramatic as this were made on some but not all arbitrary major releases.

The major thing cf-d brings here is real semver, so it's _clear_ that some versions are major changes.

The credo remains the same - forward, always.

Chip's point about long-term support/backported fixes is exactly on-point. It's a major support burden, and is one of the principle pieces of work done by commercial distributors.

Jesse Alford
_Formerly of_ CF Release Integration


On Wed, Jul 18, 2018 at 11:38 AM Chip Childers <cchilders@...> wrote:
Food for thought: One of the challenges here is that maintaining patches for past coordinated releases is expensive (both in time and CI costs). In the CF ecosystem, this has traditionally been the responsibility of the downstream commercial distributions.

This isn't to say that there isn't a solution that can help all downstream users (including non-commercial users AND the distros), yet not burden the Rel Int team too much. I'm not sure what that solution is though...

On Mon, Jul 16, 2018 at 9:47 AM Franks, Geoff <geoff.franks@...> wrote:

I’m going to agree with Marco’s concerns here. Making life harder and less stable for the end users of CF has a real potential to alienate and push away the CF userbase altogether, even if it’s just in appearance (seeing monthly major releases of a product may cause new organizations to hesitate to migrate, until the release process appears more stable.

 

 

From: <cf-dev@...> on behalf of Marco Voelz <marco.voelz@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Monday, July 16, 2018 at 1:34 AM
To: "cf-dev@..." <cf-dev@...>
Subject: [External] Re: [cf-dev] cf-deployment 3.0

 

Dear Josh,

 

Thanks for the context, I wasn't aware of what happened before the release of networking 2.0. To stick with your example, though: From what you are saying I have understood that you would rather have done it this way – please correct me here if I'm wrong:

  • integrate networking release 2.0 into cf-deployment, 
  • integrate other PRs with breaking changes
  • bumping cf-deployment to a new major version, given above changes
  • merging the CVE fixes only into the new major version of cf-deployment

 

With this process, you would have achieved the following:

  • the development teams are happy, because they shipped as soon as they were ready to
  • operators are grumpy, because they have to bump networking to a new major version and adopt to other breaking changes in order to fix CVEs

 

I'm not saying you have to turn this tradeoff the other way around, but in my opinion this doesn't seem very consumer friendly. 

 

In your team's mission, you have clearly stated that your goal is to enable development teams to maintain a high velocity. I'd like to stress that we shouldn't leave the operators and users out of the picture here. In the end, you're developing for them, not for yourself. 

 

I'm not sure if the consumer/operator persona is a thing for RelInt, but if that's the case, here's something I'd like to hold true for whatever change RelInt makes to their process:

"As an operator of CF, I'd like to consume CVE fixes with as little changes to my existing installation as possible, such that I close known vulnerabilities as soon as possible"

 

Does that sound reasonable?

 

Warm regards

Marco


From: cf-dev@... <cf-dev@...> on behalf of Josh Collins <jcollins@...>
Sent: Friday, July 13, 2018 11:39:30 PM
To: cf-dev@...
Subject: Re: [cf-dev] cf-deployment 3.0

 

Hi Marco,

I'm happy to provide more context on the container networking 2.0 reference.
The container networking team submitted a PR to cf-deployment with changes required for them to ship v2.0. 
RelInt deferred the container networking team's PR for a few weeks due to competing priorities including multiple CVE's fixes.
During the deferral time, a few other PRs were submitted which included breaking changes.
These additional changes took much more time to integrate and validate than anticipated and in the end, the container networking team's 2.0 release was published in cf-d about 5 weeks after it was ready to go.
The introduction of a regular cadence aims to mitigate this type of delay in the future. Had we had one at the time, the networking team would have timed it's PR to align and we would have been poised to accept and publish it quickly.
We believe this will help teams confidently plan for, communicate about, and negotiate integrating their releases into cf-deployment.
And hopefully enable the RelInt team to integrate and ship major releases more seamlessly.

This is an evolving process so we'll see how things roll in the coming months and make adjustments where it makes sense to do so. 
I appreciate and welcome any and all feedback along the way.

Thanks very much,

Josh

--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

Re: cf-deployment 3.0

Krannich, Bernd
 

I was about to mention that I indeed enjoyed the existing CF model of releases which roughly translated to “you better run fast” for consumers.

 

The thing I found needed some tweaking in the existing model was the approach to including fixes for prio very high CVEs. Often times, in our quest to run fast and keep systems secure as fast as possible, we ended up pulling in a bunch of features which required additional validation and essentially slowed us down in our effort of rolling things out to production.

 

I felt that the better approach to support people that can keep the speed would have been to always provide fixes for prio very high CVEs as cherry-picks based on the latest released version (and then of course also include those fixes into the next “regular” release, too).

 

Based on the comments so far, it sounds like for consumers “you better run fast” will actually be harder with the newly proposed approach. But maybe I’m not fully understanding the concepts, so it would be great to get some more details on the plans.

 

Regards,

Bernd

 

From: <cf-dev@...> on behalf of Chip Childers <cchilders@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Wednesday, 18. July 2018 at 19:38
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] cf-deployment 3.0

 

Food for thought: One of the challenges here is that maintaining patches for past coordinated releases is expensive (both in time and CI costs). In the CF ecosystem, this has traditionally been the responsibility of the downstream commercial distributions.

 

This isn't to say that there isn't a solution that can help all downstream users (including non-commercial users AND the distros), yet not burden the Rel Int team too much. I'm not sure what that solution is though...

 

On Mon, Jul 16, 2018 at 9:47 AM Franks, Geoff <geoff.franks@...> wrote:

I’m going to agree with Marco’s concerns here. Making life harder and less stable for the end users of CF has a real potential to alienate and push away the CF userbase altogether, even if it’s just in appearance (seeing monthly major releases of a product may cause new organizations to hesitate to migrate, until the release process appears more stable.

 

 

From: <cf-dev@...> on behalf of Marco Voelz <marco.voelz@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Monday, July 16, 2018 at 1:34 AM
To: "cf-dev@..." <cf-dev@...>
Subject: [External] Re: [cf-dev] cf-deployment 3.0

 

Dear Josh,

 

Thanks for the context, I wasn't aware of what happened before the release of networking 2.0. To stick with your example, though: From what you are saying I have understood that you would rather have done it this way – please correct me here if I'm wrong:

  • integrate networking release 2.0 into cf-deployment, 
  • integrate other PRs with breaking changes
  • bumping cf-deployment to a new major version, given above changes
  • merging the CVE fixes only into the new major version of cf-deployment

 

With this process, you would have achieved the following:

  • the development teams are happy, because they shipped as soon as they were ready to
  • operators are grumpy, because they have to bump networking to a new major version and adopt to other breaking changes in order to fix CVEs

 

I'm not saying you have to turn this tradeoff the other way around, but in my opinion this doesn't seem very consumer friendly. 

 

In your team's mission, you have clearly stated that your goal is to enable development teams to maintain a high velocity. I'd like to stress that we shouldn't leave the operators and users out of the picture here. In the end, you're developing for them, not for yourself. 

 

I'm not sure if the consumer/operator persona is a thing for RelInt, but if that's the case, here's something I'd like to hold true for whatever change RelInt makes to their process:

"As an operator of CF, I'd like to consume CVE fixes with as little changes to my existing installation as possible, such that I close known vulnerabilities as soon as possible"

 

Does that sound reasonable?

 

Warm regards

Marco


From: cf-dev@... <cf-dev@...> on behalf of Josh Collins <jcollins@...>
Sent: Friday, July 13, 2018 11:39:30 PM
To: cf-dev@...
Subject: Re: [cf-dev] cf-deployment 3.0

 

Hi Marco,

I'm happy to provide more context on the container networking 2.0 reference.
The container networking team submitted a PR to cf-deployment with changes required for them to ship v2.0. 
RelInt deferred the container networking team's PR for a few weeks due to competing priorities including multiple CVE's fixes.
During the deferral time, a few other PRs were submitted which included breaking changes.
These additional changes took much more time to integrate and validate than anticipated and in the end, the container networking team's 2.0 release was published in cf-d about 5 weeks after it was ready to go.
The introduction of a regular cadence aims to mitigate this type of delay in the future. Had we had one at the time, the networking team would have timed it's PR to align and we would have been poised to accept and publish it quickly.
We believe this will help teams confidently plan for, communicate about, and negotiate integrating their releases into cf-deployment.
And hopefully enable the RelInt team to integrate and ship major releases more seamlessly.

This is an evolving process so we'll see how things roll in the coming months and make adjustments where it makes sense to do so. 
I appreciate and welcome any and all feedback along the way.

Thanks very much,

Josh

--

Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

[High Severity CVE] UAA accepts refresh token as access token on admin endpoints

Dan Jahner
 

CVE-2018-11047: UAA accepts refresh token as access token on admin endpoints


Severity

High

Vendor

Cloud Foundry Foundation

Affected Cloud Foundry Products and Versions

  • You are using uaa versions 4.19 prior to 4.19.2, 4.12 prior to 4.12.4, 4.10 prior to 4.10.2, 4.7 prior to 4.7.6, 4.5 prior to 4.5.7
  • You are using uaa-release versions v60 prior to v60.2, v57 prior to v57.4, v55 prior to v55.2, v52 prior to v52.10, v45 prior to v45.11

Description

Cloud Foundry UAA, versions 4.19 prior to 4.19.2 and 4.12 prior to 4.12.4 and 4.10 prior to 4.10.2 and 4.7 prior to 4.7.6 and 4.5 prior to 4.5.7, incorrectly authorizes requests to admin endpoints by accepting a valid refresh token in lieu of an access token. Refresh tokens by design have a longer expiration time than access tokens, allowing the possessor of a refresh token to authenticate longer than expected. This affects the administrative endpoints of the UAA, e.g. /Users, /Groups, etc. However, if the user has been deleted or had groups removed, or the client was deleted, the refresh token will no longer be valid.

Mitigation

Users of affected versions should apply the following mitigations or upgrades:

  • Releases that have fixed this issue include:
    • uaa versions 4.19.2, 4.12.4, 4.10.2, 4.7.6, 4.5.7
    • uaa-release versions v60.2, v57.4, v55.2, v52.10, v45.11

Re: cf-deployment 3.0

David Sabeti
 

As the previous project lead for RelInt, I want to speak to Marco's concerns directly. We _definitely_ considered the operator as an important persona during any decision-making; if anything, we were overcommitted to that persona, evidenced by the fact that we became at times an obstacle to CFF dev teams out of fear of making a breaking changes for operators.

There's clearly some concern that operators won't be able to keep up with breaking changes. However, one impact of making breaking changes more frequently -- and, even better, on a schedule -- is to reduce the difficulty of adapting to them. To build a bit on what Josh said earlier in his example about cf-networking 2.0, as we pushed off releasing a major version of cf-deployment, more backwards-incompatible updates were stockpiled in the backlog. In the end, cf-deployment 2.0 included **seven** breaking changes instead of merely one or two.

To link this back to Marco's story -- "As an operator of CF, I'd like to consume CVE fixes with as little changes to my existing installation as possible, such that I close known vulnerabilities as soon as possible" -- this is already a problem with cf-deployment. As others have mentioned, there's no back-porting of cf-deployment after major version bumps, so operators already have to accommodate breaking changes in order to get CVE fixes. I understand that the proposal means that this happens more often, but it also means that major version bumps will be more predictable and less risky.[0]

I wasn't sure if it was worth rehashing the days of cf-release or not, but since Jesse broached the subject, I'd give his comments a +1 all around. One of the ways I understood Josh's proposal was as an important course correction. If cf-release was too free-wheeling in making breaking changes, cf-deployment has been too conservative. The proposal for a regular cadence of breaking changes seems like a balance between those two. Similarly, this is a re-balancing with regards to the personas as well: based on experience, the RelInt team has learned that it should be more willing to release breaking changes for operators in order to empower the CFF dev teams.

Sabeti
Also _formerly_ of the RelInt team


[0] Bernd has an interesting point about providing patch updates only to the latest release of cf-deployment, as a way to provide operators with a CVE-fix-only release. Providing such releases is also non-trivial work that I'm not sure the RelInt team would prioritize. Also, RelInt ships minor releases twice per week, so the changesets are typically small. Still, it seems a bit more palatable than any kind of LTS because it assists operators in living up to the "you better run fast."



On Wed, Jul 18, 2018 at 10:59 AM Krannich, Bernd <bernd.krannich@...> wrote:

I was about to mention that I indeed enjoyed the existing CF model of releases which roughly translated to “you better run fast” for consumers.

 

The thing I found needed some tweaking in the existing model was the approach to including fixes for prio very high CVEs. Often times, in our quest to run fast and keep systems secure as fast as possible, we ended up pulling in a bunch of features which required additional validation and essentially slowed us down in our effort of rolling things out to production.

 

I felt that the better approach to support people that can keep the speed would have been to always provide fixes for prio very high CVEs as cherry-picks based on the latest released version (and then of course also include those fixes into the next “regular” release, too).

 

Based on the comments so far, it sounds like for consumers “you better run fast” will actually be harder with the newly proposed approach. But maybe I’m not fully understanding the concepts, so it would be great to get some more details on the plans.

 

Regards,

Bernd

 

From: <cf-dev@...> on behalf of Chip Childers <cchilders@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Wednesday, 18. July 2018 at 19:38
To: "cf-dev@..." <cf-dev@...>


Subject: Re: [cf-dev] cf-deployment 3.0

 

Food for thought: One of the challenges here is that maintaining patches for past coordinated releases is expensive (both in time and CI costs). In the CF ecosystem, this has traditionally been the responsibility of the downstream commercial distributions.

 

This isn't to say that there isn't a solution that can help all downstream users (including non-commercial users AND the distros), yet not burden the Rel Int team too much. I'm not sure what that solution is though...

 

On Mon, Jul 16, 2018 at 9:47 AM Franks, Geoff <geoff.franks@...> wrote:

I’m going to agree with Marco’s concerns here. Making life harder and less stable for the end users of CF has a real potential to alienate and push away the CF userbase altogether, even if it’s just in appearance (seeing monthly major releases of a product may cause new organizations to hesitate to migrate, until the release process appears more stable.

 

 

From: <cf-dev@...> on behalf of Marco Voelz <marco.voelz@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Monday, July 16, 2018 at 1:34 AM
To: "cf-dev@..." <cf-dev@...>
Subject: [External] Re: [cf-dev] cf-deployment 3.0

 

Dear Josh,

 

Thanks for the context, I wasn't aware of what happened before the release of networking 2.0. To stick with your example, though: From what you are saying I have understood that you would rather have done it this way – please correct me here if I'm wrong:

  • integrate networking release 2.0 into cf-deployment, 
  • integrate other PRs with breaking changes
  • bumping cf-deployment to a new major version, given above changes
  • merging the CVE fixes only into the new major version of cf-deployment

 

With this process, you would have achieved the following:

  • the development teams are happy, because they shipped as soon as they were ready to
  • operators are grumpy, because they have to bump networking to a new major version and adopt to other breaking changes in order to fix CVEs

 

I'm not saying you have to turn this tradeoff the other way around, but in my opinion this doesn't seem very consumer friendly. 

 

In your team's mission, you have clearly stated that your goal is to enable development teams to maintain a high velocity. I'd like to stress that we shouldn't leave the operators and users out of the picture here. In the end, you're developing for them, not for yourself. 

 

I'm not sure if the consumer/operator persona is a thing for RelInt, but if that's the case, here's something I'd like to hold true for whatever change RelInt makes to their process:

"As an operator of CF, I'd like to consume CVE fixes with as little changes to my existing installation as possible, such that I close known vulnerabilities as soon as possible"

 

Does that sound reasonable?

 

Warm regards

Marco


From: cf-dev@... <cf-dev@...> on behalf of Josh Collins <jcollins@...>
Sent: Friday, July 13, 2018 11:39:30 PM
To: cf-dev@...
Subject: Re: [cf-dev] cf-deployment 3.0

 

Hi Marco,

I'm happy to provide more context on the container networking 2.0 reference.
The container networking team submitted a PR to cf-deployment with changes required for them to ship v2.0. 
RelInt deferred the container networking team's PR for a few weeks due to competing priorities including multiple CVE's fixes.
During the deferral time, a few other PRs were submitted which included breaking changes.
These additional changes took much more time to integrate and validate than anticipated and in the end, the container networking team's 2.0 release was published in cf-d about 5 weeks after it was ready to go.
The introduction of a regular cadence aims to mitigate this type of delay in the future. Had we had one at the time, the networking team would have timed it's PR to align and we would have been poised to accept and publish it quickly.
We believe this will help teams confidently plan for, communicate about, and negotiate integrating their releases into cf-deployment.
And hopefully enable the RelInt team to integrate and ship major releases more seamlessly.

This is an evolving process so we'll see how things roll in the coming months and make adjustments where it makes sense to do so. 
I appreciate and welcome any and all feedback along the way.

Thanks very much,

Josh

--

Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

Re: cf-deployment 3.0

Jesse T. Alford
 

Another point: most (certainly not all, but most) CVEs are stemcell, buildpack, or rootfs bumps that can be consumed safely/have minimal integration concerns. Even those that are in more substantive releases, such as routing and UAA, can be bumped-ahead fairly easily with a manual edit or an ops file, and are often fairly safe iterations over the releases that came before them, though it can be admittedly hard to tell.

If, somewhere along the spectrum of risk and difficulty I just described, the risk becomes too great for you to feel safe going straight to prod without relint's blessing, I recommend you test them first. If testing these adjustments to your particular environment is too burdensome, well, yes, it does become so, doesn't it?

Maintaining a whole passel of integration environments is a significant engineering and infrastructure burden, but happily it is one you can pay commercial integrators to shoulder for you.


On Wed, Jul 18, 2018 at 2:46 PM David Sabeti <dsabeti@...> wrote:
As the previous project lead for RelInt, I want to speak to Marco's concerns directly. We _definitely_ considered the operator as an important persona during any decision-making; if anything, we were overcommitted to that persona, evidenced by the fact that we became at times an obstacle to CFF dev teams out of fear of making a breaking changes for operators.

There's clearly some concern that operators won't be able to keep up with breaking changes. However, one impact of making breaking changes more frequently -- and, even better, on a schedule -- is to reduce the difficulty of adapting to them. To build a bit on what Josh said earlier in his example about cf-networking 2.0, as we pushed off releasing a major version of cf-deployment, more backwards-incompatible updates were stockpiled in the backlog. In the end, cf-deployment 2.0 included **seven** breaking changes instead of merely one or two.

To link this back to Marco's story -- "As an operator of CF, I'd like to consume CVE fixes with as little changes to my existing installation as possible, such that I close known vulnerabilities as soon as possible" -- this is already a problem with cf-deployment. As others have mentioned, there's no back-porting of cf-deployment after major version bumps, so operators already have to accommodate breaking changes in order to get CVE fixes. I understand that the proposal means that this happens more often, but it also means that major version bumps will be more predictable and less risky.[0]

I wasn't sure if it was worth rehashing the days of cf-release or not, but since Jesse broached the subject, I'd give his comments a +1 all around. One of the ways I understood Josh's proposal was as an important course correction. If cf-release was too free-wheeling in making breaking changes, cf-deployment has been too conservative. The proposal for a regular cadence of breaking changes seems like a balance between those two. Similarly, this is a re-balancing with regards to the personas as well: based on experience, the RelInt team has learned that it should be more willing to release breaking changes for operators in order to empower the CFF dev teams.

Sabeti
Also _formerly_ of the RelInt team


[0] Bernd has an interesting point about providing patch updates only to the latest release of cf-deployment, as a way to provide operators with a CVE-fix-only release. Providing such releases is also non-trivial work that I'm not sure the RelInt team would prioritize. Also, RelInt ships minor releases twice per week, so the changesets are typically small. Still, it seems a bit more palatable than any kind of LTS because it assists operators in living up to the "you better run fast."



On Wed, Jul 18, 2018 at 10:59 AM Krannich, Bernd <bernd.krannich@...> wrote:

I was about to mention that I indeed enjoyed the existing CF model of releases which roughly translated to “you better run fast” for consumers.

 

The thing I found needed some tweaking in the existing model was the approach to including fixes for prio very high CVEs. Often times, in our quest to run fast and keep systems secure as fast as possible, we ended up pulling in a bunch of features which required additional validation and essentially slowed us down in our effort of rolling things out to production.

 

I felt that the better approach to support people that can keep the speed would have been to always provide fixes for prio very high CVEs as cherry-picks based on the latest released version (and then of course also include those fixes into the next “regular” release, too).

 

Based on the comments so far, it sounds like for consumers “you better run fast” will actually be harder with the newly proposed approach. But maybe I’m not fully understanding the concepts, so it would be great to get some more details on the plans.

 

Regards,

Bernd

 

From: <cf-dev@...> on behalf of Chip Childers <cchilders@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Wednesday, 18. July 2018 at 19:38
To: "cf-dev@..." <cf-dev@...>


Subject: Re: [cf-dev] cf-deployment 3.0

 

Food for thought: One of the challenges here is that maintaining patches for past coordinated releases is expensive (both in time and CI costs). In the CF ecosystem, this has traditionally been the responsibility of the downstream commercial distributions.

 

This isn't to say that there isn't a solution that can help all downstream users (including non-commercial users AND the distros), yet not burden the Rel Int team too much. I'm not sure what that solution is though...

 

On Mon, Jul 16, 2018 at 9:47 AM Franks, Geoff <geoff.franks@...> wrote:

I’m going to agree with Marco’s concerns here. Making life harder and less stable for the end users of CF has a real potential to alienate and push away the CF userbase altogether, even if it’s just in appearance (seeing monthly major releases of a product may cause new organizations to hesitate to migrate, until the release process appears more stable.

 

 

From: <cf-dev@...> on behalf of Marco Voelz <marco.voelz@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Monday, July 16, 2018 at 1:34 AM
To: "cf-dev@..." <cf-dev@...>
Subject: [External] Re: [cf-dev] cf-deployment 3.0

 

Dear Josh,

 

Thanks for the context, I wasn't aware of what happened before the release of networking 2.0. To stick with your example, though: From what you are saying I have understood that you would rather have done it this way – please correct me here if I'm wrong:

  • integrate networking release 2.0 into cf-deployment, 
  • integrate other PRs with breaking changes
  • bumping cf-deployment to a new major version, given above changes
  • merging the CVE fixes only into the new major version of cf-deployment

 

With this process, you would have achieved the following:

  • the development teams are happy, because they shipped as soon as they were ready to
  • operators are grumpy, because they have to bump networking to a new major version and adopt to other breaking changes in order to fix CVEs

 

I'm not saying you have to turn this tradeoff the other way around, but in my opinion this doesn't seem very consumer friendly. 

 

In your team's mission, you have clearly stated that your goal is to enable development teams to maintain a high velocity. I'd like to stress that we shouldn't leave the operators and users out of the picture here. In the end, you're developing for them, not for yourself. 

 

I'm not sure if the consumer/operator persona is a thing for RelInt, but if that's the case, here's something I'd like to hold true for whatever change RelInt makes to their process:

"As an operator of CF, I'd like to consume CVE fixes with as little changes to my existing installation as possible, such that I close known vulnerabilities as soon as possible"

 

Does that sound reasonable?

 

Warm regards

Marco


From: cf-dev@... <cf-dev@...> on behalf of Josh Collins <jcollins@...>
Sent: Friday, July 13, 2018 11:39:30 PM
To: cf-dev@...
Subject: Re: [cf-dev] cf-deployment 3.0

 

Hi Marco,

I'm happy to provide more context on the container networking 2.0 reference.
The container networking team submitted a PR to cf-deployment with changes required for them to ship v2.0. 
RelInt deferred the container networking team's PR for a few weeks due to competing priorities including multiple CVE's fixes.
During the deferral time, a few other PRs were submitted which included breaking changes.
These additional changes took much more time to integrate and validate than anticipated and in the end, the container networking team's 2.0 release was published in cf-d about 5 weeks after it was ready to go.
The introduction of a regular cadence aims to mitigate this type of delay in the future. Had we had one at the time, the networking team would have timed it's PR to align and we would have been poised to accept and publish it quickly.
We believe this will help teams confidently plan for, communicate about, and negotiate integrating their releases into cf-deployment.
And hopefully enable the RelInt team to integrate and ship major releases more seamlessly.

This is an evolving process so we'll see how things roll in the coming months and make adjustments where it makes sense to do so. 
I appreciate and welcome any and all feedback along the way.

Thanks very much,

Josh

--

Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

Re: cf-deployment 3.0

Josh Collins
 

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: [CAUTION] Re: [cf-dev] Proposed BOSH logging interface

Jesse T. Alford
 

We haven't done anything beyond proposing the interface and implementing the option to respect permissions.

Since the time of this proposal, BPM has implemented a feature that should allow us to run Blackbox in it, mounting the logs directory as read-only. We haven't tried it yet. Assuming it works, this would also reduce our concerns about running blackbox with read access to the entire file system.

Regarding your other feedback about what should go in the tags or structured data, we've not formally taken any of that on board; development of syslog-release is currently paused. I'd suggest putting these things up as issues on the syslog-release repo;
awareness of those is more likely to be durable enough to remain visible until such time as there's a team on this.


On Wed, Jul 4, 2018 at 4:32 AM Voelz, Marco <marco.voelz@...> wrote:

Dear Jesse,

 

did anything come out of this proposal? Did you end up picking up this track of work?

 

Warm regards

Marco

 

From: <cf-dev@...> on behalf of Marco Voelz <marco.voelz@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Tuesday, 8. May 2018 at 10:08
To: "cf-dev@..." <cf-dev@...>, Dmitriy Kalinin <dkalinin@...>
Subject: [CAUTION] Re: [cf-dev] Proposed BOSH logging interface

 

Dear Jesse,

 

Thanks for putting this proposal out there. We would be happy to see an automated logfile forwarding mechanism. Here's a couple of comments on your initial points:

* Including the filename in the syslog metadata is very useful and something we'd really like to have. Currently it is something we're working around a bit.

* The appname/tag field should probably contain the release's name as well as a prefix. My proposal here is `<deployment name>.<instance group name>.<job name>`. wdyt?

* We haven't made any particular use of the priority field, so losing control over this field wouldn't matter for out use-cases. Severity is usually something that the actual log message needs to contain, as the logger's severity can only be set on its initial creation, afaik.

* Restricting the depth of recursion seems reasonable. So far, I don't think we're using bosh releases which have more than 1 folder below their /var/vcap/sys/log/<job name>/ folder.

 

Concerning the requirements about permissions on the logfiles you'd want to forward: Did you talk to Dmitriy/the BOSH team about this? With stemcell series 3541.x the permissions on the standard folders below /var/vcap were tightened a bit, so just wanted to make sure that your assumptions are in line with the upcoming changes in the stemcells.

 

Warm regards

Marco


From: cf-dev@... <cf-dev@...> on behalf of Jesse T. Alford <jalford@...>
Sent: Tuesday, April 3, 2018 12:55:38 AM
To: cf-dev@...
Subject: [cf-dev] Proposed BOSH logging interface

 

Hello! We're the CF Platform Logging team. We maintain `syslog-release` and have been working to improve and regularize platform logging behavior.

 

This is a proposal intended to establish reasonable expectations about what should be logged and what should be forwarded in bosh-deployed cloud systems.

 

Historically, it has been up to each release to provide for their log forwarding, if any. We intend `syslog-release` to provide a consistent interface useful enough to replace all other provisions for the forwarding of logs from bosh jobs.

 

## Proposed Interface

If log forwarding is enabled, some files in `/var/vcap/sys/log` (and its subdirectories, recursively), will have any line written to them forwarded as the MSG portion of an RFC5424 compliant syslog message. Which files are forwarded is governed first by file extension, and secondarily by file permissions.

 

`syslog-release` attempts to read any file ending in `.log`.

(This allows us to avoid forwarding rotated logs, swapfiles, etc.)

It will forward from such files if either of the following are true:

- it is world-readable

- it is readable to the `vcap` group

 

In particular, this means that logs will not be forwarded from files where:

- user and group are root:root

- user and group are vcap:root or vcap:none

- user and group are vcap:vcap, but it is not group-readable

 

…unless they are world-readable.

 

We think that this interface will allow us to avoid running a log forwarder with elevated permissions, while also allowing jobs to, for instance, write DEBUG or similar logs to a file that is not group-readable, thus improving their security and reducing the load on the logging system while still making them available on the ephemeral disk for debugging purposes.

 

## Questions

There are a couple of things around this interface we're especially interested in feedback on, in addition to the obvious "will this be a problem for you" overall question.

 

We may have to have a proviso that the depth of this is not unlimited. This depends somewhat on what is inexpensive to implement and maintain, and is an area we'd appreciate feedback on. Is three levels deep from `/var/vcap/sys/log` (i.e. `/var/vcap/sys/log/jobname/processname/*`) enough? Would four be?

 

In the old way of doing things, more control over the PRI information and other syslog fields was available to release authors. Logs forwarded from files currently all come out as PRI 14, which translates to Facility: User, Severity: Info. Additionally, the appname/tag field is set to the name of the directory containing the log file. Is this enough/good info? If we were to include the filename, too, would that be useful? Sufficient?

 

## Testing with the Proposed Interface

We have recently implemented a feature to help release authors evaluate the proposed interface. If you set `syslog.respect_file_permissions: true`, blackbox will not be run with elevated capabilities, and you'll be able to see what is and isn't forwarded under the proposed interface.

Unconference at CF Summit Basel 2018

Daniel Jones
 

Hi all,

We're pleased to confirm that there'll be an Unconference at Basel again this year at 6pm on Tuesday 9th October.

We're planning on the same rough schedule as last year, so talks interspersed with open space sessions, topped off by something fun at the end. Oh, plus free food and beer.

Things we need from y'all:
  • Talks! We'd love for you folks to present, ideally for <= 10 minutes.
  • Suggestions! Would you like to do another pub quiz? Do you have any other ideas?
  • Sign-ups! If you're coming, please sign up so we know how much food and drink to order.

If you'd like to give a talk, please reply to me, Sara Lenz and Ivana Scott (CC'd).

Regards,
Daniel 'Deejay' Jones - CTO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than Cloud Foundry specialists

Re: Unconference at CF Summit Basel 2018

Dr Nic Williams
 

Thanks for putting the time into another unconference.

I'm working on a book about the UAA; hopefully its done by the conf. Since the UAA is delightfully invisible to most people, I'd love to do 5-10 mins intro on why its interesting, how to deploy, and how to learn more.

Nic

On Mon, Jul 23, 2018 at 9:36 PM Daniel Jones <daniel.jones@...> wrote:
Hi all,

We're pleased to confirm that there'll be an Unconference at Basel again this year at 6pm on Tuesday 9th October.

We're planning on the same rough schedule as last year, so talks interspersed with open space sessions, topped off by something fun at the end. Oh, plus free food and beer.

Things we need from y'all:
  • Talks! We'd love for you folks to present, ideally for <= 10 minutes.
  • Suggestions! Would you like to do another pub quiz? Do you have any other ideas?
  • Sign-ups! If you're coming, please sign up so we know how much food and drink to order.

If you'd like to give a talk, please reply to me, Sara Lenz and Ivana Scott (CC'd).

Regards,
Daniel 'Deejay' Jones - CTO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than Cloud Foundry specialists



--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic

Variable Substitution in manifest.yml #

kvemula15@...
 

Hi CF Team,
I was exploring on variable substitution in manifest.yml : https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#variable-substitution
I see there is a vars.yml that can be used to specify the values of app manifest.
Now if i have various environments like Dev, stage , prod for say then do i have to create three different vars.yml files for each environment like var-dev.yml, var-stage.yml and var-prod.yml anr read values from there during cf push?
Appreciate your leads and advice on this.
Rgds,
Karthik.

Re: Variable Substitution in manifest.yml #

Josh Long
 

If the CF CLI doesn't support environment variables, It would be really wonderful if the file would consider environment variables. It would be more in line with the 12 factor manifesto, it would discourage people from keeping secrets in `yml` files unencrypted on disk. It would also be easier to use than creating a config file. That way people can source the env variable from features in the CI services like Travis env to encrypt variables, or they could be resolved by looking up the value from something like Hashicorp Vault, all through simple environment variable use. No odd code required to write data to a `.yml` file required. 


On Mon, Jul 23, 2018 at 10:40 AM <kvemula15@...> wrote:
Hi CF Team,
I was exploring on variable substitution in manifest.yml : https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#variable-substitution
I see there is a vars.yml that can be used to specify the values of app manifest.
Now if i have various environments like Dev, stage , prod for say then do i have to create three different vars.yml files for each environment like var-dev.yml, var-stage.yml and var-prod.yml anr read values from there during cf push?
Appreciate your leads and advice on this.
Rgds,
Karthik.

Re: Variable Substitution in manifest.yml #

Dr Nic Williams
 

Yes that sounds right - or if you’re deploying in CI then your CI pipeline would create the vars.yml file for each diff target/stage.

Nic

 


From: 30111352660n behalf of
Sent: Tuesday, July 24, 2018 5:36 am
To: cf-dev@...
Subject: Re: [cf-dev] Variable Substitution in manifest.yml #
 
If the CF CLI doesn't support environment variables, It would be really wonderful if the file would consider environment variables. It would be more in line with the 12 factor manifesto, it would discourage people from keeping secrets in `yml` files unencrypted on disk. It would also be easier to use than creating a config file. That way people can source the env variable from features in the CI services like Travis env to encrypt variables, or they could be resolved by looking up the value from something like Hashicorp Vault, all through simple environment variable use. No odd code required to write data to a `.yml` file required. 

On Mon, Jul 23, 2018 at 10:40 AM <kvemula15@...> wrote:
Hi CF Team,
I was exploring on variable substitution in manifest.yml : https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#variable-substitution
I see there is a vars.yml that can be used to specify the values of app manifest.
Now if i have various environments like Dev, stage , prod for say then do i have to create three different vars.yml files for each environment like var-dev.yml, var-stage.yml and var-prod.yml anr read values from there during cf push?
Appreciate your leads and advice on this.
Rgds,
Karthik.

Feature Narrative - Configure egress policies dynamically

Preethi Varambally
 

Hello,


The CF container networking team has received feedback from users regarding some pain points around using Application Security Groups (ASGs) for defining egress policies. After much research, we have defined a set of short, mid and long term goals to address the issues at hand. 


If you have experience using ASGs and have thoughts on it, please feel free to comment on the doc and perhaps also answer some of the open questions we have at the bottom of the document.



Thank you,

CF Container Networking Team


Re: Variable Substitution in manifest.yml #

kvemula15@...
 

Hi Nic,
Thank you for confirming me.Can you point me to any examples /links on web of how it could be done in CI like in jenkins world for file creation that you were talking of.
Rgds,
Karthik.

Re: Variable Substitution in manifest.yml #

Lingesh Mouleeshwaran
 

Hello Karthi, 

Even we also get rid of all secrets managed in *.yml file and moved all secrets to the vault, and we have the simple jar which embedded into spring/spring boot war. 

For Example, below entry sufficient for any web application in manifest.yml, and we have made it vault orphan token lifetime which having 10 years tenure. 

env:
    JAVA_OPTS:  -Dspring.application.name="<<Vault secret path>>" -Dspring.cloud.vault.token=000-000-00000000-00 


Spring dependency entry :

Below entries required for any web application to embed your vault client jar.

<dependency>
            <groupId>com.config.vault</groupId>
            <artifactId>vault-java</artifactId>
            <version>1.0.0</version>
  </dependency>

<context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>
            classpath*:/spring-vault-conf.xml  //this file will have details about your propertyplaceholder logic 
        </param-value>
    </context-param>

Your vault client can be the child of class PropertyPlaceholderConfigurer and you can override below method to read from the vault and populate to system ENVs

/**
* {@inheritDoc}
* @throws IOException
*/
protected void loadProperties(Properties properties) throws IOException {
        super.loadProperties(properties.putAll(vaultResource.read()));
}

Hope this gives you some context what you're looking, additional even if go via Jenkins/Travis services, still, secrets are exposed to an environment variable, anyone can able to look the secrets via cf env.

Regards
Lingesh M

On Tue, Jul 24, 2018 at 2:29 PM, <kvemula15@...> wrote:
Hi Nic,
Thank you for confirming me.Can you point me to any examples /links on web of how it could be done in CI like in jenkins world for file creation that you were talking of.
Rgds,
Karthik.


Proposal: Improving Security for HTTP Ingress to CFAR Application Containers

Eric Malm
 

Hi, everyone,

Building on the features and technologies the CF Diego and Routing teams have introduced into the CF App Runtime to improve application routing consistency, security, and stability (https://lists.cloudfoundry.org/g/cf-dev/topic/11900235#7744, which we have often called "route integrity"), the Diego team intends to make it possible for platform operators to opt into improving the security of how traffic ingresses into application containers. In particular, operators would be able to opt into ensuring that only CF system components, or even only the gorouter HTTP routers, would be able to connect to application containers from the infrastructure-provided network.

The full proposal document is available at https://docs.google.com/document/d/1DjapCLbdgGBmpuWt2P2PV-qm_vUwI_9IZHae9TbN_Pw/edit, and we welcome your comments and questions on the document or on this mailing list thread.

Some areas on which we would particularly like community feedback:

- This secured configuration would initially be incompatible with CF SSH, and would likely never be compatible with TCP routing, as the Routing team has focused its efforts on replacing both the Gorouter and the TCP routers with Istio-configured gateway Envoy proxies. Would those incompatibilities prohibit you as platform operators from opting into this improved security in environments where you would particularly like to enforce it?

- As part of enforcing this more secure configuration, the Diego cell components no longer map ports on their host VM directly to application ports inside the container. Each app instance currently receives the value of its host-side port in its CF_INSTANCE_PORT environment variable, though, and it is also exposed in the response from CC's app stats endpoint. For a variety of reasons (primarily the general availability of container networking and default app-security-group policies), we expect that these values are no longer useful for applications, and so we would like to deprecate them as part of this work and not to supply them in this optional, more secure configuration. Before we do so, we would like to know whether your applications, libraries, or other CF-related tools currently use this information and, if so, to what end.

Thanks,
Eric Malm, for the CF Diego team

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

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
 

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
 

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