CORS not working when configuration-snippet annotation is used

[fiksn]

What happened:

I am using nginx.ingress.kubernetes.io/configuration-snippet together with
nginx.ingress.kubernetes.io/cors-allow-origin and nginx.ingress.kubernetes.io/enable-cors annotations.

What you expected to happen:

I expected nginx.ingress.kubernetes.io/configuration-snippet value to be present in generated nginx.conf together with the generated code allowing CORS. However I can see only the stuff from configuration-snippet. It appears the CORS part starting with:

# Cors Preflight methods needs additional options and different Return Code
if ($http_origin ~*  ...

is not present in nginx.conf when you also use configuration-snippet. I can manually copy that code to configuration-snippet but I believe this to be a bug. I apologize if this is a known issue already or works like that by design but from Using this annotation you can add additional configuration to the NGINX location I got the impression both parts should be merged.

-------------------------------------------------------------------------------
NGINX Ingress controller
  Release:       v1.9.5
  Build:         f503c4bb5fa7d857ad29e94970eb550c2bc00b7c
  Repository:    https://github.com/kubernetes/ingress-nginx
  nginx version: nginx/1.21.6
-------------------------------------------------------------------------------

Kubernetes version (use kubectl version):

Server Version: v1.30.3-eks-2f46c53

[k8s-ci-robot]

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.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[longwuyuan]

Please write a step-by-step guide here that readers can copy/paste from, on a kind cluster or a minikube cluster. This will help others reproduce the problem and that is required because what you have posted can not be analyzed or debugged.

/remove-kind bug
/kind support
/triage needs-information

[fiksn]

While working on a minimal reproducible example I figured out what I said before isn't completely true - the snippets are present in the nginx.conf I just overlooked them since there was a lot of other stuff in between. I apologize for that.

It's really easier with a smaller test case. However there is still the weird behavior but let's go through the example:

---
apiVersion: v1
kind: Service
metadata:
  name: external-service
spec:
  type: ExternalName
  externalName: google.com
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/cors-allow-origin: '*'
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/configuration-snippet: |
      set $random_variable "false";
      if ($random_variable = "true") {
      }
  name: test-ingress
spec:
  rules:
  - host: dummy
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: external-service
            port:
              number: 80

I apply this and then to make it simple (provider agnostic) on the ingress controller nginx pod I just do:

$ curl localhost -H "Host: dummy" -vv 2>&1 | grep Access-Control-Allow-Origin
< Access-Control-Allow-Origin: *

(ignore that you get 404 and everything, it's just the header that matters, like I said my use-case is more than that and doesn't involve wildcard cors-allow-origin but I simplified it).

Now the strange part is when I change $random_variable to true or something else so the if condition is true and apply that:

$ curl localhost -H "Host: dummy" -vv 2>&1 | grep Access-Control-Allow-Origin

I don't get the header set. However it's just an empty { }. How can that interfere with the generated code for setting the CORS headers?

[github-actions]

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.

[elizabeth-dev]

duplicate of #10267.

might want to read this regarding if directives in Nginx (tl;dr: they are only good to use for return and rewrite.

keep an eye on #12424 for the fix on the inconsistent behavior.

/assign
/triage duplicate