Status Update
Comments
ob...@google.com <ob...@google.com>
an...@google.com <an...@google.com> #2
Hello,
Thanks for reaching out to us!
The Product Engineering Team has been made aware of your feature request, and will address it in due course. Though we can't provide an ETA on feature requests nor guarantee their implementation, rest assured that your feedback is always taken very seriously, as it allows us to improve our products. Thank you for your trust and continued support to improve Google Cloud Platform products.
In case you want to report a new issue, please do not hesitate to create a new
Thanks & Regards,
Manish Bavireddy.
Google Cloud Support
da...@gmail.com <da...@gmail.com> #3
We are stuck with the same problem.
We have an open case with Google Support about this and, among others, they have redirected us here.
We have tried the following workaround:
START THE WORKARROUND
As per temporary fix the recommended way to match on port would be at the Gateway level.In the following example, the Route will only match incoming traffic on port 80 because it's attaching to the "http" Gateway listener.
apiVersion:
kind: Gateway
metadata:
name: my-gateway
spec:
gatewayClassName: gke-l7-global-external-managed
listeners:
- name: http
protocol: HTTP
port: 80
- name: https
protocol: HTTPS
port: 443
---
apiVersion:
kind: HTTPRoute
metadata:
name: http-store-80
spec:
parentRefs:
- name: my-gateway
sectionName: http
hostnames:
- "
rules:
backendRefs:
- name: my-service
port: 8080
END THE WORKARROUND
But the workarround has not worked, the problem persists.
We post this comment to see what the status of the Issue is and to see if there are other workarrounds available.
Thanks & Regards,
Joan Cholvi.
Mercadona
se...@epam.com <se...@epam.com> #4
Hi,
Thanks for your response.
The information has been shared with the Product Team and further updates will be provided in this thread.
According to the
Please note that the Issue Tracker is primarily meant for reporting bugs and requesting new features. If you have any additional issues or concerns, please don’t hesitate to create a new thread on the
Thanks
[Deleted User] <[Deleted User]> #5
da...@e4s.co.uk <da...@e4s.co.uk> #6
Hello,
we also had the problem of receiving an 404 HTTP Error with the body message 'fault filter abort' whenever a client connects to the gatway with a port inside the 'Host' Header.
For everyone looking for a workaround, try it this way: For every domain, create one HTTPRoute with two matchers for the HTTP Header "Host". One matching "Host" to "domain:port" and one matching "Host" to "domain" without the port.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: my-workaround-https-route
spec:
# hostnames:
# - "mydomain.com"
parentRefs:
- kind: Gateway
name: my-gateway
sectionName: https-listener
rules:
# This host header matchers are the workaround
# Open issue at google (https://issuetracker.google.com/issues/294510336)
- matches:
# Matches domain with port
- headers:
- name: "Host"
value: "mydomain.com:443"
path:
value: /
type: PathPrefix
# Matches domain only
- headers:
- name: "Host"
value: "mydomain.com"
path:
value: /
type: PathPrefix
# This is not important for the workaround but maybe also useful for people switching from ingress to gateway
filters:
- type: RequestHeaderModifier
requestHeaderModifier:
set:
- name: X-Forwarded-Host
value: "{tls_sni_hostname}"
backendRefs:
- name: my-backend-service
port: 8080
The downside is that you have to create matchers instead of just simply listing all the domains you want to route through this rule. If you use multiple HTTPRoute resources for the same domains, make sure that the rules do not overwrite each other.
I hope the issue gets resolved quickly, we can't implement it on all domains and can't migrate all load balancers to gateway api.
ra...@7shifts.com <ra...@7shifts.com> #7
Experiencing the same issue after upgrading gateway class from gke-l7-gxlb
to gke-l7-global-external-managed
.
go...@youplant.io <go...@youplant.io> #8
[Deleted User] <[Deleted User]> #9
mn...@gmail.com <mn...@gmail.com> #10
This is really needed for us as well
al...@gmail.com <al...@gmail.com> #11
This is really needed for us as well
as...@appdat.jsc.nasa.gov <as...@appdat.jsc.nasa.gov> #12
ba...@google.com <ba...@google.com>
ba...@google.com <ba...@google.com> #13
Hello,
Thanks for reaching out to us!
The Product Engineering Team has been made aware of your feature request, and will address it in due course. Though we can't provide an ETA on feature requests nor guarantee their implementation, rest assured that your feedback is always taken very seriously, as it allows us to improve our products. Thank you for your trust and continued support to improve Google Cloud Platform products.
In case you want to report a new issue, please do not hesitate to create a new
Thanks & Regards,
Manish Bavireddy.
ge...@glamuse.com <ge...@glamuse.com> #14
For use ingress-nginx as a standard in industry. Not gce.
ka...@google.com <ka...@google.com>
ka...@google.com <ka...@google.com>
gu...@arquivei.com.br <gu...@arquivei.com.br> #15
For use ingress-nginx as a standard in industry. Not gce.
Description
What you would like to accomplish:
Ingress-nginx to support Cloud Armor since it is a GCP
How this might work:
If applicable, reasons why alternative solutions are not sufficient:
In official documentation of GKE and Cloud Armor [1], it is mentioned that Cloud Armor can be used with Bakcneds of GKE ingress controller. It would be useful that it is also used with nginx-ingress.
Other information (workarounds you have tried, documentation consulted, etc):
[1]