Att ge en AI-assistent åtkomst till Proxmox: var gränsen måste sitta

Det arbete en modell verkligen är bra på, att läsa långa loggar och hitta vad som gick sönder, är precis det arbete den oftast inte får göra. Skälet: dagens enda vägar räcker den root, och risken är inte ond avsikt utan saknad kontext.

AtlasPVE ·

Den här artikeln svarar på

  • proxmox mcp server
  • kan ai sköta proxmox
  • ai åtkomst till proxmox säkerhet
  • risk att ge llm serveråtkomst
  • best proxmox mcp server

Det finns här en verklig och lite irriterande snedhet. Att läsa tvåtusen loggrader och hitta raden där något gick sönder är precis vad en språkmodell är bra på. Det är samtidigt precis det arbete de flesta inte kan låta den göra, på grund av hur åtkomst ges.

Frågan är inte om en modell ska röra en server. Frågan är var gränsen sitter, och i dag sitter den oftast på fel ställe.

Varför den vanliga uppsättningen känns obekväm

Det finns två vanliga sätt att koppla en assistent till Proxmox: ge den en SSH-session, eller en API-nyckel med fulla rättigheter. Båda går ut på samma sak. Från den stunden står ingenting mellan modellen och hårdvaran, och allt skydd lever i formuleringen av en instruktion.

En instruktion är ingen gräns. Det är en begäran till ett system byggt för att vara hjälpsamt, på ett språk utan tvingande kraft.

Risken är saknad kontext, inte ond avsikt

Det är här diagnosen brukar bli fel. Felformen är sällan en modell som bestämmer sig för att skada. Det är en modell som handlar korrekt på en ofullständig bild.

En disk som ser tom ut. Modellen läser en enhet utan monterat filsystem och betraktar den som ledig. Enheten hör till en maskin som helt enkelt är avstängd.

En degraderad pool. Modellen läser det degraderade tillståndet och föreslår att bygga om samlingen. Rätt steg var att byta en disk, och ombyggnaden är hur resterande data går förlorad.

En tjänst som "inte kör". Den kör inte för att den kör enligt schema och är klar. Att starta om den är ofarligt; att stänga av den för att den "stannar hela tiden" är det inte.

I alla tre är kommandot rätt skrivet. Det som är fel är premissen, och ett korrekt kommando på fel premiss går i efterhand inte att skilja från sabotage.

Endast läsning hjälper, och är inte hela svaret

Det uppenbara svaret är läsbehörighet, och det tar verkligen bort de värsta utfallen. Två saker kvarstår.

Att läsa är inte gratis. Konfiguration, loggar och revisionsspår innehåller värdnamn, adresser, användarnamn och ibland nycklar som klistrats in där de inte skulle. En läsbehörig assistent med full läsomfattning är en export av din infrastruktur.

Diagnos utan handling stannar halvvägs. Om det nyttiga svaret är "starta om den här enda tjänsten" lämnar en läsbehörig uppsättning fyndet tillbaka till en människa att skriva om. Det är okej, och det är också därför rättigheter senare tyst vidgas.

Endast läsning är alltså en bra början och ett dåligt slutmål. Slutmålet är smal skrivbehörighet, genom samma portar som en människa passerar.

Var gränsen faktiskt hör hemma

Inte i instruktionen och inte i modellen. I lagret som utför, för det är den enda plats som kan neka.

Tre egenskaper gör ett sådant lager pålitligt, och alla tre går att kontrollera i stället för att lovas.

Rättigheter kommer från systemet som redan har dem. Ansluter assistenten med ett befintligt konto är det kontot får röra exakt det assistenten får röra. Ingen andra rättighetsmodell uppfinns, alltså finns inget att hålla i synk och inget sätt för de två att motsäga varandra.

Förstörande operationer passerar samma port som en människa. Om det att radera en disk frågar en människa om bekräftelse måste det fråga också när en modell begär det. En väg som är säker för människor och öppen för automatik är ingen gräns, det är en genväg med ett fint namn.

Varje steg hamnar i revisionsloggen. Vem, vad, när, på vad och med vilket resultat. Utan det har den verkliga frågan efter en incident, "gjorde assistenten det här", inget svar, och frånvaron av svar är i sig ett skäl att inte ge åtkomst.

Frågan att ställa om varje sådant verktyg

Inte "är det säkert" utan "vad är det som nekar, och var bor det?"

Är svaret "modellen har blivit tillsagd att låta bli" finns ingen gräns. Är svaret "lagret som utför kontrollerar kontots rättigheter och släpper förstörande steg genom en port" finns det en, och du kan testa den: anslut med ett begränsat konto och bekräfta att nekandet är på riktigt.

Vad Atlas gör

⚠️ Det här lagret är planerat, inte levererat. Det som följer är designen det byggs mot, nedskriven här därför att frågan ovan förtjänar ett ärligt svar och inte ett reklamsvar.

Avsikten är att assistenten kopplas till Atlas och inte till Proxmox. Proxmox ligger under och modellen når det aldrig direkt; den kan bara använda det Atlas själv kan, vilket lämnar varje befintlig port kvar i vägen.

Gränsen dras av Proxmox rättigheter, alltså den första egenskapen ovan: det anslutande kontot får röra är allt assistenten rör, och inget nytt rättighetsbegrepp dyker upp. Förstörande operationer behåller den bekräftelse de redan har, och revisionsloggen antecknar redan vem, vad, när, på vad och med vilket resultat för varje privilegierad åtgärd, nekade inräknade.

Den är också tänkt som en fristående komponent i stället för en del av installationen: på en maskin som inte vill ha den finns den aldrig. Det spelar roll av samma skäl som resten av den här artikeln. Den säkraste gränsen för en förmåga du inte har valt är dess frånvaro.

Källor

Proxmox egen dokumentation. På engelska, och den har sista ordet i den här frågan.

Relaterade artiklar

Hur ser det här ut inne i Atlas?

Gå till produktsidan