Bereitstellungsplan-Berechtigungen (Vorschau)

Ein Bereitstellungsplan ist ein Standard-Fabric-Element. Es führt kein eigenes Berechtigungsmodell ein: Der Zugriff auf einen Plan erfolgt aus deiner Arbeitsbereichsrolle, genau wie der Zugriff auf ein Notizbuch oder eine Datenpipeline.

Diagramm mit Bereitstellungsplanberechtigungen für Arbeitsbereichsrollen, Bereitstellungspipelines, Variablenbibliotheken und Serviceprinzipalen.

Es gibt keine planspezifische Rolle, keine Freigabe auf Elementebene für Pläne und keine separate Berechtigung, die erteilt werden muss, bevor jemand einen Plan erstellen kann.

Funktionsweise von Berechtigungen

Zwei verschiedene Kontrollen gelten zu zwei verschiedenen Zeitpunkten.

Wenn Sie einen Plan erstellen, bestimmt Ihre Arbeitsbereich-Rolle, ob Sie ihn erstellen, bearbeiten und löschen können. Da Arbeitsbereichsrollen für den gesamten Arbeitsbereich gelten, hat jeder, der einen Plan erstellen kann, bereits Zugriff auf jedes Element in diesem Arbeitsbereich. Es gibt keine zusätzliche Kontrolle für die im Plan genannten Punkte.

Wenn eine Bereitstellung ausgeführt wird, muss die Person oder der Dienstprinzipal, der die Bereitstellung startet, die Berechtigungen besitzen, die die Bereitstellung selbst im Zielarbeitsbereich benötigt. Das Anfügen eines Plans gewährt, erweitert oder umgeht diese Berechtigungen nicht. Ein Plan kann nur die Reihenfolge eines Einsatzes und die währenddessen durchgeführten Aktionen beeinflussen. Es kann niemandem Zugang geben, den er nicht bereits hat.

Important

Das Anhängen eines Plans erweitert niemals die Berechtigungen. Wenn eine Bereitstellung für einen Benutzer ohne Plan fehlschlagen würde, schlägt sie mit einem Plan auf die gleiche Weise fehl.

Rollen im Arbeitsbereich

Die folgende Tabelle zeigt die Mindestrolle im Arbeitsbereich für jeden Vorgang eines Bereitstellungsplans.

Operation Administrator Mitglied Mitwirkender Betrachter
Öffne einen Plan auf der Leinwand (lesen) ✅ ✅ ✅ ✅
Erstellen Sie, bearbeiten oder löschen Sie einen Plan ✅ ✅ ✅
Einen Plan per Git committen oder pullen, als Teil eines Workspace-Commits oder Aus Git aktualisieren ✅ ✅ ✅
Hänge während des Updates von Git einen Plan an. ✅ ✅ ✅
Hänge während der ersten Git-Synchronisation einen Plan an ✅ ✅ ✅
Hänge während des Branch-Outs einen Plan an ✅ ✅ ✅
Brechen Sie eine Bereitstellung mit angehängtem Plan ab. ✅ ✅ ✅
Sehen Sie sich die Planzusammenfassung für eine Bereitstellung an und öffnen Sie die Laufzeithistorie des Elements ✅ ✅ ✅ ✅

Jede Operation verwendet dasselbe Berechtigungsgate wie ihr Gegenstück, ohne Plan. Zum Beispiel erfordert das Anhängen eines Plans während eines Updates aus Git genau das, was ein Update von Git bereits erfordert.

Bereitstellungspipelines

Das Anfügen eines Plans in eine Deployment-Pipeline folgt dem Deployment Pipelines Permissions-Modell, das auf der Rolle basiert, die Sie in der jeweiligen Pipeline-Phase innehaben, und nicht auf dem Plan. Nutzer, die eine Stufe deployen können, können diesem Deployment einen Plan anhängen.

Variable Bibliotheken

Wenn ein Plan Aktionseingaben an eine variable Bibliothek verdrahtet, folgt der Zugriff auf diese Werte den eigenen Berechtigungen des variablen Bibliothekselements, die ebenfalls aus der Workspace-Rolle abgeleitet sind. Die Auswahl des aktiven Wertesatzes erfordert dieselbe Rolle, wie es eine direkte Änderung in der Variablenbibliothek erfordert.

Dienstprinzipale

Service Principals haben die gleichen rollenbasierten Berechtigungen wie Nutzer. Ein Service Principal, der planbasierte Bereitstellungen in einem CI/CD-Prozess ausführt, benötigt für den Zielarbeitsbereich die Rolle Contributor oder eine höhere Rolle, genau wie heute für jede Bereitstellung. Für den Plan ist kein zusätzlicher Zuschuss erforderlich.

Verwandte Inhalte

  • Zuletzt aktualisiert um