Å gi en KI-assistent tilgang til Proxmox: hvor grensen må ligge

Arbeidet en modell virkelig er god til, å lese lange logger og finne hva som gikk i stykker, er nettopp det arbeidet den som regel ikke får gjøre. Grunnen: dagens eneste veier gir den root, og risikoen er ikke vond vilje, men manglende kontekst.

AtlasPVE ·

Denne artikkelen svarer på

  • proxmox mcp server
  • kan ki styre proxmox
  • ki tilgang til proxmox sikkerhet
  • risiko ved å gi llm servertilgang
  • best proxmox mcp server

Det finnes en ekte og litt irriterende skjevhet her. Å lese to tusen loggelinjer og finne linjen der noe gikk i stykker, er akkurat det en språkmodell er god til. Det er samtidig akkurat det arbeidet de fleste ikke kan la den gjøre, på grunn av måten tilgang gis på.

Spørsmålet er ikke om en modell skal røre en tjener. Det er hvor grensen ligger, og i dag ligger den som regel på feil sted.

Hvorfor det vanlige oppsettet er ubehagelig

Det finnes to vanlige måter å koble en assistent til Proxmox på: gi den en SSH-økt, eller en API-nøkkel med fulle rettigheter. Begge kommer ut på det samme. Fra det øyeblikket står ingenting mellom modellen og maskinvaren, og all beskyttelse lever i ordlyden til en instruksjon.

En instruksjon er ingen grense. Det er en forespørsel til et system som er bygget for å være hjelpsomt, på et språk uten tvangskraft.

Risikoen er manglende kontekst, ikke vond vilje

Det er her diagnosen blir feil. Feilformen er sjelden en modell som bestemmer seg for å gjøre skade. Det er en modell som handler riktig på et ufullstendig bilde.

En disk som ser tom ut. Modellen leser en enhet uten montert filsystem og regner den som ledig. Enheten hører til en maskin som rett og slett er slått av.

En degradert pool. Modellen leser den degraderte tilstanden og foreslår å bygge samlingen opp igjen. Riktig steg var å bytte én disk, og gjenoppbyggingen er måten de gjenværende dataene går tapt på.

En tjeneste som "ikke kjører". Den kjører ikke fordi den kjører etter plan og er ferdig. Å starte den på nytt er ufarlig; å slå den av fordi den "stopper hele tiden", er det ikke.

I alle tre er kommandoen riktig skrevet. Det som er galt, er premisset, og en riktig kommando på et galt premiss lar seg i ettertid ikke skille fra sabotasje.

Bare lesing hjelper, og er ikke hele svaret

Det åpenbare svaret er lesetilgang, og det fjerner virkelig de verste utfallene. To ting gjenstår.

Å lese er ikke gratis. Konfigurasjon, logger og revisjonsspor inneholder vertsnavn, adresser, brukernavn og av og til nøkler limt inn der de ikke skulle. En assistent med full leseomfang er en eksport av infrastrukturen din.

Diagnose uten handling stopper halvveis. Er det nyttige svaret "start denne ene tjenesten på nytt", gir et leseoppsett funnet tilbake til et menneske for å skrives om. Det er greit, og det er også derfor rettigheter senere utvides i stillhet.

Bare lesing er altså en god start og et dårlig mål. Målet er smal skrivetilgang, gjennom de samme portene et menneske passerer.

Hvor grensen faktisk hører hjemme

Ikke i instruksjonen og ikke i modellen. I laget som utfører, for det er det eneste stedet som kan nekte.

Tre egenskaper gjør et slikt lag pålitelig, og alle tre lar seg kontrollere i stedet for å loves.

Rettigheter kommer fra systemet som allerede har dem. Kobler assistenten seg til med en eksisterende konto, er det den kontoen får røre nøyaktig det assistenten får røre. Ingen andre rettighetsmodell finnes opp, så det finnes ingenting å holde i synk og ingen måte for de to å motsi hverandre på.

Ødeleggende operasjoner passerer samme port som et menneske. Om det å slette en disk spør et menneske om bekreftelse, må det spørre også når en modell ber om det. En vei som er trygg for mennesker og åpen for automatikk, er ingen grense, det er en snarvei med et pent navn.

Hvert steg havner i revisjonsloggen. Hvem, hva, når, på hva og med hvilket resultat. Uten det har det egentlige spørsmålet etter en hendelse, "var det assistenten som gjorde dette", ikke noe svar, og fraværet av svar er i seg selv en grunn til å ikke gi tilgang.

Spørsmålet man bør stille om et slikt verktøy

Ikke "er det trygt", men "hva er det som nekter, og hvor bor det?"

Er svaret "modellen har fått beskjed om å la være", finnes ingen grense. Er svaret "laget som utfører sjekker kontoens rettigheter og slipper ødeleggende steg gjennom en port", finnes det en, og du kan teste den: koble til med en begrenset konto og bekreft at nektelsen er ekte.

Hva Atlas gjør

⚠️ Dette laget er planlagt, ikke levert. Det som følger, er designet det bygges mot, skrevet ned her fordi spørsmålet over fortjener et ærlig svar og ikke et reklamesvar.

Hensikten er at assistenten kobles til Atlas og ikke til Proxmox. Proxmox ligger under, og modellen når det aldri direkte; den kan bare bruke det Atlas selv kan, slik at hver eksisterende port blir stående i veien.

Grensen trekkes av Proxmox' rettigheter, altså den første egenskapen over: det den tilkoblede kontoen får røre, er alt assistenten rører, og det dukker ikke opp noe nytt rettighetsbegrep. Ødeleggende operasjoner beholder bekreftelsen de allerede har, og revisjonsloggen noterer allerede hvem, hva, når, på hva og med hvilket resultat for hver privilegert handling, avviste inkludert.

Den er også tenkt som en egen komponent i stedet for en del av installasjonen: på en maskin som ikke vil ha den, er den aldri til stede. Det betyr noe av samme grunn som resten av denne artikkelen. Den tryggeste grensen for en evne du ikke har valgt, er fraværet av den.

Kilder

Proxmox sin egen dokumentasjon. På engelsk, og den har siste ord i denne saken.

Relaterte artikler

Hvordan ser dette ut inne i Atlas?

Gå til produktsiden