Paket-Permissions

[janbritz]

Aktuell hat jeder Worker festgesetzte Resourcen-Limits WorkerResourceLimits(max_memory=200 * MiB, max_cpu_time_seconds_per_call=10) was sich aber mit #137 ändern soll. Aufbauen auf diesen Kommentar:

Paket

Jedes Paket sollte sich auf ein festgelegtes Mindestmaß an Resourcen verlassen können, das es verwenden darf. Benötigt das Paket von einer oder mehreren Resourcen mehr, dann kann es über die qpy_config.yml angefordert werden z.B.:

resources:
  virtual_memory: 500 MiB
  cpu_time_per_call: 20s
  [...]

Sollten weniger Resourcen angefragt werden, als das festgelegte Mindestmaß, darf der Worker auch nicht mehr verwenden.

Paketabhängigkeit

Um die Implementierung im Server zu vereinfachen, würde ich vorschlagen, dass die angefragten Resourcen mindestens genauso hoch sein müssen, wie die der Abhängigkeiten. Im SDK könnte man für den Fall, dass das nicht gegeben ist, eine Warnung oder sogar eine Fehlermeldung ausgeben.
Das sollte relativ einfach bei statischen Abhängikeiten umzusetzen sein, bei Dynamischen muss der Entwickler vorher schauen, welche und wieviele die Pakete jeweils benötigen.

Server

Die Limits können vom Admin nach oben geändert werden. Wenn ein Paket mehr Resourcen benötigt, als vom Admin (oder per Default) festgelegt, dann wird das Paket nicht ausgeführt.

Der Admin sollte aber über die config.ini für ausgewählte Pakete Außnahmen machen können z.B.:

[worker_pool]
max_workers = 8
max_memory = 500 MiB

[worker]
virtual_memory = 250 MiB
cpu_time_per_call = 15s

exceptions =
     @qpy/truthtable {
         virtual_memory = 400 MiB
         cpu_time_per_call = 20s
     }
    @qpy/falsetable {
        virtual_memory = 200 MiB
    }

Man könnte hier auch überlegen, dass man zusätzlich zum Identifier auch eine Version angeben kann (@qpy/truthtable/1.0.0), oder die Limits für einen ganzen Namespace ändern kann (@qpy), oder es User-abhängig macht (tu-berlin.de).
Ich würde das wie die CSS-Regeln handhaben: die spezifischste zutreffende Regel (in unserem Fall der Identifer in exceptions) hat Vorrang.

[MartinGauk]

Wir hatten ja gestern schon kurz gesprochen. Wir müssten überlegen, ob wir das Dateiformat für die Konfiguration wechseln sollten. Ich überlege zudem, ob wir die paketspezifische Konfiguration in eine eigene Datei auslagern sollten, um die wichtigsten Einstellungen von diesen zusätzlichen/optionalen Einstellungen zu trennen.

In diesem Zusammenhang würde es mir gefallen, wenn wir das Konzept von admin_settings berücksichtigen. Das sind beliebige Einstellungen, die vom Admin hinterlegt werden können/müssen (z.B. Zugangsdaten zu anderen Diensten/Servern) und vom Paket abgerufen werden können. Oder vielleicht gehören die besser in eine eigene Datei?

Bezüglich virtual memory: Wir wechseln irgendwann zu cgroups und begrenzen dann nicht mehr nach virtual memory sondern physical memory. Ich würde daher nur von memory schreiben.

Ressourcenlimits

Mir gefällt die Idee, dass man durch deinen Vorschlag als Admin einzelnen Paketen sogar ein anderes Ressourcenlimit zuteilen kann als sie über ihr Manifest anfordern. Ich denke hier z.B. an Programmieraufgaben, die je nach Sprache und Aufgabe sehr unterschiedliche Anforderungen haben. Ein generischer Fragetyp für Programmieraufgaben müsste über das Manifest ansonsten ständig zu viele Ressourcen anfordern und in Einzelfällen reicht es immer noch nicht.

