|
Re: Security feed not updating
Thanks Caitlyn for the fix! This is much appreciated. Best regards, Guillaume.
On Tue, Jul 9, 2019 at 9:10 AM Lee Porte via Lists.Cloudfoundry.Org <lee.porte=digital.cabinet-office.gov.uk@...> wrote:
|
|
|
|
Re: Security feed not updating
Lee Porte
Hi Caitlyn, I can confirm that all is working at this end. Thanks for resolving Lee
On Mon, 8 Jul 2019 at 19:24, Caitlyn O'Connell <coconnell@...> wrote:
--
|
|
|
|
Using X.509 certificates as a mechanism for OAuth client authentication
#uaa
brian.sung@...
I do not think UAA currently supports the draft-ietf-oauth-mtls-04 to use a TLS client certificate instead of using client-id/client-secret to authenticate the OAuth client.
Is this or something similar on UAA's future roadmap?
|
|
|
|
Re: Security feed not updating
Caitlyn O'Connell <coconnell@...>
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:
--
Caitlyn O'Connell Senior Marketing Manager Pronouns: She/Her Time Zone: Eastern Time Register for Cloud Foundry EU Summit! September 11-12 in the Hague, Netherlands.
|
|
|
|
Re: Security feed not updating
Caitlyn O'Connell <coconnell@...>
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:
--
Caitlyn O'Connell Senior Marketing Manager Pronouns: She/Her Time Zone: Eastern Time Register for Cloud Foundry EU Summit! September 11-12 in the Hague, Netherlands.
|
|
|
|
Re: Security feed not updating
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:
|
|
|
|
Discontinuation of the Bits-Service
Peter Goetz <peter.gtz@...>
Hello CF community, The Bits-Service team has decided to discontinue the development of the Bits-Service. The reasons for this are many-fold, but can be summarized by a major push towards container standards like Kubernetes in recent years. With this, we are seeing a shift from packages and buildpacks producing droplets, to new Cloud Native Buildpacks producing OCI images. The CF Buildpacks team is actively investigating options for integrating Cloud Native Buildpacks into Cloud Foundry to provide a next-generation build experience. We hope to have more information available about this shortly. Furthermore, there is currently no plan to implement direct communication between Bits-Service and the cf CLI. Without this direct communication, there is not much benefit in having the Bits-Service. What do you need to do?
Eirini OCI Image Registry The Bits-Service currently still serves as an OCI image registry for Eirini, and for that reason, we will provide some basic maintenance support until Eirini has also migrated away from Bits-Service. For the time being, we’re happy to merge PRs and make releases where it is necessary to support Eirini. If there is anyone in the community with an interest to continue active development of the Bits-Service, we’ll be happy to transfer ownership. Thank you, Peter Goetz, Bits-Service PM Elliott Shanks, CF Buildpacks PM
|
|
|
|
Re: Security feed not updating
Lee Porte
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:
--
|
|
|
|
Re: Security feed not updating
Dr Nic Williams <drnicwilliams@...>
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
|
|
|
|
Security feed not updating
Lee Porte
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
|
|
|
|
Re: Update from cf-networking
Shannon Coen
Hi Dan, The scaling issues are primarily related to CF's use of Istio. Currently every Envoy sidecar in the platform receives configuration for all internal routes, regardless of whether there are C2C policies in place that enable apps to connect to one another directly via the overlay network. The sidecars memory utilization increases with the config it holds in memory, and this resource is constrained by a quota for the application container. With default configuration for container memory quota, at around 300 total internal routes all sidecars run out of memory and crash. We can be smarter about the configuration each sidecar receives. We are exploring options, including configuring the sidecars for a given app with routing configuration only for destinations for which a C2C security policy has been created. This would shift the scaling limit to 300 policies per app, which seems more than enough. Looking further forward, as we explore networking investments in K8s as the orchestrator for CFAR (Eirini), we could explore leveraging pods to give the sidecar and apps independent resource limits. Best, Shannon Coen Product Lead, PCF Networking Pivotal, Inc.
On Thu, Jun 27, 2019 at 8:50 AM Daniel Jones <daniel.jones@...> wrote:
|
|
|
|
Re: Update from cf-networking
Daniel Jones
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 EngineerBetter Ltd - More than cloud platform specialists
On Thu, 27 Jun 2019 at 03:27, Shannon Coen <scoen@...> wrote:
|
|
|
|
Update from cf-networking
Shannon Coen
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:
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.
|
|
|
|
REQUEST for REVIEW - Scope for CF-Deployment v10.0
Saikiran Yerram
Good day everyone, I want to share and gather feedback on the proposed scope of the next major release of cf-deployment v10.0 version. Anyone with the link above can review and comment. Please take some time to peruse it and comment directly within the doc when you have a moment. You can reach us at CloudFoundry slack channels #cf-deployment, #release-integration Regards, Saikiran Yerram
|
|
|
|
[Proposal] CAPI V3 Service Offerings
Niki Maslarski
Hello everyone, The SAPI Team has been working on a model for the Cloud Controller V3 API for services. You can view the proposal here https://docs.google.com/document/d/1bDsEiZRwQJNUI41cQlUaioY7JA1fnv_AThOI2ekPXNM/edit?usp=sharing We are seeking feedback over the next week from the community to help us finalize this proposal and move forward with implementation. Looking forward to your comments! You can contact us by replying to this email, via mail to cf-services-api@... or in our cloud foundry slack channel #sapi Best regards Niki && George On Behalf of the SAPI Team
|
|
|
|
Re: Announcement: Planned Deprecation of the v6 cf CLI
Abby Chau
Hi Guillaume, Thanks for reaching out. Sorry the url is inaccessible - it was meant to point at an email entitled " [cf-dev] Announcement: CC API v2 Deprecation Plan" sent in February 2019 by Greg Cobb and the V3 Acceleration Team. Please let me know if you have any additional questions. Thanks. Best, Abby
On Fri, Jun 21, 2019 at 12:46 PM Guillaume Berche <bercheg@...> wrote:
|
|
|
|
Re: Announcement: Planned Deprecation of the v6 cf CLI
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.
On Fri, May 31, 2019 at 2:20 AM Abby Chau <achau@...> wrote:
|
|
|
|
Removing Consul support from capi-release
Tim Downey
Hello everyone! As you're likely aware, in 2017 Cloud Foundry began moving away from using Consul for distributed locks and service discovery. Additionally, last year's release of cf-deployment 5.0.0 removed it as a default component of CF completely. We have begun the process of removing Consul support from some of the jobs in capi-release, starting with the cc-uploader. This means that as of the next capi-release (1.83.0), staging will no longer work in deployments that are relying on Consul for discovery. If you're using cf-deployment (BOSH DNS) or some other mechanism for service discovery this should not cause any issues. Best, Tim Downey, Connor Braa, and the CAPI Team
|
|
|
|
CAPI V3 Deployment states
Scott Sisil
Hi All, The CAPI team has been gathering feedback on how we communicate state of a rolling deployment through the V3 deployments resource. After getting feedback from integrating client teams, we have generated a new proposal that defines a new approach to communicating a more robust status for deployment state. You can view the proposal here - https://docs.google.com/document/d/10VClD8M1yEptkrlKiQzQ_r3DT-JW9Et9xHCFaQdwKpA/edit#heading=h.lwy9q5bvgh48 We are seeking feedback over the next week from the community to help us finalize this proposal and move forward with implementation in the coming weeks. Looking forward to your comments! Thanks, Scott Sisil CAPI PM
|
|
|
|
Re: #java #springboot
#java
#springboot
Warren, Paul <Paul.Warren@...>
You should take a look at CloudFoundry's
Volume Service feature. This feature allows you to bind NFS, or SMB volumes into your application containers.
You may also want to take a look at
Spring Content. A project that allows you to quickly and easily create headless Content Services (with Spring Boot if you would like) for managing unstructured data such as; images, documents and movies, in any of a number of different types of storage
including the filesystem (that you would use with the Volume Service feature).
You can reach out to the Volume Service team on slack #cf-persistence
HTH
_Paul
|
|
|