Date   
Announcement of planned deprecation of flag options (domains, hostname, route-path) on cf push on the v6 CLI

Abby Chau
 

Hi everyone,

The cf CLI team reached out to the Community back in December 2017 to gather feedback about domains and hostnames app manifest properties. Based on feedback, in cf CLI release v6.34.0, the team moved forward with deprecating domains and hostnames properties in the app manifest in favor of the routes attribute. 

At the time, the flag options to override the manifest properties were not deprecated. On `cf push` these include:
  • --hostname
  • --no-hostname
  • -d for domain
  • --route-path
This email announces planned deprecation of the above flag options on cf push on the v6 CLI, and to gather community feedback on our current approach on the v7 beta CLI for overriding routes using cf push. 

We welcome feedback in comments in this document, which also details:
  • the upcoming changes (the flags above will continue to work on v6 CLI but a deprecation notice will appear in the output)
  • a section calling for feedback for the v7 beta CLI (where we have removed these flag options).
Thanks and we hope to hear from you.

Best,

Abby Chau
cf CLI, Product Manager 





istio-release 1.3.0

Wa Gao
 

Hello cf-dev!

We have cut istio-release 1.3.0, here are the release highlights:

Release Highlights

- App developer can rely on the platform to provide client-side load balancing for app to app communication via container-to-container networking; requests will be evenly distributed across instances of applications mapped to the same internal route details
- App developer can rely on the platform to provide retries for app to app communication via container-to-container networking; the platform will retry requests three time if the response code is 5xx details
- Reliability and security improvement: Copilot consumes VIPs from CAPI to reduce the risk of misrouting details
- Bump istio to 1.2.0 in istio-release details
- Bump Envoy to 1.11.0 in istio-release details

No manifest changes 

Regards,
--

Wa Gao (Claire) | Senior Product Manager, Networking | Pivotal

Phone: 508-615-8644 | Email: wgao@...

 

Re: Upgrading to UAA 4.35.0 from UAA 4.30.0 stopped the UAA logging #uaa

Shetty, Viraj S [CTR]
 

I added a console setup and removed the file setup before compiling and it works. 

appender.console.type = Console
appender.console.name = STDOUT
appender.console.layout.type = PatternLayout
appender.console.layout.pattern = ${log_pattern}
 
rootLogger.level = INFO
rootLogger.appenderRef.stdout.ref = STDOUT
 
logger.cfIdentity.name = org.cloudfoundry.identity
logger.cfIdentity.level = debug
 

Re: Upgrading to UAA 4.35.0 from UAA 4.30.0 stopped the UAA logging #uaa

Chao Wang
 

+Joshua Casey who is the master of Log4j2 

On Tue, Jul 23, 2019 at 1:58 PM vshetty via Lists.Cloudfoundry.Org <vshetty=fdic.gov@...> wrote:

[Edited Message Follows]

Thanks Chaos. The doc says to create a custom env logging.config and point to log4j2 format file. Just like in the previous versions, why can we not get the logging by default ? 

Should I just create a custom log4j2.properties config file ? Is there an example of one that I can use ? The UAA war file does not contain a log4j2.properties otherwise i could have pointed to that. 

What is the best way to do this ? I am using the cloudfoundry environment, so I can't just push a log4j2.properties file. 

Thanks,
Viraj

Re: Upgrading to UAA 4.35.0 from UAA 4.30.0 stopped the UAA logging #uaa

Shetty, Viraj S [CTR]
 
Edited

Thanks Chaos. The doc says to create a custom env logging.config and point to log4j2 format file. Just like in the previous versions, why can we not get the logging by default ? 

Should I just create a custom log4j2.properties config file ? Is there an example of one that I can use ? The UAA war file does not contain a log4j2.properties otherwise i could have pointed to that. 

What is the best way to do this ? I am using the cloudfoundry environment, so I can't just push a log4j2.properties file. 

Thanks,
Viraj

CF-Deployment v10.0 release pulled due to a backward incompatible issue with UAA 73.4.0 #cf

Saikiran Yerram
 