Theoretisch wäre es nett, wenn ein Paket auch zur Laufzeit höhere Limits anfordern kann, um nicht pauschales Overprovisioning betreiben zu müssen. CPU/Memory-Limits können wir in cgroups ja problemlos ändern. Aber schaffen wir uns dann neue Probleme (potentiell starvation)?

Vielleicht können wir noch unterscheiden zwischen maximalen Ressourcen, die z.B. alle Pakete im Namespace @qpy anfordern und erhalten dürfen, und einem Überschreiben der Limits durch feste Werte.

Pakete identifizieren

Für das Erteilen von Permissions ist die Verwendung von Namespace und Shortname unsicher. Bei kritischen Permissions (z.B. Freigabe zum ungehinderten Netzwerkzugriff) sollte man das Paket lieber über den Hash identifizieren. Ansonsten sollte im Allgemeinen nach der Herkunft unterschieden werden. Ich denke hierbei an diese Merkmale, die verundet werden:

• Herkunft
  • Repository (exakter Match der Repo-URL/Name¹ oder beliebiges in allgemeiner Konfiguration hinterlegtes Repo) oder
  • local oder
  • User (exakter Match oder beliebiger User)
    • Context (Matching nach übermittelten Context oder beliebiger Context)¹ ²
• Namespace (exakter Match oder beliebiger Name)
• Shortname (exakter Match oder beliebiger Name)
• Version (Match oder beliebige Version)

(¹ muss im Rahmen dieses Issues noch nicht implementiert werden)
(² Wir könnten das Konzept mit dem übermittelten Context noch erweitern als String, z.B. übermittelt unser Moodle-Plugin [Kurs ID]-[Quiz Context ID], damit man einem ganzen KI-Kurs viel mehr Ressourcen erteilen kann)

ODER

• Hash

[janbritz]

Wir müssten überlegen, ob wir das Dateiformat für die Konfiguration wechseln sollten.

Mit INI müssten wir eine weitere Syntax für die exceptions einführen (neben collector->repositories und auth->users), was mMn nicht intuitiv ist. Ich denke YAML wäre hier, trotz zusätzlicher Abhängigkeit, schöner/geeigneter als TOML.
Zum einen können weiterhin Angaben mit Einheiten oder URLs, ohne " geschrieben werden. Zum anderen müssen Mapping-Keys unique sein, wodurch die IDE Fehler anzeigt, auf die wir im Code auch testen (hier und hier). YAML vs. TOML:

In TOML könnte man die expections aber auch so angeben:

[worker]
exceptions = [
    { identifier = "@qpy/truthtable", memory = "400 MiB" }
]

Ich überlege zudem, ob wir die paketspezifische Konfiguration in eine eigene Datei auslagern sollten, um die wichtigsten Einstellungen von diesen zusätzlichen/optionalen Einstellungen zu trennen.

Ich finde es eigentlich immer ganz schön, wenn alle Einstellungen an einem Ort liegen. Da die exceptions-Liste natürlich auch sehr lang werden kann und damit die Config unübersichtlich werden würde, könnte man die Option anbieten, einen Pfad anzugeben, in welcher die Konfigurationen liegen - z.B.: exceptions: path/to/exceptions oder exceptions_file: path/to/exceptions.
Diese Überlegungen können wir auch auf collector->repositories und auth->users übertragen.

In diesem Zusammenhang würde es mir gefallen, wenn wir das Konzept von admin_settings berücksichtigen. Das sind beliebige Einstellungen, die vom Admin hinterlegt werden können/müssen (z.B. Zugangsdaten zu anderen Diensten/Servern) und vom Paket abgerufen werden können. Oder vielleicht gehören die besser in eine eigene Datei?

Ah, interessant, da diese Optionen nicht direkt den Server betreffen, wäre die Trennung in eine eigene Datei nicht so abwegig. Eventuell könnte das aber auch verwirrend sein, weshalb wir hier auch den hybriden Ansatz abieten sollten.

Vielleicht können wir noch unterscheiden zwischen maximalen Ressourcen, die z.B. alle Pakete im Namespace @qpy anfordern und erhalten dürfen, und einem Überschreiben der Limits durch feste Werte.

