Konsolenberechtigung für zusätzl. Benutzer?

[floh8]

Bezügliche meines Posts https://forum.proxmox.com/threads/proxmox-backup-server-realm-sinn.125578/post-547824 habe ich mal einen zusätzlichen Benutzer "honk" angelegt. Wenn ich jetzt den Benutzer einlogge unter ssh oder GUI-Console dann bekomme ich nur ein "$" als Prompt und keine Befehle funktionieren. Erst wenn ich die Shell auf /bin/bash umstelle , bekomme ich den gewohnten Prompt. Trotzdem kann ich keine Proxmoxbefehle ausführen.
Wenn ich z.B. folgenden Befehl ausführe, kommt:

honk@pve1:~$ /sbin/ha-manager crm-command node-maintenance enable pve1
ipcc_send_rec[1] failed: Is a directory
ipcc_send_rec[2] failed: Is a directory
ipcc_send_rec[3] failed: Is a directory
Unable to load access control list: Is a directory

Welche Berechtigung muss denn der Benutzer haben, um Proxmox von der Konsole aus mit seinen Proxmoxberechtigungen zu administrieren?

 

[nunner]

Hi,

die CLI Tools benötigen alle root-Berechtigungen (da sie teils sehr direkt mit dem Backend interagieren). Mit sudo sollte es funktionieren, aber ich weiß nicht, ob das in deinem Fall gewollt ist.

 

[floh8]

Das ist natürlich unschön. Mit sudo müßte ich also einer Gruppe alle PRoxmox Tools zuweisen. Und dann auf alle Hosts verteilen.
Aufwendig.

 

[Falk R.]

Die Zusätzlichen User sind ja auch nur für die GUI gedacht, auf CLI arbeitet man ja in der Regel mit root.

 

[floh8]

In großen Umgebungen macht es durch aus Sinn, Aufgabe zu verteilen und da will ich nicht irgendeinem key user root-Rechte geben. Ich denke, da vor allem an den Anwendungsfall, wenn ich eine Entwicklungsabteilung habe. Die bevorzugen es natürlich oft mit der Kommandozeile zu arbeiten, um vielleicht auch Scripte zu nutzen. Es wäre schon schön, wenn sich die Benutzerberechtigung auch auf die Kommandozeile auswirken würde. Sicherlich nicht einfach umzusetzen in einem Cluster.

 

[fabian]

bis auf wenige ausnahmen ("ha-manager crm-command" ist leider eine solche ) sind die CLI tools nur wrapper um die API -> wenn hier gewuenscht ist, mit weniger privilegien zu arbeiten empfiehlt es sich direkt die API als entsprechender user zu verwenden (und da wo dinge nicht auf der API sind, entsprechend requests aufzumachen die dieses feature auf API ebene exposen - das ist aber wie gesagt die ausnahme, *alles* was auf der GUI konfigurierbar/machbar ist verwendet die API, und noch einiges mehr ist dort verfuegbar aber nicht auf der GUI exposed).

die CLI tools laden direkt die perl module, und diese erwarten entweder als root (pvedaemon oder CLI) oder als www-data (pveproxy) zu laufen. hier sicherzustellen dass mit beliebigen usern alles so laeuft wie erwartet ohne faelschlicherweise "unprivilegiert" zu wirken, ohne es zu sein ist viel arbeit.

 

[Falk R.]

In großen Umgebungen macht es durch aus Sinn, Aufgabe zu verteilen und da will ich nicht irgendeinem key user root-Rechte geben. Ich denke, da vor allem an den Anwendungsfall, wenn ich eine Entwicklungsabteilung habe. Die bevorzugen es natürlich oft mit der Kommandozeile zu arbeiten, um vielleicht auch Scripte zu nutzen. Es wäre schon schön, wenn sich die Benutzerberechtigung auch auf die Kommandozeile auswirken würde. Sicherlich nicht einfach umzusetzen in einem Cluster.

Auf einem Hypervisor per CLI basteln, dafür musst du überall root oder admin sein. Guck dir ESXi oder HyperV an.
Deshalb haben alle Hypervisoren eine GUI, wo man Berechtigungen anwenden kann.

 

[floh8]

Bei VMware, hätte ich jetzt gedacht, wäre es möglich. Ich habe mir überlegt, man könnte ja die Konsolenberechtigung via sudo mit ansible ausrolllen. Allerdings kann man ja dann nicht genau differenzieren zwischen den genauen Rechten. Um es einfach zu gestalten, würde man alle Proxmox-Kommandos erlauben und damit das Rollenkonzept wieder aushebeln. Das wäre natürlich nicht Sinn der Sache.

 

[floh8]

