This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

I dealt with the same problem yesterday with Access-Control-Allow-Origin: * always returning based on the backend logic that NGINX generates for service via the nginx.conf as soon as I specified the annotation: nginx.ingress.kubernetes.io/cors-allow-origin: <host>

I had to take an alternative approach using the nginx.ingress.kubernetes.io/configuration-snippet annotation, setting headers with the more_set_headers function.

Here's what works for me - I updated the logic to support multiple origins - https://serverfault.com/a/1036160 (Thank you Marcel!)
This is a temporary workaround for me until the annotation logic works again.

annotations:
  nginx.ingress.kubernetes.io/configuration-snippet: |-
    if ($http_origin ~* "^https?://(example.com|example2.com)$") {
        set $allow_origin $http_origin;
    }

    more_set_headers 'Access-Control-Allow-Origin: $allow_origin';
    more_set_headers 'Access-Control-Allow-Credentials: true';
    more_set_headers 'Access-Control-Allow-Methods: GET , OPTIONS, POST';
    more_set_headers 'Access-Control-Allow-Headers: Authorization,Content-Type';
    # Cors Preflight methods needs additional options and different Return Code - UPDATED
    if ($request_method = 'OPTIONS') {
        more_set_headers 'Access-Control-Max-Age: 1728000';
        more_set_headers 'Content-Type: text/plain charset=UTF-8';
        more_set_headers 'Content-Length: 0';
        return 204;
    }

Can provide the nginx.conf? The version of the controller, deployment and other logs that might be helpful, and the ingress resource you are using to test?

-James

I had to take an alternative approach using the nginx.ingress.kubernetes.io/configuration-snippet annotation, setting headers with the more_set_headers function.

I opted for a similar workaround in the end, but it's still disappointing to not be able to use the annotation.

Can provide the nginx.conf? The version of the controller, deployment and other logs that might be helpful, and the ingress resource you are using to test?

@strongjz can I ask what you mean by 'the ingress resource you are using to test'?

This is stale, but we won't close it automatically, just bare in mind the maintainers may be busy with other tasks and will reach your issue ASAP. If you have any question or request to prioritize this, please reach #ingress-nginx-dev on Kubernetes Slack.

Hi @strongjz,
I have similar question problem.

TLDR: This configuration send cors headers only when origin is equal https://mysite.com. In all other case it sends no cors, so the source doesn't say to browser for which origin is intended.

Image: registry.k8s.io/ingress-nginx/controller:v1.10.0
Logs: doesn't contains any error.

Nginx.conf

set $proxy_alternative_upstream_name "";

# Cors Preflight methods needs additional options and different Return Code

