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

Merging nnginx.ingress.kubernetes.io/whitelist-source-range annotation with global config #12332

Open
iamalryz opened this issue Nov 9, 2024 · 3 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. 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.

Comments

@iamalryz
Copy link

iamalryz commented Nov 9, 2024

According to documentation, at the moment annotation nginx.ingress.kubernetes.io/whitelist-source-range totally overrides corresponding option from ConfigMap.

In my use case I want to configure trusted networks globally for all Ingress objects (by whitelist-source-range option at ConfigMap), and add another trusted IPs/networks for particular Ingress objects.

If I use annotation nginx.ingress.kubernetes.io/whitelist-source-range on particular Ingress object, I loose access to its from trusted networks configured globally.

It would be nice to have a toggle to enable merging nnginx.ingress.kubernetes.io/whitelist-source-range annotation with whitelist-source-range option from ConfigMap.

Like this:

nginx.ingress.kubernetes.io/whitelist-source-range-mode: <override|merge>

With default value of override.

I couldn't find another issues about this feature.

@iamalryz iamalryz added the kind/feature Categorizes issue or PR as related to a new feature. label Nov 9, 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 Nov 9, 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

What are the nginx.conf directives that get configured for this and in which contexts

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 Dec 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. 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.
Projects
Development

No branches or pull requests

3 participants