Please use the next version of CF-Deployment as we have identified an issue with UAA version 73.4.0 due to a backward incompatibility issue in upgrading to Spring Security 5 on 07-19-2019. The next release of UAA would fix this issue.

Re: Upgrading to UAA 4.35.0 from UAA 4.30.0 stopped the UAA logging #uaa

Chao Wang
 

Hi Viraj,

Please check the release notes of UAA 4.31.0 which shared the changes you need to make, there are also additional comments from the tracker story if you need more details. 

Thanks,
Chao



On Mon, Jul 22, 2019 at 11:46 AM vshetty via Lists.Cloudfoundry.Org <vshetty=fdic.gov@...> wrote:
When I was using UAA 4.30.0, UAA used to log a lot of messages which was fine. However, I recently upgraded the UAA to 4.35.0 and the logging stopped working. I deploy UAA by getting the source from github link below, compiled it and then deployed using cloudfoundry push command

https://github.com/cloudfoundry/uaa/releases/tag/4.35.0

I understand that there was a change made to logging in 4.31.0 -  Upgrade to Log4j2 logging framework 

What do I need to do to get logging back ? Do I need to create a log4j2 file ? If so, where do I need to save it. 

Any help is appreciated. 

Thanks,
Viraj 

Upgrading to UAA 4.35.0 from UAA 4.30.0 stopped the UAA logging #uaa

Shetty, Viraj S [CTR]
 

When I was using UAA 4.30.0, UAA used to log a lot of messages which was fine. However, I recently upgraded the UAA to 4.35.0 and the logging stopped working. I deploy UAA by getting the source from github link below, compiled it and then deployed using cloudfoundry push command

https://github.com/cloudfoundry/uaa/releases/tag/4.35.0

I understand that there was a change made to logging in 4.31.0 -  Upgrade to Log4j2 logging framework 

What do I need to do to get logging back ? Do I need to create a log4j2 file ? If so, where do I need to save it. 

Any help is appreciated. 

Thanks,
Viraj 

Re: Running UAA on Kubernetes behind TLS-enabled ingress controller #uaa

Filip Hanik
 

hi Enrique,

The port number will not be forced if 
  the appropriate proxy headers are set 
