-
-
Notifications
You must be signed in to change notification settings - Fork 98
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
[Feature] Add support for loadBalancerSourceRanges #98
Comments
Thanks for the suggestion, but Please sed inlets with "inlets-operator" :-) And this feature request will only work with inlets PRO |
@alexellis, can you explain why this will only work with inlets PRO? I was thinking about passing this source ranges to the provisioners. |
Let me check that I understand you correctly then. Are you asking to define a number of TCP ports that are exposed by the exit-server? |
It is more about IP CIDR blocks. Some cloud providers honor the |
OK, I misunderstood what you wanted. I thought you were asking for a range of ports, related to your other request under #97.
Perhaps you can link this to the appropriate Kubernetes docs page and give a specific example of what might be within that field? |
The loadBalancerSourceRanges field is mentioned in Kubernetes API Reference I've updated the request with an example. If this request does not really fit in the idea of inlets-operator, I fully understand that |
Expected Behaviour
To configure a Load Balancer firewall, there is the option to use the Service's loadBalancerSourceRanges to define the ranges that should be allowed.
When possible, the provisioner could create firewall rules based on the ranges defined in loadBalancerSourceRanges
Example:
With this example, a load balancer will be created that is only accessible to clients with IP addresses from 193.92.145.1 and 193.92.145.2.
Current Behaviour
The field loadBalancerSourceRanges is ignored.
Context
inlets-operator is great to expose some services to the public, but sometimes it could be useful to restrict access to the service based on CIDR ranges.
The text was updated successfully, but these errors were encountered: