Spark-stöd för OneLake-säkerhet (RLS och CLS)

Fabric Spark integreras med OneLake-säkerhet så att principer för säkerhet på radnivå (RLS) och säkerhet på kolumnnivå (CLS) som definierats en gång i OneLake tillämpas konsekvent när användare läser Delta-tabeller på lakehouse från Spark-notebook-filer och Spark-jobbdefinitioner. Användarna fortsätter att skriva Vanliga Spark SQL- eller DataFrame-frågor. Spark filtrerar resultatet transparent så att varje användare bara ser de rader och kolumner som de har behörighet att komma åt.

Den här artikeln förklarar hur Spark fungerar med OneLake-säkerhet, inklusive tvingande arkitektur, dataförberedelseflödet, användarupplevelsen och de scenarier och gränser som stöds.

Anmärkning

För principredigering och den tvärgående motormodellen, se Säkerhet på radnivå i OneLake och Säkerhet på kolumnnivå i OneLake.

Begrepp i korthet

  • En enda sanningskälla. RLS-regler och CLS-kolumnlistor definieras vid ett tillfälle på lakehouset genom säkerhetsroller i OneLake. Spark lagrar eller duplicerar inte principen.
  • Effektiv motoragnostisk åtkomst. OneLake returnerar den förberäknade effektiva åtkomsten för den begärande användaren, inklusive tillåtna kolumner och RLS-radfiltermetadata. Spark använder den effektiva åtkomsten vid frågetillfället.
  • Deltafiltrering. OneLake- och Fabric-plattformslagret tillämpar endast RLS- och CLS på Delta-parquet-tabeller. Icke-Delta-objekt med regler som tillämpas blockeras av plattformen i stället för att filtreras av Spark.
  • Privilegierade roller kringgås. Beteendet hos OneLake och Fabric-plattformen innebär att rollerna Admin, Member och Contributor i arbetsytan inte begränsas av RLS eller CLS. Filtrering gäller för Viewer och för användare som beviljats åtkomst via OneLake-säkerhetsroller.

Så tillämpar Spark OneLake-säkerhet

När en användare skickar en fråga som berör en säker lakehouse-tabell, förbereder Spark en körningsplan som kombinerar användarens fråga med den effektiva OneLake-säkerhetsåtkomsten för den användaren. Verkställighet sker under körningen, inte som ett steg efter filter i användarkoden, så det kan inte kringgås av alternativa API:er eller sökvägsbaserade läsningar.

Körningsmodell med två kontexter

Fabric Spark använder två körningskontexter för att hålla principutvärderingen isolerad från användarkoden:

  • Användarkontext. Kör användarens notebook- eller Spark-jobbdefinition med användarens identitet. Den här kontexten planerar frågan och använder filtrerade utdata, men den har aldrig direkt, ofiltrerad åtkomst till skyddade tabeller.
  • Systemkontext (säkerhet). En privilegierad, Microsoft hanterad kontext som löser användarens effektiva åtkomst mot OneLake, läser de underliggande Delta-filerna, tillämpar RLS-radfiltrering och CLS-projektioner och returnerar endast de rader och kolumner som användaren får se.

Systemkontexten visas i övervakningshubben som jobb som SparkSecurityControl körs tillsammans med användarens notebook-session. Jobbnamnet och övervakningsupplevelsen är Fabric plattformsbeteende. De här jobben förväntas och anger att OneLake-säkerhetstillämpningen är aktiv.

Frågeflöde för en skyddad tabell

  1. Användaren kör en fråga i en Spark-anteckningsbok, till exempel SELECT * FROM lakehouse.sales.
  2. Spark löser upp tabellen genom Lakehouse-katalogen och upptäcker att OneLake-säkerhet har aktiverats.
  3. Spark begär effektiv åtkomst för den aktuella användaren från OneLake. Svaret innehåller de tillåtna kolumnlistorna (CLS) och RLS-radfiltermetadata.
  4. Systemsäkerhetskontexten läser Delta-filerna, projicerar endast de tillåtna kolumnerna och tillämpar RLS med hjälp av bitmappsformat eller radfiltrering i borttagningsvektorformat under körningen.
  5. Det filtrerade resultatet skickas tillbaka till användarkontexten, som slutför resten av användarens fråga (kopplingar, sammansättningar, skrivningar till icke-skyddade mål och så vidare) över redan filtrerade data.

Vad händer för varje principtyp

Policy Det som Spark returnerar Notes
Endast RLS Alla kolumner, men bara de rader som tillåts av RLS-regeln. Radfiltrering tillämpas i säkerhetskontexten med hjälp av filtrering i bitmappsformat eller borttagningsvektorformat. användarna kan inte observera filterlogik.
Endast CLS Endast de tillåtna kolumnerna; alla rader. SELECT * lyckas och returnerar de tillåtna kolumnerna när minst en kolumn tillåts. Om inga kolumner tillåts misslyckas Spark med frågan.
RLS + CLS i samma roll Tillåtna rader projiceras på tillåtna kolumner. Stöds så länge båda reglerna tillhör samma roll.
RLS i roll A, CLS i roll B (samma användare) Sökningen misslyckades. OneLake- och Fabric-plattformsskiktet stöder inte att en användare är medlem i två roller där den ena definierar RLS och den andra definierar CLS. Se Säkerhet på radnivå och Säkerhet på kolumnnivå.
Icke-Delta-objekt Åtkomsten har blockerats. OneLake- och Fabric-plattformslagret tillämpar endast RLS och CLS på Delta-parquet-tabeller. Andra objekt i en skyddad roll blockeras.

De kanoniska redigeringsreglerna och RLS-uttryckssyntaxen finns i artiklarna säkerhet på radnivå och säkerhet på kolumnnivå .

