Skip to main content

Grant Syself bare-metal access

Inspect 1.36

When support needs to look at a bare-metal server directly, you give them temporary access through Hetzner Robot and take it back when they finish. The access is scoped to one server and you control when it ends.

First, pick your mechanism#

There are two ways to stop the automation from acting on a host, and they do different things. Pick the one that matches the work.

Mechanism What it does Use it when
maintenanceMode: true (field on HetznerBareMetalHost) Deprovisions the host: it leaves the cluster, its workloads reschedule, and it is not picked for any new machine. You are handing the physical server over for hardware or boot-level work and it is fine for the node to leave the cluster.
cluster.x-k8s.io/paused (annotation) Freezes reconciliation on the object. The controllers stop touching it and leave everything exactly as it is. Nothing is deprovisioned and no workloads move. You want the automation to stop acting while support looks, but you do not want the node removed or its pods rescheduled.

For how to apply the pause annotation and resume it, see . Pausing does not open any access by itself: to let support reach the server, you still create and share the temporary Robot login below.

The rest of this guide uses maintenanceMode, the right choice when the fix needs work on the hardware itself.

Step 1: Put the server into maintenanceMode#

maintenanceMode stops the automation from managing the server, so it does not fight support while they work on it.

Edit the HetznerBareMetalHost resource for the server and set:

yaml
		spec:
  maintenanceMode: true
Warning

While maintenanceMode is on, the server is removed from the cluster and its workloads reschedule to other nodes. Confirm the remaining nodes have enough capacity before you continue, or the rescheduled pods stay pending.

Step 2: Create a temporary Hetzner Robot admin login#

Log in to Hetzner Robot⁠ and select the server you want to share.

Open the Admin Login section and generate a temporary password for the server. Open the Admin Login section again, and Robot shows a generated login username:

text
		Login #2928603+MzQDe

This username belongs to this one access grant. Support uses it to log in to the Robot UI and reach the server.

Step 3: Share the login safely#

Send support the server ID (visible in the Hetzner Robot server list), the temporary Robot login username, and the temporary password.

Send them through your agreed support channel, the same email or shared Slack channel you use for a case, not a public issue tracker or a shared document. The login only works while the temporary password stands, so you invalidate it in Step 5.

What support can and cannot do#

With the temporary admin login, support reaches this one server through Hetzner Robot to investigate the hardware and the boot state directly. They cannot reach it through the cluster while it is in maintenanceMode, because it has been removed from the cluster and its workloads have moved. The access ends the moment you revoke the login and clear maintenanceMode.

Step 4: Revoke the login when support is done#

After support finishes, remove the temporary admin login from Hetzner Robot, or rotate the password to invalidate it. This cuts off the access first, before the server rejoins.

Step 5: Clear maintenanceMode#

Set maintenanceMode back to false in the HetznerBareMetalHost spec:

yaml
		spec:
  maintenanceMode: false

Automated management resumes and the server rejoins the cluster.

Step 6: Confirm the server rejoins#

Watch the HetznerBareMetalHost and the node come back:

		$ kubectl get hetznerbaremetalhost -n <namespace>
$ kubectl get nodes

The node returns to Ready once the automation has taken the server back and the kubelet reports in.

Least privilege and audit#

Grant the login only for the length of the investigation, and revoke it as soon as support is done rather than leaving it open. The grant is scoped to the single server you selected in Robot, so it never reaches the rest of the fleet. Any SSH session on the node itself leaves an trail; access at the Hetzner Robot level is recorded by Hetzner, not by the cluster.

For the wider model of what Syself can and cannot reach in your cluster, see .

Related#

Collect logs with the log collector

Run the built-in syself-log-collector on a Syself Autopilot node, then get the bundle off it over SSH with scp, or with kubectl alone when you have no SSH access, so support can investigate a node-level problem.

FAQ

Answers to the most common questions about Syself Autopilot: what it is, how billing works, and how upgrades work.