Data lakehouses promise open, flexible analytics—but security is often bolted on, not built in. As teams add more engines, users, and use cases, fragmented catalogs and ad hoc policies become a drag on innovation turning every new engine or workload into a security exception to manage. What if your governance lived with the data itself, not in every query engine you deploy?
Most lakehouse architectures still put the catalog—and therefore the control point for security—inside individual query engines. That means each engine brings its own metadata store, access model, and policy language. The result is familiar: duplicated permissions, inconsistent enforcement, and a constant race to keep security aligned across platforms. Every new engine or workload introduces friction, slowing down data scientists and application teams who just want governed access to high‑quality data.
This session explores a different design: moving the Apache Iceberg REST catalog into the persistent storage layer, specifically IBM Fusion powered by Ceph S3 object storage. Instead of treating the catalog as an engine feature, it becomes a foundational service of the lakehouse storage platform.
By anchoring the Iceberg RESTful catalog in Ceph, security and governance become query‑engine independent. IBM Fusion with Ceph S3 can enforce access through native object storage capabilities such as S3 STS (temporary credentials), IAM‑style policies, and encryption. Table‑level access control is no longer a best‑effort mapping from engine ACLs to buckets and objects; it is enforced directly at the object layer, where the data actually resides.
Attendees will see how IBM watsonx.data integrates with IBM Fusion using credential‑vending workflows. Instead of long‑lived credentials shared across tools, users receive scoped, time‑bound access to precisely the Iceberg tables and columns they are entitled to. Query engines—whether watsonx.data’s Presto/Trino, Spark, or others—simply speak Iceberg and S3, while the storage platform guarantees consistent policy enforcement underneath.
The payoff is a simpler, more resilient architecture: one catalog, one set of policies, many engines. Governance is centralized, but innovation at the query layer is unconstrained.
For data scientists, this approach removes the bottlenecks of ticket‑driven access and security reviews every time a new tool is introduced. They gain governed self‑service access to ApacheIceberg tables across engines, with clear guardrails and less friction. For enterprise architects, consolidating the catalog and access control in IBM Fusion reduces integration complexity, audit gaps, and risk. Security teams gain a single enforcement point, directly at the data, rather than a patchwork of engine‑level controls. The end result is a lakehouse that is both easier to operate and inherently more secure.
Join this session at Nvidia GTC 2026 Booth 2007 on March 16, 1:15pm to see architecture patterns, live flows, and design considerations for storage‑centric lakehouse security—and learn how to apply Iceberg REST catalogs with IBM watsonx.data and IBM Fusion in your environment.