Re: Proposal: Improving Security for HTTP Ingress to CFAR Application Containers
Mike Youngstrom
Oh man, after re-reading your email it now makes sense. To be honest I didn't actually read the document you provided since it wasn't open for read to everyone so I just assumed what was in there instead. Sorry. Typically in our environments we use network firewalls to force that ingress into the network zones holding CF instances only happen through Enterprise load balancers and only then to specific components, e.g. gorouter, ssh-proxy, tcp router, etc., and use security groups to stop apps talking directly to other containers. Though I imagine in the future we may deploy to environments with less strict network firewall setups. In such an environment this configuration option would be very useful and we probably would use it without TCP routing support if we had such a situation. But we don't currently. Thanks for helping me through this email. :) Mike
|
||
|
||
Re: Proposal: Improving Security for HTTP Ingress to CFAR Application Containers
Eric Malm <emalm@...>
Great, thanks for letting me know. Just to clarify, route integrity on its own (enabled via https://github.com/ Also, we on the Diego team think that we've finally finished ironing out a minor edge case around making sure incoming requests are handled correctly when app instances are being shutdown gracefully, so we expect to work with Release Integration in the next month or so to promote that route-integrity ops file to be a stable one and then later to be the default configuration in cf-deployment.
Certainly, thanks for the details! Best, Eric
|
||
|
||
Re: Proposal: Improving Security for HTTP Ingress to CFAR Application Containers
Mike Youngstrom
Got it.
We would probably not deploy the improved http ingress until tcp and ssh are both working. Our priority from the improvements in http ingress have been more on the reliable side and less on the security side. We haven't run into any NATS mis-routing requests issues for a while and we do have TCP customers. So, we would probably prefer to keep riding our current NATS good luck streak than disrupt our TCP customers.
That's perfect. We don't use the port. Some examples where cell ip address has come in handy: * Mostly firewall debugging. Our firewall situation is a mess. Lots of manual work and issues to debug where sometimes knowing the specific cell ip address can help in debugging a problem. * Occasionally customers want to do tcpdumps from a destination server. The ip of the cell hosting the source app instance helps reduce the tcpdump scope. Unfortunately, in tcpdump situations the CF operations team usually gets involved anyway to grab a tcpdump from the cell side since last time I checked we couldn't take tcpdumps from in a container. So, these scenarios are usually not very self service anyway. Hope that helps. Mike
|
||
|
||
Re: Proposal: Improving Security for HTTP Ingress to CFAR Application Containers
Eric Malm <emalm@...>
Hey, Mike, On Wed, Aug 15, 2018 at 10:36 AM, Mike Youngstrom <youngm@...> wrote:
Not quite: in the initial form of this more secured configuration, neither CF SSH nor TCP routing will work at all, as their gateway/front/edge routers would not have the network pathway into the container that they currently recognize. The Diego team is actually done at this point with the diego-release features required to enable that initial secured configuration, and will soon contribute an experimental operations file to opt into it to cf-deployment shortly and then focus on our approach to make CF SSH work again in this secure mode. We don't expect the current TCP routing tier ever to work with this configuration, though, as the Routing team is instead focused on the Istio integration effort as a longer-term plan to replace both the HTTP and TCP routing tiers. So I'm interested in knowing whether you'd be able to enable this extra security in any of your CF environments if either (a) CF SSH doesn't work as a result (short-term obstacle, resolved in a month or so) or (b) TCP routing doesn't work (longer-term obstacle, resolved only with Istio integration).
Great, thanks for the feedback! The CF_INSTANCE_IP environment variable will continue to contain the cell VM's IP inside the container environment, and it'll likewise still be present in the response from the CC stats endpoint, so it sounds like those network-debugging activities would be unaffected. It'd of course be great to hear the specifics of how having that cell VM IP has been useful to your developers or to you as the platform operators in resolving those network-related issues, though. Thanks again, Eric
|
||
|
||
PHP Buildpack Config Feedback
Daniel Mikusa
Hi All! To anyone out there using the PHP buildpack. We're trying to understand if what the buildpack does currently to configure Nginx + PHP-FPM so that it works within the defined memory limits works well for people and a variety of use cases. If you have any thoughts on this topic, please pop over to the following Github issue and leave some comments. Example questions to consider: Are there problems with what we do now? Does the current config work for most cases (80%+)? Are there things people routinely change, customize or override with how the buildpack configures memory usage now? Are there any concrete use cases that people could share good or bad related to this topic? etc.. Thanks in advance for any feedback! Dan
|
||
|
||
Re: Proposal: Improving Security for HTTP Ingress to CFAR Application Containers
Mike Youngstrom
We would love to have greater route integrity and security for our HTTP clients. If configuring this would provide those improvements to HTTP but not for TCP and SSH, we would still deploying it just to get the benefits for HTTP. Is that what you're asking?
We don't use these values as part of an API or client library. However, we do find it useful, on occasion, to know real network ip address of the cell an application is running on usually for firewall or other network debugging activities. We don't ever use the port information. I imagine we can find this information other ways but the CC api is currently the simplest way our application developers could self service find this data. I don't think this is a big issue. Just noting that my team (and perhaps others) will need to devise a different way to provide this information to app developers. Thanks, Mike
|
||
|
||
Re: [cf-bosh] Incubation proposal: CF Containerization
vlad.iovanov@...
Thank you for the great news Marco!
Cheers, Vlad
From: cf-dev@... <cf-dev@...> On Behalf Of Marco Voelz
Sent: Wednesday, August 15, 2018 12:10 PM To: CF BOSH Mailing List <cf-bosh@...> Cc: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>; cschum@... Subject: Re: [cf-dev] [cf-bosh] Incubation proposal: CF Containerization
Hi everyone,
The BOSH PMC voted unanimously in favor of incubating the CF Containerization project. Welcome to Vlad and the team!
Warm regards Marco
From: Voelz, Marco
Hi everyone,
Thanks for the comments, discussions and suggestions everyone! The deadline for raising major concerns before we go on with the usual incubation process ended on August 10th. I don't see any ongoing discussions that would prevent us moving forward, so I'll call for a vote within the PMC and we will then proceed.
Warm regards Marco
From: cf-bosh@... <cf-bosh@...> on behalf of Dmitriy Kalinin <dkalinin@...>
Thank you for submitting this proposal. Let's shoot for collecting and resolving most of the comments in the next month by Aug 10th and voting at that time to incubate it in BOSH PMC.
On Tue, Jul 3, 2018 at 2:25 AM, Cornelius Schumacher <cschum@...> wrote:
|
||
|
||
Re: [cf-bosh] Incubation proposal: CF Containerization
Marco Voelz
Hi everyone,
The BOSH PMC voted unanimously in favor of incubating the CF Containerization project. Welcome to Vlad and the team!
Warm regards Marco
From: Voelz, Marco
Sent: Monday, August 13, 2018 1:52 PM To: CF BOSH Mailing List Cc: Discussions about Cloud Foundry projects and the system overall. Subject: Re: [cf-bosh] Incubation proposal: CF Containerization Hi everyone,
Thanks for the comments, discussions and suggestions everyone! The deadline for raising major concerns before we go on with the usual incubation process ended on August 10th. I don't see any ongoing discussions that would prevent us moving forward, so I'll call for a vote within the PMC and we will then proceed.
Warm regards Marco
From: cf-bosh@... <cf-bosh@...> on behalf of Dmitriy Kalinin <dkalinin@...>
Sent: Friday, July 13, 2018 12:02:27 AM To: CF BOSH Mailing List Cc: Discussions about Cloud Foundry projects and the system overall. Subject: Re: [cf-bosh] Incubation proposal: CF Containerization Thank you for submitting this proposal. Let's shoot for collecting and resolving most of the comments in the next month by Aug 10th and voting at that time to incubate it in BOSH PMC.
On Tue, Jul 3, 2018 at 2:25 AM, Cornelius Schumacher
<cschum@...> wrote:
Hi all,
|
||
|
||
REMINDER: CAB call for August is Wednesday 08/15 @ 8a PST or 11a EST + TALKS AGENDA
Michael Maximilien
Quick reminder for the call on Wednesday and announcing two talks:
1. Using Istio Pilot and Envoy for Edge Routing in Cloud Foundry [1] by Shubha Anjur Tupil of Pivotal
2. Update on Project Eirini: Kubernetes backend for Cloud Foundry [2] by Julian Friedman of IBM
Full agenda and Zoom details in [0]. Zoom soon. Best,
------
dr.max ibm ☁ silicon valley, ca maximilien.org
----- Original message -----
|
||
|
||
Re: [cf-bosh] Incubation proposal: CF Containerization
Marco Voelz
Hi everyone,
Thanks for the comments, discussions and suggestions everyone! The deadline for raising major concerns before we go on with the usual incubation process ended on August 10th. I don't see any ongoing discussions that would prevent us moving forward, so I'll call for a vote within the PMC and we will then proceed.
Warm regards Marco
From: cf-bosh@... <cf-bosh@...> on behalf of Dmitriy Kalinin <dkalinin@...>
Sent: Friday, July 13, 2018 12:02:27 AM To: CF BOSH Mailing List Cc: Discussions about Cloud Foundry projects and the system overall. Subject: Re: [cf-bosh] Incubation proposal: CF Containerization Thank you for submitting this proposal. Let's shoot for collecting and resolving most of the comments in the next month by Aug 10th and voting at that time to incubate it in BOSH PMC.
On Tue, Jul 3, 2018 at 2:25 AM, Cornelius Schumacher
<cschum@...> wrote:
Hi all,
|
||
|
||
Stratos User Survey
Richard Cox
Hi All!
|
||
|
||
CF CLI v6.38.0 Released Today
Abby Chau
Hey everyone, The CF CLI team released cf CLI v6.38.0 today; please see release notes for full details. Highlights include: Changes to the `cf app app-name` Display
Multiple Buildpacks Support
Invocation Timeout Configuration
Upgraded to Golang 1.10.3
Support for SOCKS5
Other Enhancements
New Translations
Bug Fixes
Deprecations
Special Guests: Dies Koper (for helping us test SOCK5 support), SAPI London team (for tags support for user provided services and help updating the `cf service service-instance` table), Dr. Max and the IBM team (for translation updates). Best, Abby and the CLI team
|
||
|
||
CAB call for August is Wednesday 08/15 @ 8a PST or 11a EST
Michael Maximilien
FYI.., Please remember to book your calendar to join the Zoom call [0] Wednesday August 15th at 8a Pacific for QAs, PMC highlights, and community presentations. If you have a presentation about an OSS project related to CF or an update on a current project then please contact me ASAP. Reply direct to me or Slack. Zoom soon. Best, dr.max ibm ☁ silicon valley, ca
|
||
|
||
Re: routing-release 0.180.0
Shubha Anjur Tupil
I wanted to add a note to clarify now that some routing components use bpm. BPM needs to be colocated on the VM for the components that are using BPM (gorouter, routeing-api and route-registrar). If you are using cf-deployment, BPM is already colocated on the bosh deployed VMs, but if you are not using cf-deployment you would have to colocate the BPM job on the component VMs for gorouter, routing-api and route-registrar. Regards, Shubha
On Mon, Aug 6, 2018 at 4:08 PM, Shubha Anjur Tupil <sanjurtupil@...> wrote:
|
||
|
||
Re: Version of UAA to upgrade to from version 4.11.0
Sree Tummidi
Please update to the latest line which is 4.19.2 Thanks, Sree TummidiSr. Manager, Product Management Pivotal Cloud Foundry
On Tue, Aug 7, 2018 at 9:02 AM, <brian.sung@...> wrote: Hi, we are currently using version UAA 4.11.0 and like to update to a more recent version.
|
||
|
||
Version of UAA to upgrade to from version 4.11.0
brian.sung@...
Hi, we are currently using version UAA 4.11.0 and like to update to a more recent version.
Looking at the Github repo, the latest release is 4.12.4, and I think this is what I should aim for. But I also see 4.13.4, 4.14.0, and 4.19.2 releases. Are these releases of feature branches under development? Should I consider upgrading to one of these? Regards, Brian
|
||
|
||
routing-release 0.180.0
Shubha Anjur Tupil
Hi, We released routing-release 0.180.0 today.
Using BPM for routing components
Fixed Issues:
Regards, Shubha
|
||
|
||
Missing az_attr claim in access_token of password grant
Paul Bakare
Hi, An access_token gotten from password grant doesn't contain az_attr when decoded [1]. Is this by design? Is there something I'm doing wrongly? How do I access an access_token additional information (az_attr) when decoded? Kindly advise. Many thanks Odeyemi 'Kayode O. http://ng.linkedin.com/in/kayodeodeyemi. t: @charyorde
|
||
|
||
bosh and cf ssl cert update question
강경원 <kyungwon.kang@...>
Hello.
I created CERTS file with bosh-cli with var-store. By default, ssl will be expired after 1 year from generated day. Is there a best way to update ssl at bosh and cf?
|
||
|
||
Re: Headless browser support in nodejs-buildpack
Franks, Geoff
We had to solve a similar problem ourselves. We ended up building a custom stack for this, forking cflinuxfs2, and adding the additional packages + business logic on top. There are a number of buildpacks that may have issues with stacks not named `cflinuxfs2`, but the only buildpack we needed seemed to work with the custom name, so we have a default stack, and a custom stack for the apps that neeed Chrome. If you can support multi-buildpack pushes with the v3 API, you may be able to make use of that with https://github.com/cloudfoundry/apt-buildpack which would be less long-term maintenance + support compared to forking things.
From: <cf-dev@...> on behalf of "Pietsch, Mathias (Allianz Deutschland, externer Mitarbeiter)" <EXTERN.PIETSCH_MATHIAS@...>
Hello Cloudfoundry-Support team,
in our project we have the following issue:
we would like to generate a PDF-File with screenshots of our angular-html application. Therefore we need a buildpack with a headless browser support.
We already tried to generate screenshots with headless-chrome and phantomjs with the standard nodejs-buildpack. For the headless-chrome we received an error-message that the shared library libnss3.so is missing. The phantomjs process terminated immediately.
Do you have a solution for us to solve our problem? This would be very helpful for finishing our project.
Thank in advance and best regards.
Mathias Pietsch
dienstleistend für Allianz Deutschland AG, Grafische Oberflächen für ROPO Externer Brückenkopf: Darko Pelikan
Erreichbarkeit während des Projekts: Telefon: +49 (0) 711 6 63 - 1537 E-Mail: EXTERN.PIETSCH_MATHIAS@...
------------------------------------------------------------------
Telefon: +49 (0) 711 6 63 - 1537 E-Mail: Mathias.Pietsch@...
Schwalbenrainweg 24 D-63741 Aschaffenburg
PASS IT-Consulting Dipl.-Inf. G. Rienecker GmbH & Co. KG, Handelsregister: Amtsgericht Aschaffenburg HRA 2921, Sitz der Gesellschaft: Aschaffenburg, Komplementärin: Rienecker Beteiligungs-GmbH, Handelsregister: Amtsgericht Aschaffenburg HRB 7619, Sitz der Gesellschaft: Aschaffenburg, Geschäftsführer: Dipl. Inf. Gerhard Rienecker
|
||
|