Change who can reach the API

The Kubernetes API of a cluster listens on port 6443, and the cluster’s firewall in your Hetzner project decides who reaches it. This page limits it to the addresses you and your tools work from, so that the API is not open to the whole internet.

In progress: not bookable yet

Built in a lab: on 2026-10-10 the firewall the portal created on a real Hetzner project held exactly the rules below, and from outside the ports 22, 10250, 2379 and 8472 were closed. Changing the ranges on Settings after the cluster exists is In progress: built, not yet run on a real cluster. Tell me when it opens.

What the firewall lets in

Port	From	For
TCP 6443	the ranges you set (the default is everyone: 0.0.0.0/0 and ::/0)	the Kubernetes API
TCP 80 and 443	everyone	your apps, through the ingress on the node
ICMP	everyone	ping

Nothing else comes in: SSH (port 22) and the ports k3s uses inside the cluster stay closed. The firewall filters incoming traffic only; the node’s own calls out, such as pbx-agent’s to the portal, are not affected.

What you need

• To be a team admin. Members see the ranges but cannot change them.
• The addresses you work from, as IPv4 or IPv6 ranges in CIDR form, such as 203.0.113.7/32 or 2001:db8:1234::/48. Include every place kubectl runs from: your office, your CI runners, the machine your agent runs on.

Change the ranges in the portal

1. On the cluster’s page, open Settings.
2. Under Kubernetes API access, edit Who may reach the Kubernetes API (port 6443): one range per line, IPv4 or IPv6. An address without a prefix length becomes a single address (203.0.113.7 becomes 203.0.113.7/32).
3. Choose Save.

The portal changes the cluster’s firewall in your project first, with all its rules at once, and saves the ranges only when Hetzner has taken them. The page then says “Saved. The cluster’s firewall lets only these ranges reach the Kubernetes API.” If Hetzner answers with an error, the firewall and the saved ranges both stay as they were, and the page shows the error.

At least one range must be left; 0.0.0.0/0 and ::/0 together mean everyone. You set the first ranges when you create the cluster.

If you lock yourself out

The portal is not behind the cluster’s firewall. If your address changes and kubectl stops connecting, open Settings from anywhere and add the new address. Kubeconfigs are made on the node by pbx-agent, which calls out to the portal, so you can still get one; you only cannot use it from outside the ranges.

Change the firewall in the Hetzner console

The firewall is a resource in your project, named pbx-<DNS label>-<eight characters of the cluster's ID> and labelled pbx-cluster=<the cluster's ID>. You can edit its rules in the Hetzner console under Firewalls.

The portal does not read those rules back. It writes the whole rule set again whenever a team admin saves the ranges on Settings, and when a failed create is retried from its firewall step or an earlier one; a rule you added in the Hetzner console is gone after that. So:

• To change who reaches port 6443, use Settings while the portal manages the cluster.
• To open anything else, such as port 22, create a firewall of your own and apply it to the server. Hetzner applies the rules of every firewall on a server together. Get root on the server does this for SSH.

After you detach the cluster, the portal no longer changes its firewall, and the Hetzner console is the place to edit it.

Get a kubeconfigA temporary kubeconfig, made on the node and readable only by your browser.

Get root on the serverAdd an SSH key through the cluster and open port 22 with a firewall of your own.