Hi folks,

Everything should be in working order now. Check out the link now (https://www.cloudfoundry.org/foundryblog/security-advisory/feed/). Note that you may need to click Shift + Reload to properly refresh the page.

Thanks again for flagging. This is a valuable resource for our community so we want to make sure it's in working order!

Thanks,

Caitlyn

On Mon, Jul 8, 2019 at 11:29 AM Caitlyn O'Connell via Lists.Cloudfoundry.Org <coconnell=cloudfoundry.org@...> wrote:

Hey folks,

Apologies for the delay on this -- I was on vacation. I'm consulting with our web team now to find out what happened to the RSS feed. Thanks for alerting us to this issue! Stay tuned for an update.

Many thanks,

Caitlyn

On Mon, Jul 8, 2019 at 4:30 AM Guillaume Berche <bercheg@...> wrote:

I was also relying on the CFF rss feed, and observed it is now returning an empty stream.

Copying the CFF content team and Dan Janhner from CFF security team in case this email thread got unnoticed and a recent wordpress update/config change broke the CSS feed.

Thanks in advance to them for their help,

Guillaume.

On Tue, Jul 2, 2019 at 9:05 AM Lee Porte via Lists.Cloudfoundry.Org <lee.porte=digital.cabinet-office.gov.uk@...> wrote:

I've seen them on there too, but that's a bit more awkward to put automated monitoring in for.

On Tue, 2 Jul 2019 at 07:28, Dr Nic Williams <drnicwilliams@...> wrote:

Someone else may have a more comprehensive answer, but I’ve seen the CVEs announced on the #security channel on CF slack.

Nic

 

---

From: cf-dev@... on behalf of Lee Porte via Lists.Cloudfoundry.Org <lee.porte=digital.cabinet-office.gov.uk@...>
Sent: Monday, July 1, 2019 10:50 pm
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Security feed not updating

 

Hi,

Has anyone else noticed that https://www.cloudfoundry.org/foundryblog/security-advisory/feed/ is not being updated with new security issues? 

Has it moved? I've not spotted anything via the blog site to indicate either way. We use automated monitoring of this feed to alert us of potential CVEs we need to look at specifically on the platform.

Thanks

Lee

--

Lee Porte

Reliability Engineer 

GOV.UK PaaS Team

07785 449292

--

Lee Porte

Reliability Engineer 

GOV.UK PaaS Team

07785 449292

--

Caitlyn O'Connell

Senior Marketing Manager

Cloud Foundry Foundation

@caitlyncaleah

Pronouns: She/Her

Time Zone: Eastern Time

Register for Cloud Foundry EU Summit! September 11-12 in the Hague, Netherlands.

--

Caitlyn O'Connell

Senior Marketing Manager

Cloud Foundry Foundation

@caitlyncaleah

Pronouns: She/Her

Time Zone: Eastern Time

Register for Cloud Foundry EU Summit! September 11-12 in the Hague, Netherlands.

I was also relying on the CFF rss feed, and observed it is now returning an empty stream.

Copying the CFF content team and Dan Janhner from CFF security team in case this email thread got unnoticed and a recent wordpress update/config change broke the CSS feed.

Thanks in advance to them for their help,

Guillaume.

On Tue, Jul 2, 2019 at 9:05 AM Lee Porte via Lists.Cloudfoundry.Org <lee.porte=digital.cabinet-office.gov.uk@...> wrote:

I've seen them on there too, but that's a bit more awkward to put automated monitoring in for.

On Tue, 2 Jul 2019 at 07:28, Dr Nic Williams <drnicwilliams@...> wrote:

Someone else may have a more comprehensive answer, but I’ve seen the CVEs announced on the #security channel on CF slack.

Nic

 

---

From: cf-dev@... on behalf of Lee Porte via Lists.Cloudfoundry.Org <lee.porte=digital.cabinet-office.gov.uk@...>
Sent: Monday, July 1, 2019 10:50 pm
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Security feed not updating

 

Hi,

Has anyone else noticed that https://www.cloudfoundry.org/foundryblog/security-advisory/feed/ is not being updated with new security issues? 

Has it moved? I've not spotted anything via the blog site to indicate either way. We use automated monitoring of this feed to alert us of potential CVEs we need to look at specifically on the platform.

Thanks

Lee

--

Lee Porte

Reliability Engineer 

GOV.UK PaaS Team

07785 449292

--

Lee Porte

Reliability Engineer 

GOV.UK PaaS Team

07785 449292

Someone else may have a more comprehensive answer, but I’ve seen the CVEs announced on the #security channel on CF slack.

Nic

 

---

From: cf-dev@... on behalf of Lee Porte via Lists.Cloudfoundry.Org <lee.porte=digital.cabinet-office.gov.uk@...>
Sent: Monday, July 1, 2019 10:50 pm
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Security feed not updating

 

Hi,

Has anyone else noticed that https://www.cloudfoundry.org/foundryblog/security-advisory/feed/ is not being updated with new security issues? 

Has it moved? I've not spotted anything via the blog site to indicate either way. We use automated monitoring of this feed to alert us of potential CVEs we need to look at specifically on the platform.

Thanks

Lee

--

Lee Porte

Reliability Engineer 

GOV.UK PaaS Team

07785 449292

Awesome, thanks!

Are the scaling issues intrinsic to Istio, or is it CF's use of Istio that's causing the scaling problem?

I'm just curious as to whether we can use this information to infer that no-one is using Istio beyond this scale, or perhaps they are, but they're using it differently.

Regards,

Daniel 'Deejay' Jones - CTO

+44 (0)79 8000 9153

@DanielJonesEB

EngineerBetter Ltd - More than cloud platform specialists

On Thu, 27 Jun 2019 at 03:27, Shannon Coen <scoen@...> wrote:

Thanks to Dan from Engineer Better for prompting this update. We (the CF-Networking team) haven't reached out in a while. 

Last October we shared that with our integration between and CF and Istio Pilot, we were able to offer weighted routing via a new Envoy-base ingress gateway and Cloud Controller APIs or a CLI plugin, enabling developers to have more control in shifting traffic from one version of their application to another. That thread is here: https://lists.cloudfoundry.org/g/cf-dev/message/8328

Since then we've been working on extending our integrations to the application-to-application data plane. Our target milestones are enabling developers to rely on the platform for client-side load balancing, timeouts, retries, and mTLS between applications over the C2C overlay network. These features will remove additional toil from developers for having to implement these behaviors, increasing productivity, and give platform operators and security teams confidence that intra-application traffic is secured in a consistent way.

We already support routing of traffic from apps to internal routes through the sidecars and have default policies set for load balancing, timeouts and retries. But this only works at a relatively low scale; 300 total internal routes. Scaling past this will likely require enhancing our integration with Istio to uniquely configure the sidecars for each application based on c2c security policies. 

We've successful spiked out having the consumer and provider sidecars negotiate mTLS, but we've set that down while we work on the scaling problem above. On this topic we want some feedback from the community on a rollout strategy. Look for a follow up email coming soon.

All this work has been happening in istio-release (https://github.com/cloudfoundry/istio-release), which you can deploy with BOSH alongside cf-deployment using an ops file. Documentation can be found on the README. Warning: our integration with Istio is not yet ready for production use cases. In addition to scaling concerns, the control plane is not yet HA nor is it sufficiently instrumented for monitoring. 

In parallel with the Networking team's efforts, other CF teams are doing great work toward the same vision:

• A collaboration between CAPI and CLI teams, responsible for completing the v3 CC API and delivering the v7 CLI, have been working on the APIs and CLI commands to support declarative configuration of routing rules, starting with percentage-based traffic splitting for external routes. 
• One engineer from the Windows team has been laboring to contribute Windows support to the Envoy Proxy OSS project, which will enable developers of .NET apps to achieve all the same outcomes planned for Linux apps, plus any outcomes delivered with service mesh in the future. Once the sidecars are in place, the operating system is abstracted. 

We'd love help with all of this. If you'd like to contribute please reply here or reach out to us in #networking.

At CF Summit in Philadelphia earlier this year, I gave a presentation at User Day sharing our journey from routing to service mesh in CF, with the ever present goal of delivering business outcomes for platform operators and the development teams they serve. I've attached the slides. I plan to attend CF Summit EU in The Hague in September, and SpringOne Platform in Austin October; reach out if you'd like to meet up. 

Best,

Shannon Coen

Product Lead, PCF Networking

Pivotal, Inc.

Thanks to Dan from Engineer Better for prompting this update. We (the CF-Networking team) haven't reached out in a while. 

Last October we shared that with our integration between and CF and Istio Pilot, we were able to offer weighted routing via a new Envoy-base ingress gateway and Cloud Controller APIs or a CLI plugin, enabling developers to have more control in shifting traffic from one version of their application to another. That thread is here: https://lists.cloudfoundry.org/g/cf-dev/message/8328

Since then we've been working on extending our integrations to the application-to-application data plane. Our target milestones are enabling developers to rely on the platform for client-side load balancing, timeouts, retries, and mTLS between applications over the C2C overlay network. These features will remove additional toil from developers for having to implement these behaviors, increasing productivity, and give platform operators and security teams confidence that intra-application traffic is secured in a consistent way.

We already support routing of traffic from apps to internal routes through the sidecars and have default policies set for load balancing, timeouts and retries. But this only works at a relatively low scale; 300 total internal routes. Scaling past this will likely require enhancing our integration with Istio to uniquely configure the sidecars for each application based on c2c security policies. 

We've successful spiked out having the consumer and provider sidecars negotiate mTLS, but we've set that down while we work on the scaling problem above. On this topic we want some feedback from the community on a rollout strategy. Look for a follow up email coming soon.

All this work has been happening in istio-release (https://github.com/cloudfoundry/istio-release), which you can deploy with BOSH alongside cf-deployment using an ops file. Documentation can be found on the README. Warning: our integration with Istio is not yet ready for production use cases. In addition to scaling concerns, the control plane is not yet HA nor is it sufficiently instrumented for monitoring. 

In parallel with the Networking team's efforts, other CF teams are doing great work toward the same vision:

• A collaboration between CAPI and CLI teams, responsible for completing the v3 CC API and delivering the v7 CLI, have been working on the APIs and CLI commands to support declarative configuration of routing rules, starting with percentage-based traffic splitting for external routes. 
• One engineer from the Windows team has been laboring to contribute Windows support to the Envoy Proxy OSS project, which will enable developers of .NET apps to achieve all the same outcomes planned for Linux apps, plus any outcomes delivered with service mesh in the future. Once the sidecars are in place, the operating system is abstracted. 

We'd love help with all of this. If you'd like to contribute please reply here or reach out to us in #networking.

At CF Summit in Philadelphia earlier this year, I gave a presentation at User Day sharing our journey from routing to service mesh in CF, with the ever present goal of delivering business outcomes for platform operators and the development teams they serve. I've attached the slides. I plan to attend CF Summit EU in The Hague in September, and SpringOne Platform in Austin October; reach out if you'd like to meet up. 

Best,

Shannon Coen

Product Lead, PCF Networking

Pivotal, Inc.

Hi Abby,

It seems that the notification URL [1] mentionned into your email isn't accessible to the OSS community. Can you please share its content if its different from the cf-dev@ announcement?

Thanks in advance,

Guillaume.

[1] https://groups.google.com/a/pivotal.io/d/topic/cf-v3-acceleration/0tfRuNtDetA/discussion 

On Fri, May 31, 2019 at 2:20 AM Abby Chau <achau@...> wrote:

Hello everyone,

Hope this finds you well. 

Following on the CC V2 API Deprecation Plan notification recently, the cf CLI team are writing to also announce the planned deprecation of the v6 cf CLI. Please provide feedback and review the v6 CF CLI Deprecation Plan for details on strategy and timeframes. 

We hope to make the upgrade process as seamless as possible for our users, and that the v7 cf CLI will provide greater opportunities to grow and enhance the product for our users.

As always, we value your feedback and would appreciate comments in the document. We also hang out on Cloud Foundry Slack at #cli. We hope to hear from you. 

Many thanks,

Abby Chau and the CF CLI team

Hello everyone,

Hope this finds you well. 

Following on the CC V2 API Deprecation Plan notification recently, the cf CLI team are writing to also announce the planned deprecation of the v6 cf CLI. Please provide feedback and review the v6 CF CLI Deprecation Plan for details on strategy and timeframes. 

We hope to make the upgrade process as seamless as possible for our users, and that the v7 cf CLI will provide greater opportunities to grow and enhance the product for our users.

As always, we value your feedback and would appreciate comments in the document. We also hang out on Cloud Foundry Slack at #cli. We hope to hear from you. 

Many thanks,

Abby Chau and the CF CLI team