Allow configuring CORS in ConfigMap

[rittneje]

Currently we have to manually config CORS in the annotations for each individual Ingress. This is very annoying. Instead, there should be ConfigMap fields corresponding to all the CORS annotations that get used by default.

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/
https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#enable-cors

[k8s-ci-robot]

@rittneje: 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/test-infra repository.

[longwuyuan]

This will be helpful in certain use cases. But in some other use cases, mismatch of domains will actually inject the global CORS config into ingress rules where the global CORS config would not be desired.

[rittneje]

@longwuyuan What do you mean by "mismatch of domains"?

[longwuyuan]

Domain configured in the global CORS config and Domain of the value in the field ingress.spec.rules.host

[rittneje]

Seems like that could be resolved by allowing people to define global CORS settings per hostname then. Although realistically I'm not sure how much the distinction matters in practice.

Even being able to define these annotations once in some custom ConfigMap, and then having all the relevant Ingresses simply reference that ConfigMap via some annotation, would be a vast improvement over the situation today.

[longwuyuan]

Agreed. But the implementation has to be optional opt-in. Any change to the code needs to avoid a scene like "compulsory opt-in + optional opt-out".

[rittneje]

Wouldn't setting the config map in the first place essentially be opting in?

[longwuyuan]

Yes, hence my comment, based on the assumption not everyone will want that. It could also break multiple current uses.

[rittneje]

I don't understand what you mean. Anyone using ingress-nginx would have to go and set this new proposed config map field. This has nothing to do with it being separate per hostname or not. If the config map field is not present, then there is no global CORS configuration, so in essence it defaults to exactly what you have today - CORS is disabled. And if the cluster operator (or whoever is in charge of the ingress-nginx deployment) is going to set it, they should understand what it means. In short, adding support for a new ConfigMap field does not have any potential to break any current uses.

Separately, if someone defines the CORS annotations directly on an Ingress, then this should take precedence over any global settings. Specifically, if you set the nginx.ingress.kubernetes.io/enable-cors annotation, then all the config map settings are ignored.

This enables the following use cases:

1. If you want to only define CORS per Ingress, then don't add anything to the ConfigMap. This will follow the current behavior as-is.
2. If you do choose to define CORS globally, you can then choose to opt-out a specific Ingress by setting nginx.ingress.kubernetes.io/enable-cors: "false" in its annotations.
3. Similarly, if you do choose to define CORS globally, you can then choose to override for a specific Ingress by setting nginx.ingress.kubernetes.io/enable-cors: "true", etc. in its annotations.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale