Zum Hauptinhalt springen

Service Accounts

Ein Service Account ist die Identität, die eine Pipeline verwendet, wenn sie eigenständig läuft – nicht im Namen einer Person. Es ist ein nicht-menschliches Konto mit eigenen Client Credentials und einer eigenen Menge von Rollen. Diese Rollen entscheiden, was die Pipeline lesen und schreiben darf.

Jeder Adapter hat ein Pipeline-Service-Account​

Jeder Adapter hat ein verpflichtendes Pipeline-Service-Account. Es wird automatisch bereitgestellt, wenn der Adapter eingerichtet wird, und besteht aus zwei Dingen, die für Sie erstellt werden:

  • einem Identity Client im Identity Service (die eigentlichen Credentials, mit denen sich die Pipeline authentifiziert) und
  • einer ServiceAccountConfiguration – einem kleinen, portablen Datensatz, der dem Adapter mitteilt, welchen Client er verwenden soll, welche Rollen dieser trägt und ob er im Namen eines Benutzers handeln darf.

Standardmäßig ist dieses eine Service Account die Identität für alle Pipelines des Adapters.

Ein fehlendes Service Account wird beim Deployment abgelehnt​

Da das Service Account verpflichtend ist, wird eine Pipeline, deren Identität nicht aufgelöst werden kann, beim Deployment abgelehnt – sie fällt nicht auf uneingeschränkten Zugriff zurück und läuft nicht „als System". Dies ist beabsichtigt: Eine Pipeline sollte niemals mit mehr Autorität laufen als vorgesehen, nur weil ihre Identität vergessen wurde.

Wenn dies geschieht, schlägt das Deployment mit einer klaren Meldung fehl, die auf die zwei Möglichkeiten zur Behebung hinweist:

  • Eine Konfiguration am Adapter verknüpfen – dies wird zur Standardidentität für jede Pipeline auf diesem Adapter, oder
  • Sie an der einzelnen Pipeline überschreiben – ein Service Account nur an diese eine Pipeline verknüpfen (siehe Standard vs. Override unten).
hinweis

Ein Adapter muss außerdem online sein, damit ein Deployment gelingt. Ist der Adapter offline, sehen Sie zunächst einen Verbindungsfehler; die Service-Account-Prüfung läuft, sobald der Adapter erreichbar ist.

Standard vs. Override​

Eine Pipeline löst ihre Identität in einer einfachen Rangfolge auf:

  • Adapter-Standard – das am Adapter verknüpfte Service Account wird von allen seinen Pipelines verwendet, sofern eine Pipeline nichts anderes angibt.
  • Override pro Pipeline – verknüpfen Sie ein anderes Service Account mit einer einzelnen Pipeline, und diese Pipeline verwendet es stattdessen. So geben Sie einer Pipeline breiteren (oder engeren) Zugriff als ihren Geschwistern.

Der Override wird als Uses-Verknüpfung von der Pipeline zur Service-Account-Konfiguration ausgedrückt. Sie müssen dafür kein YAML von Hand bearbeiten – Refinery Studio verwaltet die Verknüpfung für Sie (siehe Pipeline-Identität in Refinery Studio verwalten).

Die ServiceAccountConfiguration​

Die ServiceAccountConfiguration ist eine portable Deklaration einer Identität. Sie beschreibt Absicht, nicht Geheimnisse, sodass sie sicher exportiert, importiert und zwischen Tenants verschoben werden kann. Sie trägt:

Sie deklariertBedeutung
Client idAls welcher Identity Client sich die Pipeline authentifiziert
Zugewiesene RollenDie Rollen, die das Konto trägt – diese entscheiden, auf welche Daten es zugreifen kann
Delegation erlaubtOb dieses Konto im Namen eines aufrufenden Benutzers handeln darf (siehe Delegation)
IssuerIn welcher OctoMesh-Installation die Identität lebt
TenantZu welchem Tenant die Identität gehört

„Diese Installation" und „der aktuelle Tenant" sind die Standardwerte​

Sie lassen issuer und tenant normalerweise leer:

  • leerer issuer bedeutet „diese Installation" – die OctoMesh-Instanz, in der der Adapter selbst läuft, und
  • leerer tenant bedeutet „der aktuelle Tenant" – der Tenant, in dem die Pipeline läuft.

Sie füllen konkrete Werte nur dann aus, wenn Sie bewusst möchten, dass sich die Pipeline gegen einen fremden Tenant oder eine andere OctoMesh-Instanz authentifiziert. Für den überwältigend häufigen Fall – eine Pipeline, die innerhalb ihres eigenen Tenants handelt – ist es korrekt, beide leer zu lassen, und es hält die Deklaration portabel.

Das Secret ist optional​

Eine ServiceAccountConfiguration kann ein Client Secret tragen, muss es aber nicht. Wenn kein Secret vorhanden ist, funktioniert das Konto durch Impersonation: Die eigene Identität des Adapters darf als das Service Account handeln. Es gibt dann kein Klartext-Secret zu speichern, zu rotieren oder das auslaufen könnte – der Adapter authentifiziert sich mit seinen eigenen Credentials und handelt einfach als das Service Account, das ihm vorgegeben wurde.

tipp

Impersonation ist der einfachere und sicherere Standard für Pipelines, die innerhalb ihrer eigenen Installation bleiben: Es wird nichts Sensibles in der Konfiguration gespeichert, und es gibt kein Secret, das synchron gehalten werden muss. Verwenden Sie ein explizites Secret, wenn sich das Konto irgendwo authentifizieren muss, wo der eigenen Identität des Adapters nicht zugetraut wird, zu handeln – zum Beispiel gegen eine andere OctoMesh-Instanz.

Rollen entscheiden, worauf eine Pipeline zugreifen kann​

Was eine Pipeline lesen und schreiben kann, wird vollständig durch die Rollen ihres Service Accounts entschieden, über die Datenberechtigungen der Plattform. Dies schließt owner-bezogene Daten ein (Daten, die einem bestimmten Benutzer „gehören").

  • Für breiten Zugriff – geben Sie dem Service Account die Rollen, die die von der Pipeline benötigten Berechtigungen tragen. Speziell für owner-bezogene Daten benötigt das Konto eine Datenberechtigung, die über alle Owner hinweg Zugriff auf jeden Typ gewährt, den es sehen muss; andernfalls sieht es nur die Zeilen, die es selbst besitzt (was für ein Service Account üblicherweise keine sind).
  • Für minimale Rechte – verknüpfen Sie ein dediziertes Override-Service-Account mit der einen Pipeline und geben Sie ihm nur die Rollen, die es benötigt, und nicht mehr.
warnung

Ein Konto mit keinen effektiven Rollen ist kein Fehler – es ist einfach eine Identität, die nichts sehen kann. Eine Pipeline, die „einwandfrei läuft, aber keine Daten zurückgibt", ist oft ein Service Account, dem die Rolle fehlt, die die benötigte Berechtigung trägt. Prüfen Sie zuerst die Rollen des Kontos.

Verwandte Themen​