Konnektivität

Diese Seite erklärt, wie workspaces Datenquellen erreichen: die Verbindungstypen, die die Plattform für dich anlegt, was du liefern musst und die ausgehenden Regeln drumherum. Das Netzwerkdesign dahinter steht in der Architektur.

Referenzdesign, dein Deployment kann abweichen

Verbindungstypen und Standardwerte unten sind die des Lösungscodes. Frag dein Plattform-Team, welche aktiviert sind.

Zwei Wege zu einer Quelle

Weg	Nutze ihn, wenn	So funktioniert er
VNet data gateway	Die Quelle im spoke-Netzwerk liegt oder On-Premises über ExpressRoute oder VPN	Fabric-Verbindungen werden so konfiguriert, dass sie das Gateway der Umgebung nutzen. Der workspace darf nur dieses Gateway verwenden.
Managed private endpoint	Die Quelle eine Azure-Ressource ist, die Private Link unterstützt (zum Beispiel Storage oder SQL), oder ein anderer Fabric-workspace	Eine direkte private Verbindung pro Ressource. Sie nutzt normalerweise das Gateway nicht.

Der ausgehende Traffic eines workspaces ist standardmäßig blockiert. Er verlässt den workspace nur über das Gateway oder einen managed private endpoint (siehe Workspace Network Policy).

Verbindungen über das Gateway

Alle Verbindungen unten nutzen den Konnektivitätstyp VirtualNetworkGateway und das Gateway der capacity des workspaces. Der Anzeigename einer Verbindung ist der Key, den du in der Konfiguration wählst. Die Zugangsdaten werden beim Lauf der pipeline anhand des Secret-Namens aus dem Key Vault des spokes gelesen. Sie werden nie im Repository gespeichert.

Typ	Authentifizierung	Was du lieferst
ADLS	Service Principal mit Client Secret	Container-Name und die Namen der Secrets, die die Client-ID und das Client Secret enthalten
SQL (Service Principal)	Service Principal mit Client Secret	Server, Datenbank und die Namen der Secrets für Client-ID und Client Secret
SQL (basic)	Benutzername und Passwort, für Datenbanken mit SQL-Authentifizierung	Server, Datenbank und die Namen der Secrets für Benutzername und Passwort
Oracle Cloud Storage	Basic (Benutzername und Passwort)	API-Endpoint und die Namen der Secrets für Benutzername und Passwort

Hinweise:

• Die ADLS-Verbindung zeigt auf einen Container des Data-Lake-Storage-Accounts der jeweiligen Umgebung (der DFS-Endpoint). Die Plattform legt den Container für jede ADLS-Verbindung an. Der Service Principal in den Secrets braucht Zugriff auf den Storage Account, was außerhalb dieser Lösung geregelt wird.
• Bei SQL mit Service Principal (und bei anderen Entra-ID-basierten Quellen) braucht der Service Principal Zugriff auf die Quelle. Die Plattform vergibt ihn nicht. Standardmäßig wird der Service Principal des spokes verwendet, du kannst aber über die Secret-Namen einen anderen angeben.
• Nur die oben genannten Verbindungstypen werden von der Lösung angelegt. Das Repository enthält außerdem einen Referenzexport aus der Fabric- API mit den Verbindungstypen, die Fabric für ein VNet data gateway als unterstützt listet (docs/reference/fabric_vnet_connection_types.json im Repository der Lösung). Nutze ihn, um zu prüfen, ob ein Typ ergänzt werden könnte, was eine Entwicklungsänderung wäre.
• Das Gateway schläft nach 30 Minuten Inaktivität und wacht bei der nächsten Anfrage auf.
• Nutzungsrechte für Verbindungen werden an Gruppen vergeben, siehe Zugriff und Rollen.

Workspace zu workspace

Eine workspace-zu-workspace-Verbindung legt einen managed private endpoint von einem workspace zu einem anderen workspace der Plattform an (über den Private Link Service des Ziel-workspaces). Damit lassen sich Lakehouses und Warehouses des anderen workspaces nutzen. Für jede solche Verbindung nimmt die Plattform außerdem den Ziel-workspace in die Allowed List der ausgehenden Cloud-Verbindungen des Quell-workspaces auf, für die Verbindungstypen LakeHouse und Warehouse, mit der Standard- Aktion Deny und erlaubten Power-BI-Semantic-Models.

Die Allowed List funktioniert nur mit aktiviertem Outbound-Schutz

Fabric erzwingt diese Verbindungsregeln nur, wenn die Outbound-Standardaktion des workspaces Deny ist. Bei ausgeschaltetem Outbound-Schutz gibt der Aufruf 403 zurück, das Deployment überspringt den Schritt, und die Regeln werden nicht erzwungen. Siehe Workspace Network Policy.

Managed private endpoints zu Azure-Ressourcen

Du lieferst die Resource-ID des Ziels und den Sub-Resource-Typ (zum Beispiel blob oder dfs für einen Storage Account). Der Endpoint wird im workspace mit dem Namen pe-<workspace name>-<key> angelegt.

Git-Integration

Ein workspace kann zur Versionskontrolle mit einem Git-Repository verknüpft werden. Die Lösung unterstützt GitHub (einschließlich einer eigenen GitHub-Domain).

Element	Wert
Konfiguration	Owner, Repository, Branch und Verzeichnis. Das Verzeichnis muss im Repository existieren.
Zugangsdaten	Ein Personal Access Token, das aus einem Key-Vault-Secret mit festem Namen (GitHub-PAT) im Key Vault des spokes gelesen wird
Verbindung	Eine Fabric-Verbindung vom Typ GitHubSourceControl über das VNet data gateway, Privacy Level Private
Erste Synchronisierung	Der Inhalt des workspaces gewinnt (PreferWorkspace)
Netzwerk	Eine benannte Outbound-Ausnahme für Git, nur angewendet auf workspaces mit Git-Verknüpfung und aktiviertem Outbound-Schutz
Tenant-Einstellung	GitHub-Zugriff muss im Fabric Admin Portal aktiviert sein (Voraussetzungen)

Im Basis-Setup hat nur der Development-workspace eine Git-Verknüpfung. Production-workspaces werden über CI/CD-pipelines deployt. Wird die Git-Verknüpfung aus der Konfiguration entfernt, wird Git vom workspace getrennt.

Entwicklerzugriff

Entwickler erreichen die workspaces über VPN oder ExpressRoute. Ohne Verbindung zum Plattform-Netzwerk gibt es keinen Pfad zum workspace.

Anfrage

Füge eine Verbindung über Anfragen und Änderungen hinzu, ändere oder lösche sie. Nenne die Umgebung, den workspace, die Quelle und für die Zugangsdaten die Namen der Secrets (niemals die Werte).