Ja, das halte ich für sehr sinnvoll, ersteres entspricht übrigens eigentlich meiner ersten Idee. Wie wäre es mit einer exceptions-Section, hier können die maximalen Ressourcen angegeben werden, bis zu welcher die zutreffenden Pakete Resourcen anfordern können und einer enforce/overwrite/?-Section, die das Überschreiben der Limits ermöglicht?

Für das Erteilen von Permissions ist die Verwendung von Namespace und Shortname unsicher. Bei kritischen Permissions (z.B. Freigabe zum ungehinderten Netzwerkzugriff) sollte man das Paket lieber über den Hash identifizieren.

Das sehe ich genauso und finde die Regelung auch sehr gut. Bei kritischen Permissions könnten wir später auch eine Warnung ausgeben, falls das Paket nicht über den Hash angegeben wurde.

(² Wir könnten das Konzept mit dem übermittelten Context noch erweitern als String, z.B. übermittelt unser Moodle-Plugin [Kurs ID]-[Quiz Context ID], damit man einem ganzen KI-Kurs viel mehr Ressourcen erteilen kann)

Würde dafür nicht auch einfach die Kurs-ID reichen?

[MartinGauk]

Basierend auf deinem gestrigen Vorschlag habe ich mir folgende Beispielkonfiguration überlegt, die den Grundgedanken zeigen soll, auch über weitere Permissions, die jetzt aber noch nicht konkret implementiert werden müssen. Ich denke, cpus, memory, request_timeout, bootstrap_timeout und main_process_execution_mode reichen zunächst.

worker_pool:
  # Maximum number of CPUs that can be used by all workers
  max_cpus: 8
  
  # Maximum combined memory usage of all workers
  max_memory: 500 MiB

# Packages may request more resources and ask for permissions.
permissions:
  # Resources/permissions are granted automatically up to these limits
  auto_grant_limits:
    # Maximum number of CPUs
    cpus: 2

    # Maximum memory usage (at least 200 MiB)
    memory: 250 MiB

    # Allowed execution modes for the worker main process. Allowed values are:
    #  - container: executed in isolated containers
    #  - trusted: executed as a normal process (but with CPU and memory limits), implies unrestricted_network_access
    main_process_execution_modes:
      - container

    # Maximum time (in seconds) per request (at least 10)
    request_timeout: 20

    # Maximum time (in seconds) for the worker to start (at least 4)
    bootstrap_timeout: 4

    # Worker is allowed to contact these URLs
    allowed_urls:
      - url: https://example.com/test*
        methods: ["GET", "POST"]
      - url: https://example.com/send-data
        methods: ["POST"]

    # Worker main process executed in a container gets unrestricted network access
    unrestricted_network_access: false

    # Maximum number of allowed containers to be started by the worker
    can_run_containers: 1

    # Allowed container images that can be started by the worker
    can_run_images:
      - docker.io/library/postgres:bookworm
      - docker.io/library/node:bookworm

    # The LMS should send this user information and profile fields
    lms_user_information:
      - user_id
      - course_id
      - attempt_id
      - username
      - person_first_name
      - person_last_name
      - profile_field_x
      - group_id
      - group_name
      - group_members

  packages:
    - package_selector:
        origin:
          repository: "*"
          local: true
          user: "*"
        request_context: "*"
        namespace: "*"
        shortname: "*"
        version: "*"
        hash: "*"
      auto_grant_limits:
        memory: 500 MiB
        request_timeout: 30
        bootstrap_timeout: 5

    - package_selector:
        origin:
          local: true
        request_context: "98765"
        namespace: "example"
        shortname: "coderunner"
        version: ">=2.0.0"
      override_limits:
        memory: 2 GiB

    - package_selector:
        hash: eee26bb21675236b7e98598e31d5db887cbc5d671c1d46c3e4e03e46cd3a35e0
      auto_grant_limits:
        cpus: 8
        memory: 10 GiB
        can_run_containers: 5
        allowed_urls:
          - url: https://internal/*
            methods: "*"

[MHajoha]

    # Allowed execution modes for the worker main process. Allowed values are:
    #  - container: executed in isolated containers
    #  - trusted: executed as a normal process (but with CPU and memory limits), implies network_access
    main_process_execution_mode: container

