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?