Open fiksn opened 2 months ago
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.
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
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?
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.
What happened:
I am using
nginx.ingress.kubernetes.io/configuration-snippet
together withnginx.ingress.kubernetes.io/cors-allow-origin
andnginx.ingress.kubernetes.io/enable-cors
annotations.What you expected to happen:
I expected
nginx.ingress.kubernetes.io/configuration-snippet
value to be present in generatednginx.conf
together with the generated code allowing CORS. However I can see only the stuff fromconfiguration-snippet
. It appears the CORS part starting with:is not present in
nginx.conf
when you also useconfiguration-snippet
. I can manually copy that code toconfiguration-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 fromUsing this annotation you can add additional configuration to the NGINX location
I got the impression both parts should be merged.Kubernetes version (use
kubectl version
):Server Version: v1.30.3-eks-2f46c53