Date   

Routing Release 0.204.0

Amelia Downs
 

Hi cf-dev, 


Routing Release version 0.204.0 is now available for your consuming pleasure!


Release Highlights
  • Feature: Change gorouter default branch from “master” to “main”. Fixes gorouter issue #269.
  • Feature: Change gorouter “master” branch to be called “release”. Fixes routing-release issue #171.
  • Feature: Improve performance for TCP Router. Now it does not reload the HAProxy unnecessarily.
  • Feature: Improve websocket error handling.


Regards,

CF for VMs Networking Team (we, know, it's a mouthful)



Cloud Foundry for Kubernetes (cf-for-k8s) 0.5.0 release is available

Saikiran Yerram
 

Hello CF friends,

We, the cf-for-k8s RelInt team, are excited to announce the availability of cf-for-k8s 0.5.0 release. The most notable feature is the support for the external database. The feature will allow Platform engineers to use cf-for-k8s with an external Postgres database service. The cf-for-k8s team is thankful for the contribution from SAP and is looking forward to future contributions of similar impactful features.

Thank you from cf-for-k8s RelInt team,


Re: Deploying UAA for external users #uaa #cf

Shetty, Viraj S [CTR]
 

Thanks Jonathan. I will take a look at that.  


Re: Office Hours: CF on K8s Networking

Shannon Coen
 

We're ending the call early today on account of low (no) attendance. We'll host again in two weeks!

The CFF calendar can be found at https://www.cloudfoundry.org/community-calendar/.


Best,

Shannon Coen (He/Him)
Manager, Product Management
scoen@...
875 Howard Street 5th Floor, San Francisco CA 94103
Mobile: +1.415.640.0272



From: cf-dev@... <cf-dev@...> on behalf of Dieu Cao via lists.cloudfoundry.org <dieuc=vmware.com@...>
Sent: Tuesday, July 14, 2020 2:23 PM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Office Hours: CF on K8s Networking
 
Awesome! Very excited that there'll be this new forum where folks can get engaged.

-Dieu

From: cf-dev@... <cf-dev@...> on behalf of Shannon Coen via lists.cloudfoundry.org <scoen=vmware.com@...>
Sent: Tuesday, July 14, 2020 12:37 PM
To: cf-dev@... <cf-dev@...>
Subject: [cf-dev] Office Hours: CF on K8s Networking
 
Hello CFF friends,

The CF on K8s Networking team will be hosting OSS office hours bi-weekly beginning next Wednesday, July 22. We've added the event to the CFF community calendar: https://www.cloudfoundry.org/community-calendar/.

We're working toward delivering all the same outcomes within the problem domains of traffic management and security achieved in CF for VMs, for all data paths (ingress, egress, and app-to-app), plus those that have been long requested and not yet realized. We welcome your questions, comments, collaboration, and contribution!

Best,

Shannon Coen (He/Him)
Manager, Product Management
scoen@...
875 Howard Street 5th Floor, San Francisco CA 94103
Mobile: +1.415.640.0272



Re: Deploying UAA for external users #uaa #cf

Jonathan Matthews <contact+cfdev@...>
 

On Tue, 21 Jul 2020 at 14:07, Shetty, Viraj S [CTR] via lists.cloudfoundry.org <vshetty=fdic.gov@...> wrote:
Thanks Enrique. We are deploying UAA in cloud.gov for our agency and it will be used by applications deployed in cloud.gov for our agency. I can add a nginx proxy in front but I think I should be able to filter IP addresses with spring or in the web.xml

Just in case this is useful to you, I suggest taking a look at the CF (hence probably also cloud.gov) feature called “Route Services”. 

Using this platform feature would allow you to deploy a vanilla UAA and decouple it (as an app) from its layer 4 / layer 7 protection.

Nginx can be used as a WAF in that topology, as can Haproxy or anything else reverse-proxy-ish. 

Personally, I’d chose that over relying on a block-/allow-list feature in the UAA itself, where you’d be dependent both on the feature’s presence and its correctness with no regressions over time. 

My 2¢ :-)

Jonathan
--
Jonathan Matthews
https://jpluscplusm.com


Re: Deploying UAA for external users #uaa #cf

Shetty, Viraj S [CTR]
 

Thanks Enrique. We are deploying UAA in cloud.gov for our agency and it will be used by applications deployed in cloud.gov for our agency. I can add a nginx proxy in front but I think I should be able to filter IP addresses with spring or in the web.xml. I can also probably check all the URLs used for a authentication_code or client_credentials flow using chrome and then whitelist only those. However, I am trying to see if this list is documented anywhere that I can simply use it. 