Anders als CPU, Memory, etc. haben die execution modes ja keine richtige Ordnung, daher halte ich es für sinnvoller, die erlaubten Modi aufzulisten.

    # Worker is allowed to contact these URLs
    allowed_urls:
      - url: https://example.com/test*
        methods: ["GET", "POST"]
      - url: https://example.com/send-data
        methods: ["POST"]

Um den Inhalt (Pfad) von HTTPS-Requests einzugrenzen, müssten wir einen MITM-Proxy zwischen dem Paket und der Außenwelt schalten, das geht nicht so einfach. Wir sollten denke ich eher auf Domain (bzw. IP/CIDR) und Port eingrenzen.

      allowed_limits:
        memory: 500 MiB
        request_timeout: 30
        bootstrap_timeout: 5
      override_limits:
        memory: 600 MiB
        request_timeout: 40
        bootstrap_timeout: 6

Mich verwirrt ein wenig der Unterschied zwischen "allowed" und "override". Von außen betrachtet würde ich allowed_limits so lesen, dass es die gleiche Semantik hat wie auto_grant_limits, d.h. erst nach Anforderung durch das Paket applied werden, und override_limits würde ich als "verwende sofort diese Limits" interpretieren, aber das macht in diesem Beispiel ja keinen Sinn. Wie ist das gemeint?

Wir hatten Dienstag auch kurz über "Jobs", also kurze Spikes im Ressourcenverbrauch eines Pakets, z.B. um eine Programmieraufgabe auszuführen, gesprochen. Da wir nicht das ganze Paket warten lassen wollen, bis 1 GB (oder so) RAM dafür verfügbar sind, wäre es vielleicht sinnvoll, Pakete Jobs "queuen" zu lassen, die dann (ggf. direkt in einem Extra-Container) ausgeführt werden, wenn die notwendigen Ressourcen verfügbar sind. Wollen wir die Idee weiter verfolgen?

[MartinGauk]

Anders als CPU, Memory, etc. haben die execution modes ja keine richtige Ordnung, daher halte ich es für sinnvoller, die erlaubten Modi aufzulisten.

Das stimmt. Ich habe es im Beispiel oben geändert.

Um den Inhalt (Pfad) von HTTPS-Requests einzugrenzen, müssten wir einen MITM-Proxy zwischen dem Paket und der Außenwelt schalten, das geht nicht so einfach. Wir sollten denke ich eher auf Domain (bzw. IP/CIDR) und Port eingrenzen.

Mein Gedanke ging in die Richtung, dass die Worker (außer bei unrestricted_network_access) überhaupt keinen Netzwerkzugriff haben. Wenn sie auf eine Ressource zugreifen wollen, müssen sie den QuestionPy-Server bitten, den Aufruf zu erledigen und die Antwort zurückzugeben. Um den Aufwand zu begrenzen, sollten aber nur einfache Requests ermöglicht werden, keine Websockets, etc.
An welche Lösung würdest du denken, wenn auf Ebene von Domain/IP/Port der Netzwerkverkehr eingeschränkt werden soll?

Mich verwirrt ein wenig der Unterschied zwischen "allowed" und "override". Von außen betrachtet würde ich allowed_limits so lesen, dass es die gleiche Semantik hat wie auto_grant_limits, d.h. erst nach Anforderung durch das Paket applied werden, und override_limits würde ich als "verwende sofort diese Limits" interpretieren, aber das macht in diesem Beispiel ja keinen Sinn. Wie ist das gemeint?

So war es gemeint. Ja, das Beispiel ergibt so keinen Sinn. Es sollte mehr die Syntax aufzeigen. Ich habe es oben geändert.
Außerdem ist es wahrscheinlich logischer, wenn es ebenfalls auto_grant_limits statt allowed_limits heißt.

[MartinGauk]