*AND* 
  the request comes from a trusted IP (Tomcat's RemoteIpValve)

ie, the HttpServletRequest.getScheme does not return https because the web server (ie Apache Tomcat) does not trust the source of the request, so the headers are ignored.

I'm not sure why that filter is even in the UAA. The code of the filter basically states

_Apache Tomcat doesn't trust the X-Forwarded-Proto header, so our code will do so instead and override the behavior_

So that code should not exist, as it indicates a workaround for a misconfigured system.

You need to configure your RemoteIpValve correctly, if you are using Apache Tomcat
and then your problem will go away



[Operators SIG Meeting] Call for Content - July 24

Gowrisankar M
 

Dear Cloud Foundry Community,

Please let me or Karthik know, if you’d like to bring any specific topics for discussion for the next sig meeting on Wednesday, June 24th at 08:00 US Pacific | 11:00 US Eastern | 20:30 Indian Standard Time.

Please add the calendar appt from here: https://www.cloudfoundry.org/community-calendar.

BRs, Gowrisankar

CF-Deployment v10.0 is now live #cf

Saikiran Yerram
 

Happy Friday everyone,

CF-deployment v10.0 is now live. Please refer to the release notes for breaking changes: https://github.com/cloudfoundry/cf-deployment/releases/tag/v10.0.0


Let me know if you have any questions,

Re: Running UAA on Kubernetes behind TLS-enabled ingress controller #uaa

Enrique Cano
 

Thank you, Filip.

We are not using uaa-release, and we can control the protocol (https). Our issue is that the port number is forced to be 443 when we don't want that to happen.

Regards

Enrique

Re: CF Application Runtime PMC: Loggregator Project Lead Call for Nominations

Eric Malm <emalm@...>
 

Hi, everyone,

Pivotal is nominating Allen Duet for the Loggregator Project Lead in the Application Runtime PMC.

Allen is a Director of Product Management at Pivotal where he oversees Cloud Foundry products related to Observability and Automation. Allen joined Pivotal and Cloud Foundry in December 2015.

Prior to joining Pivotal, Allen was Chief Technology Officer at Swiftpage ACT!, a software company focused on CRM and email marketing products for businesses. Allen is located in Denver and enjoys hiking, skiing, and a variety of outdoor activities.

Please send any other nominations directly to me or in reply to this message no later than 11:59 PM PDT on Monday, May 20, 2019.

Thanks,
Eric Malm

On Thu, Jul 18, 2019 at 4:57 PM Eric Malm <emalm@...> wrote:
Hi, everyone,

Fred Krone, the lead for the Loggregator project within the Application Runtime PMC, is stepping down from the project, as he has recently left Pivotal. We thank him for his  service.

The Loggregator team, located in Denver, now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PDT on Friday, Aug 2, 2019.

Also, if you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

Thanks,
Eric Malm, CF Application Runtime PMC Lead

CF Application Runtime PMC: Loggregator Project Lead Call for Nominations

Eric Malm <emalm@...>
 

Hi, everyone,

Fred Krone, the lead for the Loggregator project within the Application Runtime PMC, is stepping down from the project, as he has recently left Pivotal. We thank him for his  service.

The Loggregator team, located in Denver, now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PDT on Friday, Aug 2, 2019.

Also, if you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

Thanks,
Eric Malm, CF Application Runtime PMC Lead

routing-release 0.189.0

Aidan Obley
 

Hello cf-dev!

We have cut routing-release 0.189.0.

This release includes several fixes and improvements. Notably, this release encrypts the control plane interactions with the routing-api.

Release Highlights

  • Gorouter is configurable to prune with TTL when using TLS to validate backend identity. This is a temporary mitigation of an issue where a route deregistration message is lost details
  • gorouter_ctl runs correctly on Xenial stemcells details
  • Operator can configure routing-api to support mTLS connections details
  • Routing API provides a bosh link that route registrar consumes to enable mTLS with the routing api details
  • Operator can configure route-registrar to communicate over mTLS to routing-api details
  • gorouter consumes Routing-API Link for mtls properties details
  • Operator can configure gorouter to fetch routes over mTLS from routing-api details
  • TCP Router consumes Routing-API Link for mtls properties details
  • Operator can configure tcp-router to communicate over mTLS to routing-api details
  • Route registrar route_registrar.routing_api.skip_ssl_validation property is now correctly applied details
  • Operator can to configure gorouter with client certs for route services details
  • cloudfoundry/routing-release #146: Deploy does not fail when required property server_cert_domain_san is not configured details

Manifest Property Changes

Job Property 0.188.0 Default 0.189.0 Default
gorouter router.route_services.cert_chain did not exist undefined
gorouter router.route_services.private_key did not exist undefined
gorouter routing_api.uri http://routing-api.service.cf.internal https://routing-api.service.cf.internal
gorouter routing_api.port 3000 from routing_api link
gorouter routing_api.ca_certs did not exist from routing_api link
gorouter routing_api.cert_chain did not exist from routing_api link
gorouter routing_api.private_key did not exist from routing_api link
gorouter router.prune_all_stale_routes did not exist false
gorouter router.set_kernel_parameters did not exist true
route_registrar route_registrar.logging_level did not exist info
route_registrar route_registrar.routing_api.api_url http://routing-api.service.cf.internal:3000 https://routing-api.service.cf.internal:3001
route_registrar route_registrar.routing_api.client_cert did not exist from routing_api link
route_registrar route_registrar.routing_api.client_private_key did not exist from routing_api link
route_registrar route_registrar.routing_api.server_ca_cert did not exist from routing_api link
routing-api routing_api.enabled_api_endpoints did not exist “both”
routing-api routing_api.mtls_port did not exist 3001
routing-api routing_api.mtls_ca did not exist generated by credhub
routing-api routing_api.mtls_server_cert did not exist generated by credhub
routing-api routing_api.mtls_server_key did not exist generated by credhub
routing-api routing_api.mtls_client_cert did not exist generated by credhub
routing-api routing_api.mtls_client_key did not exist generated by credhub
routing-api consul.servers http://127.0.0.1:8500 removed property
routing-api routing_api.skip_consul_lock false removed property
tcp_router routing_api.uri http://routing-api.service.cf.internal https://routing-api.service.cf.internal
tcp_router routing_api.port 3000 from routing_api link
tcp_router routing_api.client_cert did not exist from routing_api link
tcp_router routing_api.client_private_key did not exist from routing_api link
tcp_router routing_api.ca_cert did not exist from routing_api link

Regards,
The Networking Program

Update to CF-Deployment v10.0 scope #cf

Saikiran Yerram
 

Good day everyone,

We have an update on the scope for CF-Deployment v10.0. We are postponing BOSH Service discovery to the next major release. The changes require additional validation and will not be ready for v10 release. I have updated the scope doc accordingly. 

https://docs.google.com/document/d/1qWaFHcquPUaWrVWndJuWt-W_niflN2p4aVqvqy2EyM4/edit#

Please let me know if you have any questions.

Re: Running UAA on Kubernetes behind TLS-enabled ingress controller #uaa

Filip Hanik
 

request.getScheme() can return https properly if you configure the web server (Tomcat/Jetty) to trust the headers X-Forwarded-Proto based on the IP address of the proxy server.

If you're using uaa-release, you can configure

This will ensure that https is returned and line 44 is never invoked.
Filip

On Tue, Jul 16, 2019 at 9:09 AM Enrique Cano <enrique.canocarballar@...> wrote:
Hi

We are running UAA behind an ingress controller on Kubernetes. The connection to the ingress controller is https on a port other than 443 e.g. 8443. The connection to UAA pod is http.
The issue we are facing is that the URLs UAA will return to the browser during the OAuth handshake include http instead of https. When we set X-Forwarded-Proto to "https" at the ingress controller, then the returned URLs contain https, but the port is set to 443. We believe this is because of this line of code: https://github.com/cloudfoundry/uaa/blob/develop/server/src/main/java/org/cloudfoundry/identity/uaa/security/web/FixHttpsSchemeRequest.java#L44
Is there another way of doing this? Basically, instead of redirecting to http://url:8080, we want a redirection to https://url:8443. Currently, what we get is https://url with the X-Forwarded-Proto header set to "https".

Many thanks in advance

Enrique.

FINAL REMINDER: CAB call for July is next week Wednesday 17th @ 8a Pacific

Michael Maximilien
 

FYI... see below

——
Hi, all,
 
Reminder that the CAB call [0] for July 2019 is next Wednesday 17th @ 8a Pacific.
 
We will have regular highlights, QAs, as well as two planned talks:
 
1. External DNS Connector for Cloud Foundry [1] by David Grizzanti of Comcast
2. Stratos UI Update - now with Kubernetes support [2] by Neil MacDougall of SUSE
 
Please note that talk 1 was in previous agenda but had to be postponed.
 
All other info in agenda [0]. Zoom soon. Best,
 


Running UAA on Kubernetes behind TLS-enabled ingress controller #uaa

Enrique Cano
 

Hi

We are running UAA behind an ingress controller on Kubernetes. The connection to the ingress controller is https on a port other than 443 e.g. 8443. The connection to UAA pod is http.
The issue we are facing is that the URLs UAA will return to the browser during the OAuth handshake include http instead of https. When we set X-Forwarded-Proto to "https" at the ingress controller, then the returned URLs contain https, but the port is set to 443. We believe this is because of this line of code: https://github.com/cloudfoundry/uaa/blob/develop/server/src/main/java/org/cloudfoundry/identity/uaa/security/web/FixHttpsSchemeRequest.java#L44
Is there another way of doing this? Basically, instead of redirecting to http://url:8080, we want a redirection to https://url:8443. Currently, what we get is https://url with the X-Forwarded-Proto header set to "https".

Many thanks in advance

Enrique.

Re: Security feed not updating

Chip Childers
 

Pivotal doesn't have access. The CFF web team resolved this issue a week ago. Thanks! 


On Mon, Jul 15, 2019 at 6:09 PM Emily Foster <efoster@...> wrote:
Hi Lee,

I'm forwarding your message along to the Pivotal security team to take a look.

Thanks,
Emily

On Tue, Jul 2, 2019 at 12: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