Skip to content

SYSTEM Cited by 1 source

Lifeguard (Cloudflare Town Lake access control)

Lifeguard is the access-control service for Town Lake — Cloudflare's data platform. Introduced publicly in the 2026-05-28 launch post.

Architecture

"Lifeguard is our access control service: it stores access rules in D1, dynamically pulls user and group membership from our internal access management system, and renders a combined JSON policy that Trino reads over HTTP. Lifeguard also feeds basic access information to Skipper and the Gateway, so users get blocked at the front door rather than at query time."

Resolution flow:

user query ──► Trino ──► HTTP fetch ──► Lifeguard ──► JSON policy
                                            │
                                            ├─► D1 (access rules)
                                            ├─► internal IAM (group memberships)
                                            └─► Skimmer allowlist (per-table review state)

Three substrates feed the policy:

  • D1 — stores the access rules themselves (declarative, durable, queryable).
  • Cloudflare's internal access management system — dynamically pulled group memberships (transient, no duplication into D1).
  • Skimmer's allowlist — per-table / per-column review state (pending / approved / denied).

The combined JSON policy is rendered per request and served to Trino over HTTP — the policy isn't statically baked into the engine; it's resolved live at query time.

Front-door enforcement

The post emphasises a structural property: "Lifeguard also feeds basic access information to Skipper and the Gateway, so users get blocked at the front door rather than at query time."

The architectural argument is that agent-layer pre-authorisation (Skipper checks Lifeguard before generating SQL) avoids the wasted work of writing a query you can't run. Skipper's "if you query a table you don't have access to, the error message is not 'permission denied'. It's 'this table needs review, click here to request one'" relies on Lifeguard exposing review state, not just deny/allow.

Time-bounded permission grants

Town Lake's broader governance shape calls for "time-bounded permission grants so that users could only access data when they were actively working on tasks that required it." The launch post names this as a goal Lifeguard supports but doesn't go deeper into the mechanism — whether it's TTL on D1 access rules, session-token expiry, or both is left implicit.

Position in default-closed governance

Lifeguard is the enforcement layer of Town Lake's default-closed governance. Two collaborators bookend it:

  • Skimmer classifies columns for PII and registers tables as pending review in the allowlist. Until reviewed, columns are inaccessible — but enforcement is via Lifeguard's policy, not Skimmer directly.
  • Skipper queries Lifeguard to pre-check user authority before generating SQL, and surfaces "this table needs review, click here to request one" errors with RBAC group suggestions rather than opaque permission-denied messages.

Audit trail

The post mentions logging in the PII-redaction context: "The flip and every query is logged." The implication is that Lifeguard (or a sibling logging layer Lifeguard feeds) underpins the audit trail for Town Lake — but the specific logging mechanism is not disclosed. Sibling to existing audit-trail framings at Unity Catalog and CloudTrail.

Caveats

The launch post discloses Lifeguard's architecture and role but does not disclose:

  • Policy resolution latency (Lifeguard sits in the hot path of every Trino query).
  • Caching strategy (each query resolves policy fresh, or is there a per-session/per-token cache?).
  • D1 schema for access rules.
  • How time-bounded grants are encoded (TTL on rules, expiring tokens, both).
  • Failure-mode behaviour (Lifeguard down: do queries fail closed or cached-policy?).
  • Rate-limit / DoS posture for the HTTP policy endpoint.

Seen in

Last updated · 542 distilled / 1,571 read