Iceberg Catalog & Company Teardown
Verdict: The best-engineered subject in this series and a genuinely strong fit for a lean GCP/Iceberg stack — a single Rust binary, no JVM, pluggable authorization (OpenFGA ReBAC, OPA/Rego, Cedar), OIDC-native, secrets encrypted at rest. The credential-vending attack surface — the one thing a catalog must not get wrong — is correctly defended with real path-boundary containment. The single posture caveat is the recurring theme of this series in its mildest, most defensible form: fine-grained authorization ships off by default (AllowAll). Turn it on and this is a catalog you could stand behind.
Lakekeeper is "an Apache-Licensed, secure, fast and easy to use Apache Iceberg REST Catalog written in Rust" — the metadata control plane that mediates every engine's access to an Iceberg lakehouse. It implements the Iceberg REST spec (multi-table commits, server-side conflict resolution), authenticates via OIDC, authorizes via a pluggable backend, and manages storage access through vended, expiring credentials and remote request signing for S3, Azure, and GCS. A single ~175k-LOC Rust binary — no JVM, no Python runtime.
Its stated identity is security and governance: the creator's public writing is a "Secure Lakehouse" series on authentication and permissions across tools, and the catalog is built to be the enforcement point where "who can touch which table" is decided before any engine gets a credential.
Stated vs. structural: the "secure" claim is structurally earned — the vending scope check (§3) is the proof a naive catalog would fail. But "secure" ships with fine-grained authorization disabled by default. The security is a capability you switch on, not the out-of-the-box posture — a real distinction for anyone who deploys the default and exposes it.
A cleanly-decomposed Rust workspace: a core lakekeeper crate, a thin lakekeeper-bin, and swappable backends as separate crates — authz-openfga, an OPA bridge, and Cedar for authorization; lakekeeper-storage-postgres for metadata; lakekeeper-secrets-kv2 (HashiCorp Vault) for secrets; lakekeeper-events-kafka/-nats for change events. Everything security-relevant is a trait with multiple implementations — the sign of a team that expects to be audited.
| Decision | What they chose | Consequence |
|---|---|---|
| Runtime | Single Rust binary, no JVM/Python; Kubernetes-native | Lean, infra-light — deployable next to a GCP/Dataproc stack without dragging a JVM catalog service along. |
| Authorization | Pluggable: OpenFGA (ReBAC relationship graph), OPA/Rego bridge, Cedar, or AllowAll | The permission model is a relationship/policy graph — a direct instantiation of "the declaration graph and the IAM graph should be the same thing." OPA support means it drops into an existing Rego estate. |
| Storage access | Vended expiring credentials + remote request signing, scoped per table location | Engines never hold long-lived warehouse keys; access is minted per-load and bounded — the correct least-privilege model. |
| Secrets | Encrypted at rest via a fetch-and-decrypt secret service; Vault KV2 as external backend | Warehouse credentials aren't stored bare; external secret management is a first-class option, not a bolt-on. |
Read: a deliberately auditable control plane — cattle, built by people who assumed someone like you would read it. Backend-per-trait is exactly the structure that lets a security claim be verified rather than believed.
Inspected at repo state 2026-07-16, focused on the three things a catalog must not get wrong: does authorization actually gate every operation, is vended/signed storage access correctly scoped, and are secrets protected at rest. The engineering is strong (1,445 test functions; clean workspace hygiene). The security-critical paths hold; the one caveat is a default, not a defect.
| Finding | Detail | Status |
|---|---|---|
| Credential vending / signing is correctly scoped | Before signing an S3 request, s3_signer/sign.rs runs validate_uri(), which checks every requested location is_sublocation_of the table's location — a proper path-segment containment check, not a naive starts_with (so s3://bucket/table cannot match s3://bucket/table-secret). Requests outside the table location are rejected. The primary catalog attack surface is defended right. | Solid |
| Authorization is woven through, per-action | Table/namespace/warehouse/view/project ops each call is_allowed_*_action and raise AuthZ*ActionForbidden on failure — explicit per-operation checks against the configured backend, not a coarse gate. OpenFGA/OPA/Cedar are all in the OSS tree. | Solid |
| Fine-grained authz is OFF by default | AuthZBackend::default() is AllowAll — confirmed by an in-repo test asserting exactly that. Out of the box, any authenticated principal can do anything. It is logged at boot ("Using AllowAll authorizer") and surfaced in the UI (enable_permissions=false), so it is visible, not silent — but a deployment exposed before OIDC + OpenFGA/OPA are wired has no authorization. | Default-off |
| Secrets encrypted at rest | The secret service fetches-and-decrypts (comments and code paths confirm an encryption layer over stored credentials); Postgres is the default store, Vault KV2 the external option. Materially safer default than a bare-stored or world-key scheme. | Solid |
| Authentication is separate from authorization | OIDC authN is a distinct layer from the authz backend, so AllowAll means "authz-off," not "authn-off." The two must both be configured for a real security posture — a nuance worth stating plainly to operators. | By design |
| Open-core edition split | Vakamo ships a commercial lakekeeper-plus; some enterprise features (e.g. certain role-provider paths) differ by edition, though the core authz backends (OpenFGA/OPA/Cedar) are in OSS. Check the boundary before assuming a feature is free. | Open-core |
Read: this is the rare case where "secure" survives contact with the source. The vending scope check is the tell — it is the exact thing a catalog gets wrong when security is marketing rather than design, and here it is done correctly, with path-boundary awareness. The AllowAll default is a legitimate single-tenant/dev convenience, but it means the headline adjective is a switch, not a state.
Built by Vakamo, a German (open-core) company, on an Apache-2.0 core with a commercial lakekeeper-plus edition (present on Docker Hub and the Red Hat catalog) and a PitchBook profile indicating investor tracking. ~1,300 GitHub stars and visible in the Iceberg/Trino community circuit.
| Signal | Value | Note |
|---|---|---|
| Model | Open-core (OSS + lakekeeper-plus) | Sustainable-by-design; watch the OSS/enterprise feature line. |
| Activity | Ships daily | Latest commit 2026-07-16 (day of review); 48 releases; active CHANGELOG/release-please cadence. |
| Tests | 1,445 test functions | Heavy integration coverage incl. dedicated integration-tests crate; serious for a project this age. |
| Adoption | ~1,300 stars, early | Growing catalog-space mindshare; production references still accumulating. Single snapshot. |
The strategic tension is the open-core one: how much governance capability stays in OSS versus migrating to -plus as enterprises adopt. Nothing observed suggests core security is being held hostage — the vending scope check and the authz backends are all in the open tree.
The public face and creator is Christian Thiel (Vakamo), who presents at the Iceberg/Trino community and Siemens OpenSource events and whose written output is specifically about authentication and permissions across lakehouse tools. The domain credibility is real and, unusually, aligned with the product's claim: the security posture is not a marketing veneer over a generic catalog — it is the author's actual subject-matter expertise showing up in the code (the vending scope check reads like someone who has thought about the failure mode).
Credibility & risk signal: no contradiction between stated posture and substrate — the opposite of a "sell the fear" pattern. The honest risk is ordinary open-core risk (feature gating over time), not integrity.
Iceberg won the format war; the catalog is the 2026 battleground, and Lakekeeper competes as the security-and-openness option against heavier or vendor-aligned catalogs.
| Direction | Players | Pressure |
|---|---|---|
| Vendor-aligned catalogs | Apache Polaris (Snowflake), Unity Catalog (Databricks) | Bigger gravity and bundled ecosystems; Lakekeeper counters with true vendor-neutrality and a lean, inspectable Rust core. |
| Metadata-lake / federation | Gravitino (Datastrato), Nessie (Dremio) | Broader "unify everything" scope; Lakekeeper stays focused on being the best Iceberg REST catalog with real authz. |
| Cloud-native | AWS Glue, cloud catalogs | Zero-ops appeal on a single cloud; Lakekeeper wins on multi-cloud (S3/Azure/GCS), OIDC, and policy-engine choice. |
Read: the genuine differentiator is pluggable, policy-engine-grade authorization on a JVM-free binary — OpenFGA's relationship graph or your own OPA/Rego, enforced at the catalog. For a governance-minded, multi-cloud, lean-infra shop it is arguably the most architecturally aligned catalog on offer; the wedge is real, and it is precisely the wedge that a data-mesh/OPA practitioner is positioned to exploit.
Positioning is developer- and security-credible: "Secure Lakehouse" thought-leadership, Iceberg/Trino community presence, Data Engineering Podcast coverage, honest docs. The demand is real — the catalog layer is the hottest sub-lane of the Iceberg world in 2026 — and the framing (a neutral, secure enforcement point) matches a genuine enterprise need rather than manufacturing one.
Reception is positive and growing in the data-engineering community, but there is no adversarial code teardown of the security substrate in public — assessments to date are architectural overviews and vendor/community talks. This memo is, as far as public sources show, among the first outside-in reads of the vending/authz internals.
Read: charitable — a security-first catalog whose code genuinely backs the claim, from an author who specializes in exactly this. Uncharitable — "secure" is marketed as a property while shipping with authorization off by default, so a careless operator gets an open catalog and a false sense of safety. The evidence sits firmly toward the charitable: the hard part (scoped vending) is correct, the default is visible and documented, and the fix is one config setting — not a substrate rebuild.
AllowAll default and OSS/plus split before relying on either.AllowAll default nuance. It disables authorization, not authentication; real exposure depends on whether OIDC authn is also left unconfigured. The risk is a misconfigured deployment, not an inherent hole.