Eine Sache verstehe ich nicht. Wenn ich einen PAM-User in der GUI anlege, dann geht nichts, weil der Benutzer in der /etc/passwd fehlt. Wenn ich den dort anlege und dann über die GUI das Passwort vergebe, ändert Proxmox auf dem entsprechendem Node die /etc/shadow. Wenn das Passwort eines Linuxnutzers auf dem ensprechendem Host geändert werden kann, warum legt dann Proxmox nicht bei der Erstellung des PAM-Benutzers in der GUI gleich auch den Eintrag/Benutzer in der /etc/passwd für alle Hosts an?

 

[floh8]

weniger privilegien zu arbeiten empfiehlt es sich direkt die API als entsprechender user zu verwenden

Gibt es eine ausführliche Doku zur API/pvesh?
Ein kurzer Eintrag in der Doku gibt an, dass pvesh auch nur der root nutzen kann.

The Proxmox VE management tool (pvesh) allows to directly invoke API function, without using the REST/HTTPS server.
Note     Only root is allowed to do that.

 

[nunner]

Hier [1] ist die API von PVE dokumentiert, pvesh hat auch Autovervollständigung für die Pfade.

[1] https://pve.proxmox.com/pve-docs/api-viewer/index.html

 

[floh8]

Mit Benutzerrechten kann ich pvesh nicht nutzen. Wenn ich jetzt mit sudo root Rechte vergebe, greifen dann noch die Benutzerrechte?

honk@pve1:~$ pvesh get /nodes
ipcc_send_rec[1] failed: Is a directory
ipcc_send_rec[2] failed: Is a directory
ipcc_send_rec[3] failed: Is a directory
Unable to load access control list: Is a directory

 

[fabian]

die API ist eine REST-basiert API die über HTTP angesprochen wird. pvesh ist das CLI Tool um die API zu debuggen (und ist so wie die anderen CLI Tools root-only).

https://pve.proxmox.com/wiki/Proxmox_VE_API

 

[Falk R.]

Genau das ist ja das Problem. Die meisten Befehle benötigen root Rechte.
Berechtigungen bei VMware gehen super granular im vCenter, aber immer nur für die GUI.
Auf LAN Switches ist es genau das gleiche, Berechtigungen nur GUI und CLI Vollzugriff.

 

[fabian]

du kannst deine eigenen API Clients (auch als CLI Tool, das per HTTP mit der API spricht) schreiben, die die API verwenden. die Permissions sind natuerlich im Backend implementiert. das Problem ist das *unsere* CLI tools Teil des Backends sind (und somit von Haus aus privilegiert), und nicht als Frontend/Clients implementiert sind.

bei PBS ist das z.b. anders - da gibt es einen Client (proxmox-backup-client, benoetigt User+Password oder API Token) und ein Backend CLI Tool (proxmox-backup-manager, immer root), und die Features landen je nach Use-Case im einen oder anderen Tool (und auch hier gilt - 99% der Funktionalitaet ist im Backend ueber die API exposed, und eigene Custom Clients koennen fast alles was unsere Clients und Tools koennen selbst implementieren/integrieren).

 

[floh8]

Mir scheint, ich erwarte wieder viel zu viel. Würde man es umsetzen können, hätte man gleich zu Beginn das Design darauf ausrichten müssen. Das ist nicht so schön, aber man muss es so hinnehmen.

 

[Falk R.]

Du möchtest etwas was schwer umzusetzen ist und auch niemand sonst irgendwo nutzt.
Da bleibt meist das selbstbauen, wenn man das haben möchte. Ich verstehe auch nicht was gegen eine gute GUI spricht.

 

[Dunuin]

Oder halt direkt die API in Scripten ansprechen über z.B. cURL. Da kann man sich dann ja über einen Token oder PBS/PAM Realm Nutzer authentifizieren und schön fein bestimmen, wer da was darf.

 

[floh8]

ich bin kein niemand. eine Diskussion über den Sinn und etwaige Umsetzungsmöglichkeiten will ich jetzt hier nicht unterstützen.

 

[Falk R.]

Dann mache es doch wie die großen Firmen. Orchestrierung nennt man das Zauberwort.
Bei meinen größeren Kunden, können die Entwickler über eine einfache Webgui oder über ein CLI Script eine Anforderung für z.B. VMs machen.
Das wird dann vom Vorgesetzten abgenickt (erzeugt ja Kosten) und manchmal durch die IT überprüft (ob genug Ressourcen da sind) und dann laufen da meistens Ansible Scripte die dann mit Rechten auf dem Hypervisor die gewünschten VMs erzeugen.
Da eine Virtualisierung Hardwarenah ist, braucht man immer hohe Rechte, also setzt man meistens eine Web GUI davor, weil man dann granularer Berechtigungen steuern kann.
Die große Gefahr, wenn du im Hypervisor Berechtigungen änderst, fliegt dir im schlimmsten Fall beim nächsten Update alles um die Ohren.
Wenn du nicht selbst einen eigene Fork machen möchtest, solltest du dich vielleicht daran orientieren was die Masse der Leute machen und etwas bei den großen abschauen. Wenn das eine gute Idee wäre, jedermann einen CLI Zugriff einzurichten, hätte es schon jemand gemacht.