Proxy Configuration Warning

[AhmedBytesBits]

Describe the bug
Proxy Configuration Warning after installation using the official helm chart on GKE
The warning is shown in the Admin dashboard ,as following:

It appears that FusionAuth is running behind a proxy server and your configuration is not correct.

Your browser reported a request origin that is not equal to the actual HTTP request. Because these are not equal we will fail CSRF (Cross Site Request Forgery) validation when you submit a form that is using the POST method. If you attempt to create an Application, API key, User, etc you will receive an Unauthorized message.

Reported request origin:
https://example.com

Actual request origin:
https://example.com:9011

The following X-Forwarded- HTTP request headers were detected on the request:
X-Forwarded-Proto: https

To correct the origin, add the following request headers through your proxy configuration:
X-Forwarded-Port: 443

I can view all resources but cannot make any changes on the instance except via the API

Docker version and underlying OS
GKE 1.22

To Reproduce
Steps to reproduce the behavior:
Follow the installation steps in the official repo

Expected behavior
The system should work as expected when deployed using the official repo

Logs (please share snips of applicable logs)
Nothing

Additional context
I am using certificate provisioned by GCP added to the ingress service as annotation

[johnjeffers]

Hello @AhmedBytesBits!

In newer versions of GKE (1.25+), you can use a BackendConfig CRD to pass custom request headers that should fix the proxy warning.

An example would look something like this:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-fusionauth
  namespace: fusionauth
spec:
  customRequestHeaders:
    headers:
    - 'X-Forwarded-Port: 443'

Then you would add this annotation to your service:

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default":"my-fusionauth"}'
    cloud.google.com/neg: '{"ingress":true}'

In my own internal testing, it took 3-5 minutes for the configuration to go into effect, for the proxy warning to disappear.