How to set a IP restriction on NodePort range of DO managed Kubernetes?

Posted June 12, 2019 4.6k views
DebianDigitalOceanFirewallKubernetesDigitalOcean Cloud Firewalls

Hi there.

Weeks ago, I already asked a question for how to customize DO managed Kubernetes firewall on forum.

I know how to ADD new firewall rules now, but I don’t know how to customize EXISTING RULES which already added by default DO Kubernetes.

For example, DO defaultly marked that Kubernetes NodePort range (30000 ~ 32767) as a public access, which allows every IPs without any restrictions.

But I want to ONLY ALLOW my own IP to reach NodePort in this case.

Already tried to make an additional firewall with IP restriction on NodePort range, and bound it with my DOKS cluster, But didn’t work properly.

Any helpful tips for this?


These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
2 answers

With 1.19 this is finally possible!
NodePort range is now closed by default. NodePort Services will open the automatic firewall. This can be disabled via annotation, for example:

apiVersion: v1
kind: Service
  name: traefik
  namespace: default
  annotations: "false"
  type: NodePort
    - protocol: TCP
      name: web
      port: 8000
      nodePort: 30000
    app: traefik

Now using an additional custom firewall applied to the cluster, NodePort service connectivity can be properly limited.

Hi there,

Unfortunately, it is not currently possible to add further restrictions to this nodeport range. Because our cloud firewalls are whitelist based, a DENY cannot override an ALLOW. We are currently exploring ways to make the DOKS generated objects more flexible to accommodate a wider range of customer use cases.

Modifying the generated cloud firewall is also not recommended and although it will work temporarily, it will be overwritten by the cluster reconciler to the default settings.

The cloud resources(volumes/Load Balancers/Firewall) created by DOKS are not intended to be manually modified/renamed. This is because the DOKS reconciler looks to find cloud resources with the name they were created with in order to manage and validate its settings. If there are manual modifications made to a cloud resource’s settings, the reconciler will overwrite them.

A workaround to what your trying to do would be to expose an ingress-controller service to front your other services. Then you may use the whitelist annotation functionality, for example, provided by the nginx ingress controller. See the documentation here:


John Kwiatkoski
Senior Developer Support Engineer

  • Hi John,

    This is a helpful comment. There are quite a few other questions on this forum with pretty much the same theme.

    I’ve been stuck trying to figure out how to disallow direct-IP access to my nodes on port 30001-*; I think this presents a possible security risk. I’d rather only the Load Balancer have access to the nodes.

    However, your nginx ingress suggestion with the whitelist sounds promising.

    My immediate concern there is that the IP of the load balancer is not known ahead of time. So an “infra-as-code” approach is incomplete here.

    Some approaches I’ve considered:

    1. Use the health check as a way to “authorize” the load balancer.

    a. Make the load balancer’s health check use a special URL such as /health?token=SPECIALTOKENHERE.
    b. Only accept connections from the IP address that has made correct requests to the /health path.

    This would have the advantage of being “infra-as-code” deployable
    and also would adjust to changes in live changes to the load

    Actually that’s all I’ve got at the moment. I think this design space
    is unexplored because usually a firewall will solve the problem for us.