Databricks stellt zwei neue Apache-Iceberg-Spezifikationen für katalogübergreifende Governance vor
Databricks describes two new Apache Iceberg specs, read restrictions and catalog labels, aimed at standardizing policy enforcement across engines and catalogs.
Kurze Antwort
Was hat Databricks zur Governance im Open Lakehouse angekündigt?
Databricks says the Apache Iceberg community has adopted two new specifications, read restrictions and catalog labels, to the Iceberg REST Catalog. Read restrictions let catalogs delegate policy enforcement to trusted engines, while catalog labels let catalogs exchange governance metadata, such as PII tags, across federated systems like Unity Catalog and Snowflake.
Das Wichtigste
- Databricks reports that the Apache Iceberg community has advanced two additions to the Iceberg REST Catalog: read restrictions and catalog labels.
- Leserechte erlauben es einem Katalog, die Zugriffsrichtlinie für einen Nutzer auszuwerten und Anweisungen für Zeilenfilter und Spaltenprojektionen zurückzugeben, die eine vertrauenswürdige Engine – etwa ein sicher konfiguriertes Trino-Deployment – durchsetzen muss; nicht vertrauenswürdige Engines wie Spark oder DuckDB erfordern laut Databricks stattdessen eine zentrale Durchsetzung.
- Databricks states the read restrictions spec defines nine predefined column-projection actions and standardized row-filter expressions, but does not define how a catalog establishes trust with an engine.
- Laut Databricks ermöglichen Catalog Labels es Katalogen wie Unity Catalog, Snowflake, AWS Lake Formation und Google Cloud Knowledge Catalog, Metadaten in Form von Schlüssel-Wert-Paaren auf Tabellen- und Spaltenebene auszutauschen, die der empfangende Katalog dann in sein eigenes Tagging- oder Policy-Modell überführt.
- Databricks notes that labels are opaque key-value pairs with no shared semantics, so enterprises still need their own conventions to interpret them consistently across catalogs.
Databricks hat Details zu zwei neuen Spezifikationen veröffentlicht, die von der Apache-Iceberg-Community für den Iceberg REST Catalog übernommen wurden: Leseeinschränkungen und Katalog-Labels. Beide sollen laut dem Unternehmen standardisieren, wie Governance-Richtlinien durchgesetzt werden, wenn auf Daten über verschiedene Compute-Engines und föderierte Kataloge hinweg zugegriffen wird.
Leseeinschränkungen
Databricks beschreibt Leseeinschränkungen als Antwort auf ein häufiges Szenario, in dem eine Organisation Daten in einem Katalog verwaltet, sie aber mit unterschiedlichen Engines oder Tools abfragen möchte. In diesem Modell bewertet der Katalog Identität und Kontext eines anfragenden Nutzers, entscheidet, welche Zeilenfilter oder Spaltenmaskierungen gelten, und übergibt diese Einschränkungen an eine Engine, der er zutraut, sie durchzusetzen.
Databricks grenzt dies von der zentralisierten Durchsetzung ab, bei der sämtliche Schritte innerhalb der eigenen Umgebung des Katalogs ablaufen. Als Beispiel nennt das Unternehmen seine eigene Implementierung: Databricks wende feingranulare Zugriffskontrolle auf dediziertem Compute an, indem Abfragen über eine sogenannte Secure Filtering Fleet geleitet würden, und die Cross-Engine-ABAC-Funktion von Unity Catalog erweitere dies über die Scan- und Plan-APIs des Iceberg REST Catalog auf andere Engines.
Bei der delegierten Durchsetzung erhalte die Engine laut Databricks nicht die Richtlinie in der Form, wie ein Administrator sie verfasst hat, sondern die daraus resultierenden Filter- oder Maskierungsanweisungen für den jeweiligen Nutzer. Die erste Spezifikation definiere neun vorgegebene Aktionen zur Spaltenprojektion sowie standardisierte Ausdrücke für Zeilenfilter, etwa Vergleiche oder Mengenzugehörigkeiten; Richtlinien, die auf Subqueries, Lookup-Tabellen oder benutzerdefinierten UDFs beruhen, ließen sich derzeit auf diese Weise nicht abbilden.
Databricks weist zudem darauf hin, dass die Spezifikation nicht festlegt, wie ein Katalog feststellt, dass eine Engine vertrauenswürdig ist. Eine bloße Behauptung des Clients reiche nicht aus, Systemadministratoren müssten eigene Sicherheitsmechanismen anwenden. Das Unternehmen verweist auf Diskussionen in der Iceberg-Community, in denen Optionen wie mTLS und OAuth erwogen wurden, betont aber, dass Vertrauen außerhalb des eigentlichen Protokolls bleibt. Als Beispiel für eine vertrauenswürdige Engine nennt Databricks eine sicher konfigurierte Trino-Instanz, während Spark und DuckDB als nicht vertrauenswürdig gelten, wenn Nutzer die Laufzeitumgebung kontrollieren und beliebigen Code ausführen können.
Katalog-Labels
Die zweite Spezifikation, Katalog-Labels, adressiert laut Databricks die Governance über föderierte Kataloge hinweg. Viele Unternehmen verbänden inzwischen mehrere Kataloge miteinander, darunter Unity Catalog, Snowflake, AWS Lake Formation und Google Cloud Knowledge Catalog, jeweils mit eigenen Identitätsmodellen und Richtliniensprachen.
Labels erlauben es laut Databricks einem produzierenden Katalog, Tabellen und Spalten mit leichtgewichtigen Schlüssel-Wert-Metadaten zu versehen, die ein konsumierender Katalog anschließend in seine eigenen Klassifizierungen oder sein Tagging-System überführt, bevor er seine nativen Richtlinien anwendet. Als Beispiel beschreibt das Unternehmen einen produzierenden Katalog, der eine Spalte mit „ssn" als „pii=ssn" kennzeichnet – ein konsumierender Katalog könnte dies nutzen, um eine Maskierungsrichtlinie auszulösen.
Da die Durchsetzung lokal beim konsumierenden Katalog verbleibe, bewahre laut Databricks jedes System seine eigene Ausdrucksstärke bei Richtlinien und führe unabhängige Audit-Trails, ohne für jede Zugriffsentscheidung einen anderen Katalog kontaktieren zu müssen. Das Unternehmen warnt jedoch, dass Labels opake Schlüssel-Wert-Paare ohne gemeinsame Semantik oder vom Standard definierte stabile Bezeichner seien – ein konsumierender Katalog sehe also nur das aufgelöste Label, nicht den ursprünglich beabsichtigten Zweck. Unternehmen benötigten daher weiterhin eigene Konventionen oder explizite Zuordnungen, um Labels konsistent zu interpretieren.
Anwendung der beiden Modelle
Databricks fasst die Wahl zwischen den Ansätzen als abhängig vom Ziel zusammen: zentralisierte Durchsetzung für nicht vertrauenswürdige Engines, Leseeinschränkungen für vertrauenswürdige Engines und Katalog-Labels für die Föderation zwischen Katalogen.
Quelle: Databricks Blog, „Unifying governance across engines and catalogs in the Open Lakehouse", veröffentlicht am 10. September 2026.
Häufige Fragen
- Was sind Leserechtsbeschränkungen?
- Databricks describes read restrictions as a new Iceberg REST Catalog contract in which a catalog evaluates access policy for a requesting user and returns row-filter and column-projection instructions that a trusted engine must enforce when reading a table.
- Was sind Katalogbezeichnungen?
- According to Databricks, catalog labels let a producing catalog attach key-value metadata, such as marking a column as containing PII, to tables and columns, which a consuming catalog can map into its own governance model during federation.
- Welche Suchmaschinen gelten bei Leseeinschränkungen als vertrauenswürdig?
- Databricks gives a securely configured Trino deployment as an example of a trusted engine, since it provides native enforcement of row filters and column masks, while it lists Spark and DuckDB as untrusted when users control the runtime.
- Definiert die Spezifikation der Leserechte-Beschränkungen, wie Vertrauen hergestellt wird?
- No. Databricks says the specification defines what a trusted engine must enforce but not how a catalog verifies that trust, noting the Iceberg community has discussed mechanisms such as mTLS and OAuth.