By skythet
I’ve configured next network policy in my namespace:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: np-testing-allow
namespace: testing
spec:
podSelector: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
purpose: monitoring
- namespaceSelector:
matchLabels:
purpose: ci
- namespaceSelector:
matchLabels:
environmentName: testing
But after that managed load balancer for nginx-ingress is down. How I can whitelist managed load balancer in network policy?
I’ve already tried to whitelist VPC CIDR and load balancer public IP and it didn’t help
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Hi there,
I might be missing something, but based on how DOKS load balancers work, there isn’t really a way to whitelist the managed load balancer itself in a NetworkPolicy. The load balancer is created by the Cloud Controller Manager, but traffic is still forwarded to worker nodes and then to pods.
From a NetworkPolicy point of view, incoming traffic appears to come from node IPs or from the ingress controller pods, not from the load balancer’s public IP or a specific LB resource. That’s why whitelisting the LB IP or the VPC CIDR doesn’t help.
What usually works is either allowing ingress from the namespace where your ingress controller runs, or allowing traffic from the node subnet using an ipBlock. The ingress-nginx example in the DOKS docs follows this same model, where traffic is intentionally routed only to nodes running ingress pods.
So while I can’t say this is the only solution, it does seem like the expected behavior with DOKS and NetworkPolicy.
https://docs.digitalocean.com/products/kubernetes/how-to/configure-load-balancers/
Heya, @skythet
Your NetworkPolicy is selecting every pod in testing (podSelector: {}) and then only allowing ingress from namespaces with those three labels. That also blocks traffic coming from your nginx-ingress controller (it runs in a different namespace), so the Load Balancer can still hit the ingress controller, but the ingress controller can’t reach your testing pods → everything looks “down”.
Fix is to allow ingress from the namespace where your ingress controller lives (often ingress-nginx) and/or from the ingress controller pods.
Example (add one more from: entry):
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: np-testing-allow
namespace: testing
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
purpose: monitoring
- namespaceSelector:
matchLabels:
purpose: ci
- namespaceSelector:
matchLabels:
environmentName: testing
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: ingress-nginx
If your ingress controller namespace is different, swap ingress-nginx for the real namespace name. If you want to be tighter, you can also add a podSelector to only allow the ingress controller pods (by their labels) instead of the whole namespace.
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
Full documentation for every DigitalOcean product.
The Wave has everything you need to know about building a business, from raising funding to marketing your product.
Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter.
New accounts only. By submitting your email you agree to our Privacy Policy
Scale up as you grow — whether you're running one virtual machine or ten thousand.
Sign up and get $200 in credit for your first 60 days with DigitalOcean.*
*This promotional offer applies to new accounts only.