Thanks,
Viraj 


Re: Deploying UAA for external users #uaa #cf

Enrique Cano
 

I would expect you place a well hardened reverse proxy in front of your UAA, and that is what you use to control what is exposed to the outside world and what is not?

Regards

Enrique


Deploying UAA for external users #uaa #cf

Shetty, Viraj S [CTR]
 

We want to deploy UAA for external users of the organization. This UAA deployment would only be used by external users and so some of the URLs would have to be exposed to the internet. But I want a large part of the UAA api urls like /identityzones, /groups, /users etc to not be exposed to the internet (this is for extra security). The only URLs that really need to be exposed are the ones which is useful for the OAuth 2 flows for external users. I can use the IP filtering mechanism to remove access to these URLs. Can I do this in the uaa.yml file and if so - is there a known set of URLs which are normally exposed in these conditions? I would rather whitelist a set of URLs. Any help is appreciated. 


A new major cf-acceptance tests (CATS) release v6.0.0 is available

Saikiran Yerram
 

Hello CF friends,

The new major release v6.0.0 of Cloud Foundry acceptance tests (CATS) now works with cf CLI v7. As you may be aware, the cf CLI team recently release the much-awaited v7 CLI that unlocks new app developer workflows for users who require granular control of their apps and other advanced deployment strategies. You can check out more @ https://docs.cloudfoundry.org/cf-cli/v7.html.

With this release, CATS will NO longer support running with cf CLI v6 and going forward it will only support running with cf CLI v7. If you're running CATS in your pipelines, we recommend you update your cf CLI to v7 or pin to an older version of CATS < v6.0.0.

It would have not been possible without the hard work of folks on the cf CLI team, V3 Acceleration Team, and Release Integration to come together and make this happen. 

-- Sai



Re: Isolation Segments

Daniel Jones
 

Assuming that the inputs are the same (same app code, same buildpack) then I would have thought that it's the environment that's different?

It might be worth asking on Garden channel in Cloud Foundry Slack - those folks are generally very helpful, and know a lot about the containerisation implementation that is used in the staging process.

Regards,
Daniel 'Deejay' Jones - CEO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists


On Thu, 16 Jul 2020 at 21:05, ross.kovelman via lists.cloudfoundry.org <ross.kovelman=merck.com@...> wrote:
Not that I can see, although we also do frequent "repaves" and we also somewhat recently did an upgrade to a newer version.  I'd like to think if it was a Diego cell it would have been destroyed and or rebuilt at one of those junctures?


Re: Isolation Segments

ross.kovelman@...
 

Not that I can see, although we also do frequent "repaves" and we also somewhat recently did an upgrade to a newer version.  I'd like to think if it was a Diego cell it would have been destroyed and or rebuilt at one of those junctures?


Re: Isolation Segments

Daniel Jones
 

Hmm, is there an unhealthy Diego cell in that isolation segment?

Regards,
Daniel 'Deejay' Jones - CEO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists


On Thu, 16 Jul 2020 at 18:52, ross.kovelman via lists.cloudfoundry.org <ross.kovelman=merck.com@...> wrote:
Sorry about that, this would be the log

[STG/0] [OUT] [31;1m**ERROR** [0m Could not validate nginx.conf: Error copying nginx.conf: write  /tmp/conf879997043/public/privacy/cross-border-privacy-policy/js/jquery-ui.js: cannot allocate memory
 [STG/0] [ERR] Failed to compile droplet: Failed to run all supply scripts: exit status 14
 [STG/0] [OUT] Exit status 223

Cannot allocate memory, is a bit vague I guess you can say.
 


Re: Isolation Segments

ross.kovelman@...
 

Sorry about that, this would be the log

[STG/0] [OUT] **ERROR** Could not validate nginx.conf: Error copying nginx.conf: write  /tmp/conf879997043/public/privacy/cross-border-privacy-policy/js/jquery-ui.js: cannot allocate memory
 [STG/0] [ERR] Failed to compile droplet: Failed to run all supply scripts: exit status 14
 [STG/0] [OUT] Exit status 223

Cannot allocate memory, is a bit vague I guess you can say.
 


Re: Isolation Segments

Jonathan Matthews <contact+cfdev@...>
 

Hey Ross,

Given the number of moving parts involved, it’d be really useful to know precisely what you mean by “droplet stage”. 

A redacted cf push output and cf logs --recent would probably be handy, too :-)

J

On Thu, 16 Jul 2020 at 15:07, ross.kovelman via lists.cloudfoundry.org <ross.kovelman=merck.com@...> wrote:
Curious, has anyone seen a buildpack with a manifest file work in one segment, but that same app and manifest file not work in an isolation segment?  What happens is you run cf push app name, the app fails at the droplet stage, although you can still manually start the app. Do note that the underlying resources are identical, diego cells, and the buildpack is NGINX.  Adding more memory to the manifest does solve the issue, 1GB to 2 GB, but curious why more memory would be needed between two different segments.  Nothing here stands out https://docs.cloudfoundry.org/adminguide/isolation-segment-index.html. other than networking.  I am in discussions with Pivotal but wanted to see if anyone here had issues like this elsewhere?  It's just a weird problem to say the least.
--
Jonathan Matthews
https://jpluscplusm.com


Isolation Segments

ross.kovelman@...
 

Curious, has anyone seen a buildpack with a manifest file work in one segment, but that same app and manifest file not work in an isolation segment?  What happens is you run cf push app name, the app fails at the droplet stage, although you can still manually start the app. Do note that the underlying resources are identical, diego cells, and the buildpack is NGINX.  Adding more memory to the manifest does solve the issue, 1GB to 2 GB, but curious why more memory would be needed between two different segments.  Nothing here stands out https://docs.cloudfoundry.org/adminguide/isolation-segment-index.html. other than networking.  I am in discussions with Pivotal but wanted to see if anyone here had issues like this elsewhere?  It's just a weird problem to say the least.


cf-deployment minor release v13.7.0 contains vulnerability fix CVE-2020-15586

Saikiran Yerram
 

Notice

routing-release.0.203.0 release includes a fix to a security vulnerability. We recommend you upgrade your deployments immediately.

Security: Fix for CVE-2020-15586 Bump golang to version 1.14.5 with a fix in the net/http/httputil package for an issue that could cause the Gorouter to crash if a malicious client sends specially crafted HTTP requests.


If you have any questions, please reach out to us in #release-integration slack channel.



Routing-release 0.203.0 is now available

Kauana dos Santos <kdossantos@...>
 

Release Highlights

This release includes a fix to a security vulnerability. We recommend all deployments upgrade to this release asap.

  • Security: Fix for CVE-2020-15586(link). Bumps golang to version 1.14.5 with a fix in the net/http/httputil package for an issue which could cause the Gorouter to crash if a malicious client sends specially crafted HTTP requests.


Re: Office Hours: CF on K8s Networking

Dieu Cao
 

Awesome! Very excited that there'll be this new forum where folks can get engaged.

-Dieu


From: cf-dev@... <cf-dev@...> on behalf of Shannon Coen via lists.cloudfoundry.org <scoen=vmware.com@...>
Sent: Tuesday, July 14, 2020 12:37 PM
To: cf-dev@... <cf-dev@...>
Subject: [cf-dev] Office Hours: CF on K8s Networking
 
Hello CFF friends,

The CF on K8s Networking team will be hosting OSS office hours bi-weekly beginning next Wednesday, July 22. We've added the event to the CFF community calendar: https://www.cloudfoundry.org/community-calendar/.

We're working toward delivering all the same outcomes within the problem domains of traffic management and security achieved in CF for VMs, for all data paths (ingress, egress, and app-to-app), plus those that have been long requested and not yet realized. We welcome your questions, comments, collaboration, and contribution!

Best,

Shannon Coen (He/Him)
Manager, Product Management
scoen@...
875 Howard Street 5th Floor, San Francisco CA 94103
Mobile: +1.415.640.0272



Office Hours: CF on K8s Networking

Shannon Coen
 

Hello CFF friends,

The CF on K8s Networking team will be hosting OSS office hours bi-weekly beginning next Wednesday, July 22. We've added the event to the CFF community calendar: https://www.cloudfoundry.org/community-calendar/.

We're working toward delivering all the same outcomes within the problem domains of traffic management and security achieved in CF for VMs, for all data paths (ingress, egress, and app-to-app), plus those that have been long requested and not yet realized. We welcome your questions, comments, collaboration, and contribution!

Best,

Shannon Coen (He/Him)
Manager, Product Management
scoen@...
875 Howard Street 5th Floor, San Francisco CA 94103
Mobile: +1.415.640.0272



Re: CATS Migration to support CF CLI V7

Eric Promislow
 

Hello,

The PR is at https://github.com/cloudfoundry/cf-acceptance-tests/pull/423

If anyone has any concerns (or comments) on the PR, we'd appreciate if you could add them by EOD Thursday July 16.
We hope to merge it and get a new V7-based release cut by the end of the week.

Cheers,
Eric Promislow and Dave Walter, Release Integration Team

281 - 300 of 9388