AiHummer
Norsk▾
Logg påKonto
v1.2.x▾
v1.2.xstablev1.1.xstablev1.0.xstable
{ }Swagger
Sikkerhet/RBAC og spesifiserte API-nøkler

RBAC og spesifiserte API-nøkler

v1.2.x · oppdatert 2026-07-07

AiHummer beskytter overflaten for administrasjon med rollebasert tilgangskontroll og begrensede API-nøkler. Roller bestemmer hvem en person får lov til å være; avgrensede nøkler lar deg gi en del av automatiseringen bare de privilegiene den faktisk trenger, i stedet for en nøkkel som kan gjøre alt.

Roller

Tilgang til admin-API-et og admin-grensesnittet styres av roller. En rolle bestemmer hvilke ressursgrupper en prinsipal kan se og hvilke de kan endre.

Roller administreres på administrasjonsbrukergrensesnittene Roller side. Rett ut av boksen er det innebygde roller — owner (alt), admin, operator og member — som er bare-lese (merket med et «Innebygd»-merke; de kan ikke redigeres eller slettes). Utover disse kan du opprette tilpassede roller: rolleformen tar et navn, en beskrivelse og et tillatelsesrutenett — lese/skrive avmerkingsbokser for hver av ~19 ressursdomener (agenter, samtaler, verktøy, hemmeligheter, plugins, innstillinger, godkjenninger, API-nøkler og så videre; “skriv” innebærer automatisk “les”). Hver rolle viser hvor mange subjekter som bruker den; en rolle som er tildelt noen kan ikke slettes før tildelingene er fjernet.

Kombiner roller med de andre kontrollene på dette nettstedet — IP-tillatliste, bedrifts-SSO og den revisjonslogg — slik at hver administrativ handling både er autorisert og registrert.

Avgrensede API-nøkler

API-nøkler bærer områder som begrenser hva nøkkelen kan gjøre. De definerte omfangene er:

Omfang Tilskudd
chat Sluttbruker OpenAI-kompatibelt endepunkt (standard for eldre nøkler).
admin:read Skrivebeskyttet tilgang til administratorressurser (GET /v1/admin/*: innstillinger, samtaler, analyser, osv.).
admin:write Muterende administrasjons-API-kall (POST/PUT/DELETE /v1/admin/*).
mcp Den publiserte MCP-endepunktet (POST /v1/mcp).
a2a Den publiserte Agent-til-Agent-endepunktet (POST /a2a/message).
* Full tilgang til alt (det virkelig fullstendige tilgangsområdet).

I tillegg, en generisk <area>:* jokertegn fungerer: admin:*, for eksempel tilskudd hver admin-handling men gjør ikke tildele chat, mcp eller a2a — det er ikke et separat definert omfang, bare et tilfelle av jokertegnet. Bare * gir full tilgang til alle overflater.

Nøkler som ble utstedt før scopes eksisterte, fungerer fortsatt uten begrensninger; nye nøkler kan utstedes med et begrenset scope slik at for eksempel et dashbord som bare leser målinger aldri har en nøkkel som kan endre innstillinger.

[!TIP] Bruk minste privilegium: en overvåkings- eller rapporteringsintegrasjon bør få en admin:read nøkkel, ikke admin:write — for ikke å snakke om *. Reservere * for nøkler som virkelig trenger tilgang til alle overflater.

Å velge riktig omfang

  • Chatklienter (ringe OpenAI-kompatibelt endepunkt) → chat.
  • Skrivebeskyttede integrasjoner (dashboards, eksportører, statuskontroller) → admin:read.
  • Automatisering som oppretter eller redigerer ressurser (utrustningsagenter, importering kunnskap, håndtering av timeplaner) → admin:write.
  • MCP- og A2A-klienter → mcp og a2a henholdsvis.
  • Knuse-glass / full tilgang → *, holdt med så få taster som mulig og rotert regelmessig.

[!WARNING] En avgrenset nøkkel er fortsatt en legitimasjon for admin-API-et. Lagre den i hemmelighets hvelv eller din egen hemmelige leder, aldri i kildestyring, og roter den hvis den kan ha blitt utsatt.

Hvordan nøkler administreres

Admin API-nøkler administreres gjennom admin-API-en (/v1/admin/apikeys) og administrasjonsgrensesnittet, hvor du utsteder en nøkkel, tilordner dens omfang, og tilbakekaller den når den ikke lenger er nødvendig. Fordi administrasjons-APIet selv er beskyttet av OIDC og IP-tillatelseslisten, å prege en nøkkel er en autentisert, revidert operasjon.

Hvor til neste