Så här förbereder Spark data för användare

OneLake-säkerhet är utformad för att vara transparent för datakonsumenten. Användarna fortsätter att använda de API:er som de redan känner till, och Spark hanterar principmatchning och filtrering för deras räkning.

Spark SQL

-- Returns only rows and columns the current user is authorized to see.
SELECT product_category, SUM(amount) AS total
FROM sales.transactions
GROUP BY product_category;

PySpark DataFrame

df = spark.read.table("sales.transactions")
df.filter("region = 'EMEA'").groupBy("product_category").sum("amount").show()

I båda exemplen filtreras tabelldata transactions som läses in i DataFrame redan av OneLake-säkerhet. Efterföljande transformeringar körs endast över filtrerade data.

Direkt filåtkomst blockeras

Direkt sökvägsåtkomst kringgår princip för lakehouse-kataloglösning. När OneLake-säkerhet är aktiverat i en tabell blockerar OneLake- och Fabric-plattformsskiktet följande mönster för icke-privilegierade användare:

  • spark.read.format("delta").load("abfss://...")
  • DeltaTable.forPath(spark, "abfss://...")
  • OneLake REST/SDK läser från mappen Tables/<table> för en skyddad tabell.

Användare måste komma åt skyddade tabeller via lakehouse-tabellnamnet (till exempel spark.read.table("lakehouse.table") Spark SQL) så att Spark kan matcha och tillämpa den effektiva åtkomsten.

Användarupplevelse

  • Transparent filtrering. Ingen frågeomskrivning eller särskild syntax krävs. Samma notebook-fil fungerar för användare med olika roller och returnerar rollspecifika data.
  • Konsekventa resultat mellan motorer. Samma RLS-regel och CLS-projektion som tillämpas i Spark tillämpas också i SQL-analysslutpunkten, semantiska modeller som bygger på Direct Lake och auktoriserade motorer från tredje part. Se Översikt över OneLake-säkerhetsintegreringar.
  • Privilegierade roller ser allt. Inom OneLake och Fabric plattformarnas funktionalitet fortsätter Admin, Member, och Contributor användare att se ofiltrerade data, detta är användbart för pipelineutveckling, tabellunderhåll (OPTIMIZE, VACUUM) och felsökning.
  • Övervakning. Jobben SparkSecurityControl som visas i övervakningshubben motsvarar den systemkontext som utför genomdrivande av riktlinjer. Jobbnamnet och posten i Övervakningshubben ingår i Fabric plattformens drift.

Skärmbild av platshållare: Övervakningshubben som visar ett SparkSecurityControl-jobb tillsammans med användarens notebook-session.

Prestandaöverväganden

  • RLS-radfiltrering. RLS tillämpas nära Delta-genomsökningen med hjälp av bitmapps- eller borttagningsvektorfiltrering, och där det stöds, Native Execution Engine. Den här designen minimerar de rader som materialiseras i användarkontexten.
  • Kolumnrensning. CLS-kolumnlistor kombineras med användarens projektion. Endast skärningspunkten lästs från Delta-lagringen.
  • Effektiv åtkomstcache. Spark cachar policy och metadata för effektiv åtkomst per fråga och rensar dem när frågan avslutas.
  • Partitions- och statistikanvändning. Standard-deltapartitionsrensning och datahoppning fortsätter att gälla med RLS-radfiltrering, så frågor mot partitionerade tabeller förblir effektiva.

Scenarier som stöds

  • Läsa Lakehouse Delta-tabeller i Spark-notebook-filer och Spark-jobbdefinitioner via lakehouse-katalogen (<lakehouse>.<table>).
  • Spark SQL- och PySpark/Scala DataFrame-API:er mot skyddade tabeller.
  • Kopplingar, aggregeringar och underordnade transformeringar i skyddade tabeller.
  • Skrivningar från skyddade källor till icke-skyddade utdata. Utdatatabeller som skrivs utanför den skyddade lakehouse-miljön innehåller endast de data som den skrivande användaren tilläts läsa.
  • Åtkomst mellan arbetsytor i lakehouse via genvägar, där källsjöhuset har OneLake-säkerhet aktiverat.

Limitations

OneLake Security RLS och CLS i Spark ärver de övergripande Säkerhetsbegränsningarna för OneLake. Viktiga beteenden och gränser är:

  • Spark RLS/CLS-implementeringen stöder inte tjänstekonton; det är endast användaridentiteter som utvärderas för säkerhetsprinciper på rad- och kolumnnivå. När du använder notebook-filer med arbetsyteidentitet, tillämpas inte RLS/CLS för själva arbetsyteidentiteten, utan endast för de enskilda användare som kör frågorna inom ramen för notebook-miljön.
  • Plattformskiktet OneLake och Fabric tillämpar RLS och CLS endast på Delta parquet-tabeller. Icke-Delta-objekt i en skyddad roll blockeras.
  • OneLake- och Fabric-plattformsskiktet blockerar direkt sökvägsläsningar (abfss://, DeltaTable.forPath) mot skyddade tabeller för icke-privilegierade användare.
  • Plattformsskiktet OneLake och Fabric stöder inte att en användare är medlem i två roller där den ena definierar RLS och den andra definierar CLS för de berörda tabellerna.
  • Som ett beteende hos OneLake- och Fabric-plattformen kringgår rollerna Admin, Member och Contributor RLS och CLS.
  • Skrivningar till icke-skyddade utdata från skyddade källor stöds och körs på redan filtrerade data. Skrivningar (INSERT/UPDATE/DELETE/MERGE) till ett skyddat mål kan inte stödjas för användare som omfattas av RLS eller CLS. använd en privilegierad identitet för ETL-skrivningar till skyddade tabeller.

Relaterat innehåll

  • Last updated on