Zum Hauptinhalt springen

Pipeline-Identität

Warum Pipelines eine Identität haben​

Eine Pipeline liest und schreibt echte Daten: Sie fragt Entitäten ab, erstellt und aktualisiert sie, speichert Zeitreihenwerte und beantwortet – zunehmend – Fragen im Namen einer Person über einen KI-Assistenten. Die Frage „als wer handelt diese Pipeline?" ist daher für eine Pipeline genauso wichtig wie für einen angemeldeten Benutzer.

In früheren Versionen lief eine Pipeline mit implizitem, uneingeschränktem Zugriff – so, als wäre sie das System selbst. Das ist bequem, aber unsicher: Jede Pipeline konnte beliebige Daten berühren, und es gab keine Möglichkeit zu sagen: „Diese Pipeline darf nur das tun, was diese Person tun darf."

Heute läuft jede Pipeline unter einer Identität. Genau wie ein Benutzer hat eine Pipeline nun einen Namen, als der sie handelt, eine Menge von Rollen und – über Datenberechtigungen – eine klar definierte Menge an Daten, die sie sehen und verändern darf. Nichts wird durch die Benutzeroberfläche verborgen; der Zugriff wird auf dem Server entschieden und durchgesetzt.

info

Dies ändert das Sicherheitsmodell, nicht die Art und Weise, wie Sie Pipelines bauen. Sie erstellen Nodes und Datenflüsse weiterhin genau wie zuvor. Was sich geändert hat: Die Plattform hängt nun jedem Pipeline-Lauf eine Identität an und prüft sie gegen die Datenberechtigungen.

Die zwei Modi​

Eine Pipeline läuft in einem von zwei Modi.

Service Account – die Standardeinstellung​

Standardmäßig handelt eine Pipeline als ihr eigenes Service Account: eine dedizierte, nicht-menschliche Identität, die zum Adapter der Pipeline gehört. Das Service Account hat eine feste Menge von Rollen, und diese Rollen entscheiden, was die Pipeline lesen und schreiben darf. Dies ist der richtige Modus für geplante Jobs, Importe, Integrationen und jede Pipeline, die ihre Arbeit unabhängig von einer bestimmten Person erledigt.

Siehe Service Accounts.

Delegation – im Namen des aufrufenden Benutzers​

Manche Pipelines laufen, weil eine Person darum gebeten hat – zum Beispiel der KI-Chat in einer Anwendung, in dem ein Benutzer eine Frage stellt und eine Pipeline sie beantwortet. Für diese benutzerorientierten Abläufe kann eine Pipeline im Delegations-Modus laufen: Ihre Arbeit wird unter der Identität des aufrufenden Benutzers ausgeführt, sodass der Benutzer immer nur die Daten sieht, die er selbst sehen darf.

Um sicher zu bleiben, ist ein delegierter Lauf auf das beschränkt, was beide Seiten dürfen – die effektiven Rollen sind die Schnittmenge aus den Rollen des Service Accounts und den Rollen des Benutzers. Ein mächtiges Service Account kann einem Benutzer niemals mehr Zugriff verleihen, als dieser Benutzer bereits hat.

Siehe Delegation.

Wie der Zugriff tatsächlich entschieden wird​

Welcher Modus auch verwendet wird, das Ergebnis ist dasselbe: die Rollen der Identität entscheiden, welche Daten die Pipeline berühren darf, über die Datenberechtigungen der Plattform. Um einer Pipeline breiten Zugriff zu geben, weisen Sie ihrem Service Account die Rollen zu, die die benötigten Berechtigungen tragen. Für minimale Rechte verknüpfen Sie ein dediziertes Service Account, das nur das trägt, was genau diese eine Pipeline benötigt.

Wo jedes Element verwaltet wird​

AnliegenWo es verwaltet wird
Die Standardidentität einer PipelineAn ihrem Adapter – jeder Adapter hat ein verpflichtendes Pipeline-Service-Account (siehe Service Accounts)
Ein Override für eine einzelne PipelineEine Verknüpfung von der Pipeline zu einem anderen Service Account
Die Rollen, die eine Identität trägtDie Deklaration des Service Accounts und die Rollen, die ihm zugewiesen sind
Ausführung im Namen eines BenutzersPro KI-Node und über einen tokentragenden HTTP-Trigger aktiviert (siehe Delegation)
Alles sehen und reparierenRefinery Studio

Verwandte Themen​