De Hetzner-token

Een Hetzner-Cloud-API-token koppelen is optioneel. Je hebt er nooit een nodig om in te loggen, het dashboard te bekijken, lijstprijzen te zien of een gehost cluster met alleen een control plane te draaien. Een token zet twee dingen aan: de exacte prijzen van jouw account en provisioning (worker pools en SSH-keys op je eigen Hetzner-account).

Zonder token

Je ziet toch alles, tegen lijstprijzen. Het dashboard toont Hetzner-locaties, machinetypes en prijzen, geserveerd via kubehz' eigen platformtoken. Omdat jouw Hetzner-account andere (bijvoorbeeld onderhandelde) prijzen kan hebben, zijn dit Hetzners lijstprijzen — gemarkeerd met een sterretje (*) zodat duidelijk is: een schatting, niet je rekening.

Je kunt een gehost cluster aanmaken. Een cluster met alleen een control plane heeft geen token nodig — kubehz draait de control plane op eigen infrastructuur. Een token heb je pas nodig als je workers op je account wilt toevoegen.

Met een token

Koppel een token in de aanmaakwizard of later op de clusterpagina. Welk token je gebruikt, bepaalt wat er wordt ontgrendeld:

Een Read & Write-token ontgrendelt provisioning. Het dashboard schakelt van lijstprijzen over naar de exacte prijzen van jouw account, en je kunt worker pools aanmaken en schalen (kubehz maakt de servers aan op je account — je betaalt rechtstreeks aan Hetzner, zonder kubehz-opslag) en de SSH-keys voor worker nodes beheren.

Een alleen-lezen token geeft nog steeds de exacte prijzen van je account. Het authenticeert, dus de prijzen worden de echte cijfers van je account — maar provisioning blijft vergrendeld, en het dashboard zegt dat. Om te provisionen, vervang hem door een Read & Write-token.

De token aanmaken

Kies in de Hetzner Cloud Console het project waarin je workers moeten komen, en dan Security → API tokens → Generate API token. Kies Read & Write als je wilt provisionen; Read volstaat voor alleen prijzen.

Hoe hij bij het koppelen wordt gevalideerd

Wanneer je een token koppelt of vervangt, controleert kubehz hem voordat hij wordt opgeslagen:

• Hij moet authenticeren — een token dat Hetzner weigert, wordt meteen afgewezen.
• Het moet het juiste project zijn — bij een cluster dat al servers heeft, bevestigt kubehz dat de token bij hetzelfde Hetzner-project hoort als die workers. Een token uit een ander project wordt afgewezen zodat je bestaande nodes niet gestrand raken. (Een hcloud-token hoort bij precies één project. Waar de controle niet kan draaien — nog geen geprovisionede servers, of Hetzner onbereikbaar — is hij soepel en slaat de token op.)

Hoe hij wordt opgeslagen

Versleuteld opgeslagen, nooit teruggegeven. De token wordt versleuteld voordat hij onze database raakt en wordt alleen gebruikt om de resources van je eigen cluster te beheren. Het dashboard toont de waarde nooit meer — alleen of er een token is gekoppeld en sinds wanneer. Je kunt hem op elk moment vervangen; een token koppelen of vervangen vereist verse 2FA. Trek hem in via de Hetzner Cloud Console wanneer je maar wilt.

Met de lo-CLI

Als je provisioning vanuit lok8s aanstuurt, claimt lo provision met een KUBEHZ_TOKEN (een clusters:write-API-token, aangemaakt in het dashboard onder Access → API Tokens) het cluster direct voor je tenant. Om kubehz ook je HCLOUD_TOKEN voor provisioning vanuit het dashboard te geven, kies je er expliciet voor:

# cluster.lok8s.yaml
spec:
  kubehz:
    hosting: hosted
    connectHcloudToken: true   # stuur HCLOUD_TOKEN naar kubehz voor provisioning

Dit is opt-in. Zonder connectHcloudToken: true wordt je HCLOUD_TOKENalleen lokaal door lo gebruikt en nooit naar kubehz gestuurd — en zonder een KUBEHZ_TOKEN wordt er helemaal niets naar kubehz gestuurd.

Volgende stappen

• Gehoste control plane — de plannen en het gehoste pad in het algemeen.
• Worker pools — pools, schalen en autoscaling (vereist een Read & Write-token).
• Hoe het werkt — de vertrouwensgrens die de token delegeert.

---

Documentatiestatus

Aspect	Detail
Status	live — optionele token; Read & Write ontgrendelt provisioning
Laatst herzien	2026-07-16