Pipeline-Identität in Refinery Studio verwalten
Refinery Studio macht die Identität einer Pipeline dort sichtbar und verwaltbar, wo Sie bereits arbeiten — am Adapter, an der Pipeline und an der Service-Account-Konfiguration selbst. Diese Seite führt durch das, was Sie sehen und was Sie tun können.
Am Adapter — das Panel „Pipeline Service Account"
Öffnen Sie das Bearbeitungsformular eines Adapters, und Sie finden dort einen Abschnitt Pipeline Service Account. Er zeigt die Identität, die alle Pipelines des Adapters standardmäßig verwenden:
- die verknüpfte Configuration und den Client, als der sie sich authentifiziert,
- die Rollen, die das Konto trägt (als Chips dargestellt), und
- wie breit es genutzt wird — „Default for N of M pipeline(s)".
Ist nichts verknüpft, zeigt das Panel einen klaren Gefahrenhinweis: „No pipeline service account is linked — the deploy guard will refuse every pipeline on this adapter. Link a configuration here or set a per-pipeline override." Dies ist dieselbe Regel, die unter Service Accounts beschrieben ist — das Panel bringt sie lediglich zutage, bevor Sie eine Bereitstellung versuchen.
Rotate Secret
Das Panel besitzt eine Rotate Secret-Aktion, die ein frisches Client-Secret für das Pipeline-Service-Account ausstellt. Da das alte Secret sofort aufhört zu funktionieren, verwendet der Adapter es weiter, bis seine Datenflüsse neu bereitgestellt werden — deshalb bestätigt Studio die Aktion und bietet, sobald das neue Secret ausgestellt ist, eine Deploy data flows-Schaltfläche an, um es sofort auszurollen.
Die Rotation gilt nur für Konten, die ein explizites Secret verwenden. Konten, die per Impersonation arbeiten, haben kein Secret zum Rotieren (siehe Service Accounts → Das Secret ist optional); Studio zeigt deren Anmeldemodus als „impersonation via adapter credentials" statt „secret-based".
An der Pipeline — der Block „Execution Identity"
Wenn Sie eine Pipeline (einen Datenfluss) bearbeiten, enthält ihr Eigenschaften-Panel einen Execution Identity-Block, der Ihnen auf einen Blick sagt, als wer diese Pipeline läuft. Er zeigt einen von drei Zuständen:
| Zustand | Chip | Bedeutung |
|---|---|---|
| Inherited | Inherited from adapter | Die Pipeline verwendet das Standard-Service-Account des Adapters |
| Override | Override | Die Pipeline hat ihr eigenes verknüpftes Service Account, das gegenüber der Adapter-Standardeinstellung gewinnt |
| Unresolved | Gefahrenhinweis | Es kann keine Identität aufgelöst werden — die Bereitstellung dieser Pipeline wird verweigert |
Neben dem Zustand sehen Sie die Rollen-Chips der Identität und eine Live-Zusammenfassung des Gesundheitszustands (siehe unten). Von hier aus können Sie:
- Override… — ein dediziertes Service Account nur mit dieser Pipeline verknüpfen (für breiteren oder engeren Zugriff als bei ihren Geschwistern), oder
- Revert to adapter default — das Override entfernen und auf das Konto des Adapters zurückfallen.
Ist die Identität nicht aufgelöst, verlinkt der Block direkt zum Adapter, sodass Sie den Standard in einem Sprung korrigieren können.
An der Konfiguration — Usage & identity
Öffnen Sie eine Service-Account-Konfiguration, und ihr Usage & identity-Panel beantwortet die Frage „wo wird dieses Konto verwendet, und was ist es?":
- Default for — die Adapter, die es als ihren Standard verwenden, und
- Override for — die einzelnen Pipelines, die es als Override verknüpfen,
zusammen mit dem verknüpften Client und seinen Rollen. Konten, die von einem Blueprint installiert wurden, sind als app-managed gekennzeichnet, und ihre Kernfelder sind schreibgeschützt, sodass Sie nicht versehentlich etwas bearbeiten, das dem Blueprint gehört.
Gesundheitszustand auf einen Blick
Überall, wo eine Identität erscheint — im Adapter-Panel, im Execution-Identity-Block und in den Konfigurationsdetails — zeigt Studio einen kleinen Satz von Health-Badges, die jedes Mal live abgerufen werden. Der Gesamtzustand ist einer von healthy, unhealthy oder health unknown, und die einzelnen Prüfungen umfassen:
| Prüfung | Was sie bestätigt |
|---|---|
| Client | Der Identitäts-Client existiert im Tenant |
| Secret | Ein verwendbares Secret ist vorhanden (für Secret-basierte Konten) |
| Roles | Die Rollen des Kontos stimmen mit seiner Deklaration überein — Missing- und Superfluous-Rollen werden aufgeführt, falls sie abweichen |
| Tenant | Das Konto zeigt auf den richtigen Tenant |
| Issuer | Das Konto zeigt auf die richtige Installation |
| Delegation | On-Behalf-Of ist korrekt eingerichtet, wenn das Konto Delegation erlaubt |
| Impersonation | Die Impersonation-Verknüpfung ist für Secret-lose Konten vorhanden |
health unknown bedeutet in der Regel, dass der Identity Service in diesem Moment nicht erreichbar war, nicht dass etwas kaputt ist.
Analyse der erforderlichen Rechte
Woher wissen Sie, welche Rollen ein Service Account tatsächlich benötigt? Die Analyze required rights-Aktion arbeitet es für Sie aus. Sie durchläuft die Definitionen des Adapters (oder einer einzelnen Pipeline) auf dem Server, sammelt jeden geschützten Datentyp, den die Pipelines berühren, und verknüpft das mit den Datenberechtigungen des Tenants, um die Rollen zu empfehlen, die den benötigten Zugriff gewähren würden.
Das Ergebnis wird als Delta gegenüber der aktuellen Deklaration des Kontos dargestellt:
- „declaration covers all touched types", wenn nichts fehlt, oder
- gruppierte Missing- und Superfluous-Rollen-Chips, wenn doch etwas fehlt, plus eine Baseline-Gruppe für Rollen, die jedes Pipeline-Konto benötigt.
Sie kennzeichnet auch die kniffligen Fälle ehrlich: owner-scoped-Typen werden hervorgehoben, weil ein Service Account für sie einen Full-Scope-Grant benötigt oder blind bleibt (siehe Service Accounts → Rollen entscheiden, worauf eine Pipeline zugreifen kann), und Typen, deren Identität erst zur Laufzeit bekannt ist, werden separat als nicht statisch analysierbar aufgeführt.
Die Analyse der erforderlichen Rechte ist eine Empfehlung. Sie zeigt Ihnen, was zu gewähren ist; Sie weisen die Rollen dennoch bewusst zu.
Administrative Aufgaben: Reconcile und Health
Zwei Fähigkeiten existieren für Administratoren über die alltäglichen Panels oben hinaus.
- Reconcile materialisiert oder repariert ein Service Account aus seiner Deklaration: Es stellt sicher, dass der Identitäts-Client existiert, gleicht Issuer und Tenant an, stellt nur dann ein Secret aus, wenn keines vorhanden ist, und synchronisiert die Rollen, die Delegation und die Impersonation-Verknüpfungen so, dass sie übereinstimmen. Reconcile läuft automatisch, nachdem ein Blueprint angewendet wurde, und wenn ein Tenant eingerichtet wird, sodass durch Blueprints bereitgestellte Konten ohne manuelle Schritte korrekt gehalten werden. Das Materialisieren von Rollen für ein Service Account ist an die UserManagement-Rolle gebunden, da es ändern kann, was eine Identität tun darf.
- Health kann bei Bedarf ausgelesen werden (es sind dieselben Daten, die die Studio-Badges zeigen): Ist der Client vorhanden, ist ein Secret gesetzt, stimmen die Rollen mit der Deklaration überein, ist der Tenant richtig und — für Secret-lose Konten — ist die Impersonation-Verknüpfung vorhanden.