Dać asystentowi AI dostęp do Proxmoksa: gdzie musi leżeć granica

Praca, którą model robi naprawdę dobrze, czytanie długich dzienników i znajdowanie miejsca awarii, to dokładnie ta praca, której zwykle nie wolno mu wykonać. Powód: dzisiejsze jedyne drogi wręczają mu roota, a ryzyko to nie zła wola, tylko brakujący kontekst.

AtlasPVE ·

Ten wpis odpowiada na

  • proxmox mcp server
  • czy ai może zarządzać proxmoksem
  • dostęp ai do proxmoksa bezpieczeństwo
  • ryzyko dania llm dostępu do serwera
  • best proxmox mcp server

Jest tu prawdziwa i lekko irytująca asymetria. Przeczytać dwa tysiące linii dziennika i znaleźć linię, w której coś się zepsuło, to dokładnie to, w czym model językowy jest dobry. To zarazem dokładnie ta praca, której większość ludzi nie może mu powierzyć, z powodu sposobu, w jaki przyznaje się dostęp.

Pytanie nie brzmi, czy model ma dotykać serwera. Brzmi: gdzie leży granica, a dziś zwykle leży w złym miejscu.

Dlaczego zwykły układ jest niewygodny

Są dwa popularne sposoby podłączenia asystenta do Proxmoksa: dać mu sesję SSH albo token API z pełnymi uprawnieniami. Oba wychodzą na to samo. Od tej chwili między modelem a sprzętem nie stoi nic, a cała ochrona żyje w brzmieniu instrukcji.

Instrukcja nie jest granicą. To prośba skierowana do systemu zaprojektowanego, by być pomocnym, w języku bez mocy egzekucyjnej.

Ryzykiem jest brakujący kontekst, a nie zła wola

To właśnie tutaj diagnoza bywa błędna. Forma awarii rzadko polega na tym, że model postanawia zaszkodzić. Polega na tym, że model działa poprawnie na niepełnym obrazie.

Dysk, który wygląda na pusty. Model czyta urządzenie bez zamontowanego systemu plików i uznaje je za wolne. Urządzenie należy do maszyny, która jest po prostu wyłączona.

Zdegradowana pula. Model czyta stan degradacji i proponuje przebudowę macierzy. Właściwym krokiem była wymiana jednego dysku, a przebudowa to sposób, w jaki traci się resztę danych.

Usługa, która "nie działa". Nie działa, bo działa według harmonogramu i skończyła. Zrestartowanie jest nieszkodliwe; wyłączenie, bo "ciągle się zatrzymuje", już nie.

We wszystkich trzech polecenie jest napisane poprawnie. Błędna jest przesłanka, a poprawne polecenie na błędnej przesłance po fakcie nie różni się od sabotażu.

Tylko odczyt pomaga i nie jest całą odpowiedzią

Oczywistą odpowiedzią jest dostęp tylko do odczytu i naprawdę usuwa najgorsze zakończenia. Zostają dwie rzeczy.

Czytanie nie jest za darmo. Konfiguracja, dzienniki i ślady audytu zawierają nazwy hostów, adresy, nazwy użytkowników, a czasem tokeny wklejone tam, gdzie nie powinny. Asystent z pełnym zakresem odczytu to eksport twojej infrastruktury.

Diagnoza bez działania zatrzymuje się w połowie. Jeśli użyteczną odpowiedzią jest "zrestartuj tę jedną usługę", układ tylko do odczytu oddaje ustalenie człowiekowi do przepisania. To w porządku i to również powód, dla którego uprawnienia bywają później po cichu poszerzane.

Zatem tylko odczyt to dobry początek i zły cel. Celem jest wąski dostęp do zapisu, przechodzący przez te same bramy co człowiek.

Gdzie granica naprawdę należy

Nie do instrukcji i nie do modelu. Do warstwy, która wykonuje, bo to jedyne miejsce zdolne odmówić.

Trzy właściwości czynią taką warstwę godną zaufania i wszystkie trzy da się sprawdzić, a nie tylko obiecać.

Uprawnienia pochodzą z systemu, który już je ma. Jeśli asystent łączy się istniejącym kontem, to czego wolno dotknąć temu kontu, jest dokładnie tym, czego wolno dotknąć asystentowi. Nie wymyśla się drugiego modelu uprawnień, więc nie ma czego synchronizować ani jak tym dwóm sobie przeczyć.

Operacje niszczące przechodzą tę samą bramę co człowiek. Jeśli usunięcie dysku pyta człowieka o potwierdzenie, musi pytać też wtedy, gdy prosi o to model. Ścieżka bezpieczna dla ludzi i otwarta dla automatyki nie jest granicą, tylko skrótem z ładną nazwą.

Każdy krok trafia do dziennika audytu. Kto, co, kiedy, na czym i z jakim wynikiem. Bez tego prawdziwe pytanie po incydencie, "czy zrobił to asystent", nie ma odpowiedzi, a brak odpowiedzi sam w sobie jest powodem, by nie dawać dostępu.

Pytanie, które warto zadać o każde takie narzędzie

Nie "czy to bezpieczne", tylko "co odmawia i gdzie to mieszka?"

Jeśli odpowiedź brzmi "modelowi powiedziano, żeby tego nie robił", granicy nie ma. Jeśli brzmi "warstwa wykonawcza sprawdza uprawnienia konta i przepuszcza kroki niszczące przez bramę", granica jest i da się ją przetestować: połącz się ograniczonym kontem i potwierdź, że odmowa jest prawdziwa.

Co robi Atlas

⚠️ Ta warstwa jest zaplanowana, a nie wydana. To, co następuje, jest projektem, ku któremu jest budowana, zapisanym tutaj, bo powyższe pytanie zasługuje na uczciwą odpowiedź, a nie reklamową.

Zamiarem jest, by asystent podłączał się do Atlasa, a nie do Proxmoksa. Proxmox leży pod spodem i model nigdy nie sięga do niego bezpośrednio; może użyć tylko tego, co potrafi sam Atlas, więc każda istniejąca brama zostaje na drodze.

Granicę wyznaczają uprawnienia Proxmoksa, czyli pierwsza właściwość powyżej: czego może dotknąć podłączone konto, tego i tylko tego dotyka asystent, i nie pojawia się żadne nowe pojęcie uprawnień. Operacje niszczące zachowują potwierdzenie, które już mają, a dziennik audytu już zapisuje kto, co, kiedy, na czym i z jakim wynikiem dla każdej uprzywilejowanej akcji, łącznie z odrzuconymi.

Jest też pomyślana jako osobny komponent, a nie część instalacji: na maszynie, która jej nie chce, nigdy jej nie ma. To ma znaczenie z tego samego powodu co reszta tego tekstu. Najbezpieczniejszą granicą dla możliwości, której nie wybrałeś, jest jej brak.

Źródła

Własna dokumentacja Proxmoksa. Po angielsku i to ona ma ostatnie słowo w tej sprawie.

Powiązane wpisy

Jak to wygląda wewnątrz Atlasa?

Przejdź do strony produktu