Wir hatten Dienstag auch kurz über "Jobs", also kurze Spikes im Ressourcenverbrauch eines Pakets, z.B. um eine Programmieraufgabe auszuführen, gesprochen. Da wir nicht das ganze Paket warten lassen wollen, bis 1 GB (oder so) RAM dafür verfügbar sind, wäre es vielleicht sinnvoll, Pakete Jobs "queuen" zu lassen, die dann (ggf. direkt in einem Extra-Container) ausgeführt werden, wenn die notwendigen Ressourcen verfügbar sind. Wollen wir die Idee weiter verfolgen?

Wie genau würdest du dir das vorstellen? Sollte es dann neben den Ressourcen für den Worker Pool auch dedizierte Ressourcen für Jobs geben?

Da das Thema nicht akut ist, brauchen wir jetzt noch keine Master-Lösung, aber ich finde es immer gut, wenn man sich schon mal Gedanken macht. Gut ist ja, dass wir uns im Grunde nur Gedanken machen müssten, was RAM angeht. CPUs wäre es sicherlich schön, wenn ein Worker das erhält, was er anfordert, aber es ist in der Regel nicht schlimm, wenn ein Worker weniger CPUs erhält als er haben möchte.

[MHajoha]

Mein Gedanke ging in die Richtung, dass die Worker (außer bei unrestricted_network_access) überhaupt keinen Netzwerkzugriff haben. Wenn sie auf eine Ressource zugreifen wollen, müssen sie den QuestionPy-Server bitten, den Aufruf zu erledigen und die Antwort zurückzugeben. Um den Aufwand zu begrenzen, sollten aber nur einfache Requests ermöglicht werden, keine Websockets, etc.
An welche Lösung würdest du denken, wenn auf Ebene von Domain/IP/Port der Netzwerkverkehr eingeschränkt werden soll?

Ah verstehe. Ich dachte, dass wir aus google.com:443/tcp (oder so) IPTables-Regeln erstellen, die Traffic nach 142.251.143.46:443 (und [2a00:1450:4008:804::200e]:443) erlauben. Die HTTP-Proxy-Variante klingt auch sinnvoll, und vermutlich etwas einfacher. Ich vermute fast, wir brauchen irgendwann beides, um auch nicht-HTTP-Traffic zu erlauben.

Wir hatten Dienstag auch kurz über "Jobs", also kurze Spikes im Ressourcenverbrauch eines Pakets, z.B. um eine Programmieraufgabe auszuführen, gesprochen. Da wir nicht das ganze Paket warten lassen wollen, bis 1 GB (oder so) RAM dafür verfügbar sind, wäre es vielleicht sinnvoll, Pakete Jobs "queuen" zu lassen, die dann (ggf. direkt in einem Extra-Container) ausgeführt werden, wenn die notwendigen Ressourcen verfügbar sind. Wollen wir die Idee weiter verfolgen?

Wie genau würdest du dir das vorstellen? Sollte es dann neben den Ressourcen für den Worker Pool auch dedizierte Ressourcen für Jobs geben?

Eine genaue Vorstellung habe ich auch noch nicht. Um dem Job Ressourcen zuweisen zu können, müsste er sicher in einem eigenen Container ausgeführt werden. Und ich denke der Ressourcen-Pool sollte der gleiche sein, und die Anfrage auch gleichberechtigt mit anderen Requests eingeschlangt werden.

[MartinGauk]

Ah verstehe. Ich dachte, dass wir aus google.com:443/tcp (oder so) IPTables-Regeln erstellen, die Traffic nach 142.251.143.46:443 (und [2a00:1450:4008:804::200e]:443) erlauben. Die HTTP-Proxy-Variante klingt auch sinnvoll, und vermutlich etwas einfacher. Ich vermute fast, wir brauchen irgendwann beides, um auch nicht-HTTP-Traffic zu erlauben.

Ich habe mal ein neues Issue zum Thema Netzwerkzugriff erstellt. Mein ursprünglicher Gedanke war kein klassischer Proxy (Variante 1 im Issue). Normale Proxy-Server (Variante 2) erscheinen mir nun aber auch ein sehr guter Weg zu sein und sie werden in Clients typischerweise gut unterstützt. Und wir erreichen eine gute Einschränkung nach Domain/IP. Mit einem SOCKS-Proxy wäre sämtlicher TCP- und UDP-Traffic möglich.