BusDK Update

Bus auth -token löytyy nyt API-asiakkaille

bus-auth token osaa pyytää hyväksytylle käyttäjälle scoped Bus API -tokenin ja tallentaa sen käyttäjän Bus config rootiin. bus events, bus vm, bus containers ja aggregate bus status löytävät saman tokenin oletuksena.

Muutos tekee API-käytöstä paikallisen auth-virran osan: auth-palvelu myöntää tokenin, CLI tallentaa sen user-level configiin, ja domain-asiakkaat käyttävät normaalia Bus API JWT:tä ilman repositoryn .bus/-hakemistoon sidottuja oletuksia.

26.4.2026bus-authBus APItokens

Tiiviisti

TL;DR

bus-auth token --scope lähettää pyydetyn domain-scope-joukon auth-palvelulle, esimerkiksi vm:read container:run.
Kun token-komento käyttää --token-file-auth-sessiota, palautettu normaali Bus API JWT tallentuu auth/api-token-polkuun Bus config rootin alle.
bus events, bus vm, bus containers ja bus status vm/containers hyväksyvät BUS_API_TOKEN-ympäristömuuttujan ja viimeisenä käyttäjän auth/api-token-tiedoston.
Providerien ja integraatiotyöntekijöiden Events API -yhteydet käyttävät nyt nimeä --api-token / BUS_API_TOKEN, koska token on normaali Bus API JWT.
CLI:t eivät lue repository-local .bus/auth/api-token -tiedostoa automaattisesti.

Auth-virta alkaa edelleen auth-palvelun sessiotokenista. Sen jälkeen token-komento voi pyytää rajatumman Bus API JWT:n:

$ bus-auth --api-url http://127.0.0.1:8080 \
  --token-file ~/.config/bus/auth/token \
  token --scope "vm:read container:run"

Komento tulostaa providerin vastauksen stdoutiin kuten ennenkin. Kun --token-file on käytössä, sama API-token kirjoitetaan myös käyttäjän Bus auth -tilaan:

~/.config/bus/auth/api-token

Polun juuri voi olla myös BUS_CONFIG_DIR. Tämä pitää auth-palvelun sessiotokenin ja normaalin Bus API JWT:n erillään: sessiotoken todistaa käyttäjän auth-palvelulle, API-token menee Bus API -pintoihin kuten Events APIin.

bus-events käyttää lookup-järjestystä, jossa eksplisiittinen credential voittaa aina paikallisen session:

--api-token / --token
--token-file
BUS_API_TOKEN
BUS_CONFIG_DIR/auth/api-token
~/.config/bus/auth/api-token

Käytännössä eventin voi lähettää paikallisen auth-tilan jälkeen ilman token-lipun toistoa:

$ bus-events send --name example.ping --payload '{"ok":true}'

{
  "accepted": true,
  "name": "example.ping"
}

Sama lookup-polku on nyt myös AI Platformin domain-asiakkailla. bus vm status, bus containers status, bus containers run ja aggregate-komennot bus status vm sekä bus status containers toimivat ilman token-lippua, kun auth/api-token sisältää sopivilla scopeilla myönnetyn tokenin:

$ bus vm status
$ bus containers run --profile codex -- sh -c 'printf OK'
$ bus status containers --format json

Palvelin- ja worker-prosessien Events API -yhteyksissä sama nimeäminen näkyy nyt --api-token-lippuna ja BUS_API_TOKEN-ympäristömuuttujana. bus-api-provider-vm, bus-integration-upcloud, bus-integration-ssh-runner ja bus-integration-usage eivät enää dokumentoi Events-yhteyden credentialia nimellä --events-token. Nimi kertoo paremmin, että tokenilla on audience ai.hg.fi/api ja domain-scopet kuten vm:write, container:run, ssh:run tai usage:read.

Eksplisiittinen credential voittaa edelleen paikallisen session. CI-ajossa tai palvelussa voi käyttää --api-token, --token, --token-file, BUS_API_TOKEN tai vanhaa AI Platform -nimeä BUS_AI_TOKEN, jos komento sitä tukee. Lue lisää bus-auth-dokumentaatiosta, bus-events-dokumentaatiosta, bus-vm-dokumentaatiosta, bus-containers-dokumentaatiosta ja bus-status-dokumentaatiosta.