Het probleem van de leverancier is niet de toegang, maar de niet-gecontroleerde schrijftoegang.
In een recent topic op het Databricks Community-forum kwam een scenario naar voren dat de meeste platformteams herkennen: een externe leverancier moet notebooks, jobs en pipelines ontwikkelen en implementeren in je workspace, maar je hebt geen mechanisme om te voorkomen dat ze productieobjecten rechtstreeks bewerken. De leverancier heeft CAN_EDIT-rechten op gedeelde mappen, omdat iemand die nodig had om "snel werk af te ronden". Nu ontdekt je wijzigingen in productienotebooks zonder pull request, zonder review en zonder mogelijkheid tot terugdraaien.
De eerste reactie is om de toegang volledig in te trekken, maar dat remt de leveringssnelheid. Leveranciers moeten productiecode kunnen lezen om de bestaande logica te begrijpen. Ze moeten jobs kunnen uitvoeren om hun werk te valideren. Wat ze niet zouden moeten kunnen, is wijzigingen in productiepaden doorvoeren zonder de beoordeling van je team.
Databricks biedt geen enkele "alleen-lezen leveranciersmodus"-schakelaar. In plaats daarvan stelt je de beveiliging samen uit vier mechanismen: maprechten in de workspace, service principals, Git-mappen en Unity Catalog. Elk mechanisme dekt een ander aanvalsoppervlak. Maprechten bepalen wie workspace objecten kan bewerken. Serviceprincipals bepalen hoe code de productieomgeving bereikt. Git-mappen dwingen versiebeheer af als implementatiepad. Unity Catalog regelt de gegevenstoegang onafhankelijk van de werkruimterechten.
Als je een van deze lagen overslaat, ontstaat er een hiaat. Een leverancier met CAN_EDIT-rechten op een map kan een notebook overschrijven, zelfs als je Git-mappen hebt geconfigureerd, omdat Git-mappen bestanden buiten het repositorypad niet met terugwerkende kracht beschermen. Een leverancier met Unity Catalog SELECT-rechten, maar zonder schrijfrechten voor de werkruimte, kan je gegevens nog steeds lezen via een SQL-datawarehouse zonder je notebooks aan te raken, wat wellicht precies is wat je wilt.
Mapmachtigingen worden van boven naar beneden overgenomen — gebruik dat om een machtigingsgrens te creëren.
De machtigingen voor Databricks-werkruimtes volgen een top-down overervingsmodel. Wanneer je CAN_VIEW toekent aan een map, erft elk notebook, bestand en submap daarin die machtiging, tenzij deze expliciet wordt overschreven. Dit is de eerste en meest directe controle die je hebt over de toegang van leveranciers.
Het praktische patroon is een structuur met drie mappen in de root van de werkruimte:
/Production — De leveranciersgroep krijgt CAN_VIEW. Alleen de service principal van je platformteam en de beheerders van de werkruimte behouden CAN_MANAGE. Leveranciers kunnen elk notebook in productie lezen om de bestaande logica te begrijpen, maar kunnen hier niets bewerken of uitvoeren.
/Development — De leveranciersgroep krijgt CAN_EDIT. Dit is hun sandbox. Ze maken notebooks, itereren op code en voeren interactieve clusters uit. Niets hier wordt naar productie geïmplementeerd zonder je CI/CD-pipeline te doorlopen.
/Staging — De leveranciersgroep krijgt CAN_RUN, maar niet CAN_EDIT. je CI/CD-pipeline implementeert code hier voor integratietesten. Leveranciers kunnen tests uitvoeren om het gedrag te valideren, maar kunnen de geïmplementeerde artefacten niet wijzigen.
Stel deze machtigingen in met behulp van de Databricks Permissions API in plaats van de gebruikersinterface om ervoor te zorgen dat ze reproduceerbaar en controleerbaar zijn. Het endpoint is PUT /api/2.0/permissions/directories/{directory_id} met een JSON-body die de toegangscontrolelijst specificeert. Script dit in Terraform of je IaC-tool, zodat de machtigingen behouden blijven na het opnieuw aanmaken van de workspace.
Een belangrijk detail: workspace-beheerders hebben automatisch de status CAN_MANAGE op alle objecten. Als een gebruiker van een leverancier de status van workspace-beheerder heeft – zelfs tijdelijk toegekend voor het oplossen van problemen – wordt je volledige machtigingsstructuur omzeild. Controleer maandelijks het lidmaatschap van de beheerdersgroep. Met de Databricks SCIM API (GET /api/2.0/preview/scim/v2/Groups) kunt je de groep admins programmatisch opvragen.
Serviceprincipes maken van de inzet een knelpunt dat je onder controle hebt.
Maprechten voorkomen dat een leverancier een productienotebook in de gebruikersinterface kan bewerken. Maar als de persoonlijke inloggegevens van de leverancier worden gebruikt om implementatiescripts uit te voeren, is er nog steeds geen scheiding tussen hun code en de productieomgeving. Serviceprincipals lossen dit op door de menselijke identiteit te scheiden van de implementatie-identiteit.
Een service principal is een niet-menselijke identiteit in Databricks die authenticatie uitvoert via OAuth-tokens of persoonlijke toegangstokens. Maak er een aan voor je CI/CD-pipeline – noem deze sp-cicd-prod. Geef sp-cicd-prod de rechten CAN_MANAGE op /Production en /Staging. Geef deze verder geen andere rechten. Nu bereikt code de productieomgeving alleen nog via de pipeline die authenticatie uitvoert met deze service principal.
Leveranciers dienen pull-requests in bij je Git-repository. je CI/CD-systeem (GitHub Actions, Azure DevOps, GitLab CI) authenticeert als sp-cicd-prod, voert databricks workspace import of de Databricks Asset Bundles CLI (databricks bundle deploy) uit en pusht gevalideerde code naar de productiemap. De leverancier heeft nooit de inloggegevens die naar de productieomgeving schrijven.
Maak de service principal aan op accountniveau via de Account SCIM API: POST /api/2.0/accounts/{account_id}/scim/v2/ServicePrincipals. Voeg deze vervolgens toe aan je workspace en wijs machtigingen toe. Bewaar het OAuth-geheim in de geheimbeheerder van je CI/CD-platform — Azure Key Vault, GitHub Secrets of AWS Secrets Manager — nooit in een gedeeld notitieboek of workspace bestand.
De service principal wordt ook de eigenaar van de productietaken. Dit is belangrijk omdat Databricks-taken worden uitgevoerd met de machtigingen van de eigenaar. Als een leverancier een taak aanmaakt onder zijn eigen identiteit en vervolgens de opdracht verlaat, wordt die taak bij de volgende uitvoering niet meer correct uitgevoerd. Het eigenaarschap van de service principal blijft behouden bij personeelswijzigingen. Stel het veld 'eigenaar' expliciet in je taakdefinities in met behulp van het veld owner_user_name van de Jobs API (dat, ondanks de naam, applicatie-ID's van service principals accepteert).
Git-mappen handhaven de beoordelingspoort die alleen door machtigingen niet mogelijk is.
Machtigingen en service principals bepalen wie code kan schrijven en hoe deze wordt geïmplementeerd. Git-mappen voegen een derde dimensie toe: ze maken versiebeheer en peer review een structurele vereiste in plaats van een beleidsdocument dat niemand leest.
Databricks Git-mappen (voorheen Repos) klonen een externe Git-repository naar de werkruimte. Wanneer een leverancier in een Git-map werkt, wordt elke wijziging die hij of zij aanbrengt, bijgehouden als een lokale wijziging van de gekloonde branch. Om hun code in de hoofdbranch te krijgen, moeten ze committen, pushen en een pull request openen – die je team beoordeelt voordat de code wordt samengevoegd.
Het probleem zit hem in het feit dat Git-mappen naast gewone werkruimte-notebooks bestaan. Een leverancier met CAN_EDIT op een map die geen Git-map is, kan een gewone notebook maken en uitvoeren wat hij of zij wil. Dit is waar mapmachtigingen en Git-mappen elkaar versterken. Als de leveranciersgroep alleen CAN_EDIT heeft in /Development/vendor-name en die map een Git-map is die is gekoppeld aan je repository, dan wordt elke bewerking die ze uitvoeren standaard onder versiebeheer geplaatst.
Beheerders kunnen ook een lijst met toegestane Git-URL's configureren op werkruimteniveau. Hiermee wordt beperkt welke externe repositories in de werkruimte gekloond kunnen worden. Als je leverancier probeert een Git-map te koppelen aan hun eigen privérepository – een repository die je niet kunt controleren – blokkeert de lijst dit. Configureer dit via de beheerdersconsole onder Werkruimte-instellingen > Git-integratie, of via de Workspace Conf API: PATCH /api/2.0/workspace-conf met {"enableGitUrlRestriction": "true", "gitUrlAllowList": "https://github.com/your-org/*"}.
Combineer dit met regels voor branchbeveiliging bij je Git-provider. Vereis ten minste één goedkeuring van je interne team voordat er merges naar de main- of production-branches plaatsvinden. De code van de leverancier wordt beoordeeld. De service principal implementeert alleen vanuit de beveiligde branch. De keten is compleet.
Unity Catalog scheidt gegevenstoegang van schrijftoegang tot de werkruimte.
Een leverancier die geen productienotebooks kan bewerken, moet mogelijk nog steeds productiedata kunnen opvragen – bijvoorbeeld om transformaties te valideren, problemen op te sporen of rapporten te genereren. Unity Catalog biedt de mogelijkheid om datatoegang te verlenen zonder toegang tot werkruimteobjecten te verlenen. Dit is de scheiding die de meeste teams over het hoofd zien bij het instellen van leveranciersrechten.
Verleen de leveranciersgroep SELECT-rechten op specifieke catalogi, schema's of tabellen met behulp van standaard SQL: GRANT SELECT ON SCHEMA main.vendor_project TO vendor_group. Ze kunnen deze data opvragen via een SQL-warehouse of een interactief cluster zonder schrijfrechten te hebben op werkruimtemappen. Voor schrijfrechten op ontwikkeltabellen verleent je deze alleen op een ontwikkel catalogus: GRANT ALL PRIVILEGES ON SCHEMA dev.vendor_project TO vendor_group.
Deze gelaagdheid betekent dat een leverancier SELECT * FROM main.sales.orders kan uitvoeren in een SQL-editor, maar de notebook die deze data transformeert in productie niet kan wijzigen. Ze bouwen en testen hun transformaties in de ontwikkel catalogus, dienen code in via Git, en je CI/CD-pipeline implementeert de gecontroleerde code naar productie, waar deze werkt met productiedata onder de identiteit van de service principal.
Controleer alles. Unity Catalog genereert systeemtabellen in system.access.audit die elke gebeurtenis met betrekking tot gegevenstoegang vastleggen, inclusief welke principal welke tabel heeft benaderd en wanneer. Voer wekelijks een query uit: SELECT * FROM system.access.audit WHERE action_name = 'getTable' AND request_params.principal_name LIKE 'vendor%' AND event_date > current_date - 7. Dit geeft je een concreet overzicht van waartoe je leveranciers toegang hebben gehad, wat belangrijk is voor compliance en voor de onvermijdelijke toegangscontrole na de implementatie.
MetricSign monitort de uitvoering van Databricks-taken en toont fouten met context over de onderliggende oorzaak, inclusief permissie fouten die optreden wanneer de rechten van een service principal verkeerd zijn geconfigureerd of een Unity Catalog-privilege ontbreekt. Wanneer een productietaak mislukt omdat sp-cicd-prod na een catalogus migratie de SELECT-rechten op een tabel is kwijtgeraakt, groepeert MetricSign die fout met de specifieke machtigingsfout in plaats van deze te verbergen in een algemene melding van een mislukte taak.
De vierlaagse audit: controleer of je controles daadwerkelijk effectief zijn.
Configuratieafwijkingen zijn de grootste vijand. Tijdens de onboarding van de leverancier configureert je mapmachtigingen, service principals, Git-mappen en Unity Catalog-rechten. Zes maanden later verleent iemand de machtiging CAN_EDIT aan een productiemap om een urgente bug op te lossen. Deze machtiging blijft permanent van kracht.
Maak een script voor een kwartaalaudit dat alle vier de lagen controleert. Voor mapmachtigingen roept je GET /api/2.0/permissions/directories/{id} aan voor elke productiemap en markeert je alle niet-beheerders en niet-service principal-vermeldingen met CAN_EDIT of CAN_MANAGE. Controleer voor service principals of de eigenaren van productietaken service principals zijn en geen menselijke gebruikers — raadpleeg de Jobs API (GET /api/2.1/jobs/list) en controleer het veld creator_user_name. Controleer voor Git-mappen of alle ontwikkelmappen van de leverancier zijn gekoppeld aan goedgekeurde repositories met behulp van GET /api/2.0/repos en vergelijk dit met je lijst met toegestane repositories. Voer voor Unity Catalog SHOW GRANTS ON SCHEMA main.production_schema uit en controleer of geen enkele leveranciersgroep schrijfrechten heeft op productieschema's.
Automatiseer dit als een Databricks-notebook dat wordt uitgevoerd als een geplande taak en de resultaten naar een Delta-tabel schrijft. Stel een waarschuwing in bij elke afwijking. Het script hoeft niet complex te zijn: vier API-aanroepen en vier SQL-statements dekken de cruciale controles.
Het beëindigen van de samenwerking met leveranciers is een ander aandachtspunt. Schakel bij het einde van de samenwerking de leveranciersgroep uit in plaats van individuele gebruikers te verwijderen. Het uitschakelen van de groep in je identiteitsprovider (Entra ID, Okta) wordt automatisch via SCIM naar Databricks doorgegeven. Controleer de doorgifte door GET /api/2.0/preview/scim/v2/Groups?filter=displayName eq "vendor-group" te gebruiken en te bevestigen dat de ledenlijst leeg is. Trek vervolgens de Unity Catalog-rechten expliciet in: verwijdering in SCIM heeft geen gevolgen voor de catalogus rechten.