Wybór źródła tożsamości przy dodawaniu użytkownika: istnieje na serwerze czy tylko w panelu

Proxmox zna dwa rodzaje użytkowników: konta systemowe naprawdę istniejące na serwerze i konta istniejące wyłącznie wewnątrz Proxmoksa. Zły wybór albo blokuje logowanie, albo otwiera więcej drzwi, niż trzeba.

AtlasPVE ·

Ten wpis odpowiada na

  • proxmox dodać użytkownika
  • proxmox pam a pve realm
  • proxmox użytkownik nie może się zalogować
  • proxmox użytkownik inny niż root
  • proxmox realm co to jest

Przyrostek na końcu nazwy użytkownika nie jest ozdobą. Mówi, gdzie mieszka konto, a tego wyboru nie da się później przenieść.

Dwa rodzaje użytkowników

Pierwszy rodzaj naprawdę istnieje na serwerze. To użytkownicy samej maszyny, a ich hasło jest hasłem maszyny. Konto root, którym logujesz się na początku, jest tego rodzaju.

Drugi rodzaj istnieje wyłącznie wewnątrz Proxmoksa. Nie ma odpowiednika na maszynie: żadnej powłoki, żadnego zdalnego logowania, żadnego miejsca w systemie. Brzmi to niekompletnie, ale to dokładnie to, czego chcesz. Pozwolenie komuś na korzystanie z panelu nie wymaga otwierania mu serwera.

Pierwszy klasyczny błąd

Użytkownik zostaje utworzony na serwerze, a potem panel go nie wpuszcza. Samo utworzenie konta systemowego nie nadaje w panelu niczego, bo tożsamość i uprawnienie to osobne prace. Konto jest rozpoznane, ale nigdy nie powiedziano, co mu wolno widzieć. To bliźniak problemu, w którym uprawnienie zostaje nadane, a mimo to nic się nie pojawia.

Drugi klasyczny błąd

Użytkownik zostaje utworzony w panelu, a potem ktoś próbuje połączyć się nim z serwerem. Nie zadziała i dobrze, że nie zadziała. Konto istniejące wyłącznie w panelu istnieje właśnie po to: jego zasięg kończy się na ekranie.

Który wybrać

Jeśli osoba nie musi dotykać samego serwera, wybierz rodzaj istniejący wyłącznie w panelu. Otwiera się mniej drzwi, a w dniu, w którym trzeba je zamknąć, zamykają się w jednym miejscu. Jeśli ktoś naprawdę będzie wykonywał pracę na serwerze, i tak potrzebuje konta systemowego, ale nie podejmuj tej decyzji z powodu wymogu panelu.

Wyłączanie zamiast kasowania

Konto można wyłączyć bez kasowania, a kontu można nadać datę końca. Skasowanie zabiera historię razem z zapisem: pytanie, komu co nadano, zostaje bez odpowiedzi. Dla osoby, która odeszła, wyłączenie jest zwykle właściwszą odpowiedzią niż skasowanie.

Nadawaj grupie, a nie osobie

Nadanie wprost osobie jest szybkie pierwszego dnia, przy drugiej osobie zaczyna pracę od nowa, a przy trzeciej robi się mętne, kto co ma i dlaczego. Nadanie grupie i włożenie do niej osoby zostawia dla każdej kolejnej osoby sekundy pracy i nie gromadzi za tobą rozproszonych wpisów.

Drugi składnik

Samo hasło to jedne drzwi. Jeśli panel jest osiągalny z zewnątrz albo jeśli konto niesie uprawnienia, włącz drugi składnik. Dla automatyzacji lepiej wygenerować osobny klucz niż dzielić hasło, a to jest osobny temat.

Co robi Atlas

Atlas pokazuje dostęp jako łańcuch, a nie listę: serwer, zakres, źródło tożsamości, użytkownik, grupa, rola i ścieżka siedzą połączone na jednej mapie. Na pytanie, przez które drzwi ta osoba wchodzi i dokąd sięga, odpowiada się więc przez spojrzenie, a nie przez składanie wpisów w głowie. Hasło, drugi składnik i klucze automatyzacji zarządzane są per konto, a ponieważ Atlas nie buduje własnego systemu ról, uprawnienia widoczne na ekranie są tymi samymi co na serwerze.

Ź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