if ($http_origin ~* ((https://mysite\.com))$ ) { set $cors 'true'; }

if ($request_method = 'OPTIONS') {
	set $cors ${cors}options;
}

if ($cors = "true") {
	more_set_headers 'Access-Control-Allow-Origin: $http_origin';
	more_set_headers 'Access-Control-Allow-Credentials: true'; 
	more_set_headers 'Access-Control-Allow-Methods: GET, PUT, POST, DELETE, PATCH, OPTIONS';
	more_set_headers 'Access-Control-Allow-Headers: DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
	
	more_set_headers 'Access-Control-Max-Age: 1728000';
}

if ($cors = "trueoptions") {
	more_set_headers 'Access-Control-Allow-Origin: $http_origin';
	more_set_headers 'Access-Control-Allow-Credentials: true'; 
	more_set_headers 'Access-Control-Allow-Methods: GET, PUT, POST, DELETE, PATCH, OPTIONS';
	more_set_headers 'Access-Control-Allow-Headers: DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
	
	more_set_headers 'Access-Control-Max-Age: 1728000';
	more_set_headers 'Content-Type: text/plain charset=UTF-8';
	more_set_headers 'Content-Length: 0';
	return 204;
}

client_max_body_size                    1m;

proxy_set_header Host                   $best_http_host;

Ingess

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    acme.cert-manager.io/http01-edit-in-place: "true"
    cert-manager.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/cors-allow-origin: https://mysite.com
    nginx.ingress.kubernetes.io/enable-cors: "true"

Related code rows:

• https://github.com/kubernetes/ingress-nginx/blob/main/rootfs/etc/nginx/template/nginx.tmpl#L976
• https://github.com/kubernetes/ingress-nginx/blob/main/internal/ingress/controller/template/template.go#L1733

same problem in 1.9.4, is anything new with this issue?

@benosmond @patog could you share the yaml for the Ingress resource that is causing your issue? I've just tried to reproduce it with this config:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/cors-allow-credentials: "false"
    nginx.ingress.kubernetes.io/cors-allow-headers: x-forwarded-for,foo
    nginx.ingress.kubernetes.io/cors-allow-origin: '*'
    nginx.ingress.kubernetes.io/enable-cors: "true"
  name: demo-localhost
  namespace: default
spec:
  ingressClassName: nginx
  rules:
  - host: demo.localdev.me
    http:
      paths:
      - backend:
          service:
            name: demo
            port:
              number: 80
        path: /
        pathType: Prefix

and I got this response on a GET request (note the Access-Control-Allow-Headers header present in the response):

~ curl -v --location 'http://demo.localdev.me'                                                                        20:50:00
* Host demo.localdev.me:80 was resolved.
* IPv6: (none)
* IPv4: 192.168.64.2
*   Trying 192.168.64.2:80...
* Connected to demo.localdev.me (192.168.64.2) port 80
> GET / HTTP/1.1
> Host: demo.localdev.me
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Date: Thu, 21 Nov 2024 19:50:11 GMT
< Content-Type: text/html
< Content-Length: 50
< Connection: keep-alive
< Last-Modified: Thu, 21 Nov 2024 19:50:02 GMT
< ETag: "673f8eea-32"
< Accept-Ranges: bytes
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, PUT, POST, DELETE, PATCH, OPTIONS
< Access-Control-Allow-Headers: x-forwarded-for,foo
< Access-Control-Max-Age: 1728000
<
HOSTNAME=demo-c879b6c47-tftbm
* Connection #0 to host demo.localdev.me left intact

/triage not-reproducible

/remove-lifecycle frozen
/triage needs-information

/assign

@elizabeth-dev

@benosmond @patog could you share the yaml for the Ingress resource that is causing your issue? I've just tried to reproduce it with this config:

Unfortunately it's been a while and I no longer have the YAML I was using to test this. I ended up using a configuration snippet to add in the headers I wanted to every request, which worked fine at the cost of a few extra lines.

From what I remember, the chart I was using looked pretty much the same as your example, so maybe this is working now.

@benosmond yeah, sorry about that... happy to see that the issue seems to be solved though!

I have the same problem when I have this configuration snipped also applied on my ingress (from this issue):

nginx.ingress.kubernetes.io/configuration-snippet: |
            set $forwarded_scheme $http_x_forwarded_proto;
            if ($forwarded_scheme = "") {
                set $forwarded_scheme $scheme;
            }
            if ($forwarded_scheme = "http") {
              return 403 "This endpoint is only accessible via HTTPS. You are currently using plaintext HTTP.";
            }

curl -i -X OPTIONS https://... returns CORS headers but not curl -i -X GET https://...

Full definition:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/configuration-snippet: |-
      set $forwarded_scheme $http_x_forwarded_proto;
      if ($forwarded_scheme = "") {
          set $forwarded_scheme $scheme;
      }
      if ($forwarded_scheme = "http") {
        return 403 "This endpoint is only accessible via HTTPS. You are currently using plaintext HTTP.";
      }
    nginx.ingress.kubernetes.io/cors-allow-credentials: "true"
    nginx.ingress.kubernetes.io/cors-allow-headers: DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization,X-Org
    nginx.ingress.kubernetes.io/cors-allow-methods: GET, POST, PUT, PATCH, DELETE,
      OPTIONS
    nginx.ingress.kubernetes.io/cors-allow-origin: https://toto.example.com, https://*.toto.example.com
    nginx.ingress.kubernetes.io/cors-expose-headers: Location, x-pagination, Link
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/modsecurity-snippet: |-
      SecRuleRemoveById 920220
  name: super-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: api.toto.example.com
    http:
      paths:
      - backend:
          service:
            name: toto-api
            port:
              number: 8080
        path: /
        pathType: Prefix

@awoimbee thank you for sharing that specific case, because I've been able to pinpoint the underlying issue.

basically, it seems like if directives in Nginx behave... in an interesting way (to say something), and it seems the code for the CORS headers was sometimes affected (not always it seems)

in any case, fix is on its way!