Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CORS not working when configuration-snippet annotation is used #11990

Open
fiksn opened this issue Sep 18, 2024 · 4 comments
Open

CORS not working when configuration-snippet annotation is used #11990

fiksn opened this issue Sep 18, 2024 · 4 comments
Labels
kind/support Categorizes issue or PR as a support question. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. needs-priority needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. triage/needs-information Indicates an issue needs more information in order to work on it.

Comments

@fiksn
Copy link

fiksn commented Sep 18, 2024

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

@fiksn fiksn added the kind/bug Categorizes issue or PR as related to a bug. label Sep 18, 2024
@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Sep 18, 2024
@k8s-ci-robot
Copy link
Contributor

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
Copy link
Contributor

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

@k8s-ci-robot k8s-ci-robot added kind/support Categorizes issue or PR as a support question. triage/needs-information Indicates an issue needs more information in order to work on it. and removed kind/bug Categorizes issue or PR as related to a bug. labels Sep 19, 2024
@fiksn
Copy link
Author

fiksn commented Sep 19, 2024

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?

Copy link

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.

@github-actions github-actions bot added the lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. label Oct 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/support Categorizes issue or PR as a support question. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. needs-priority needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. triage/needs-information Indicates an issue needs more information in order to work on it.
Projects
Development

No branches or pull requests

3 participants