FabricFabricAirlift
Fabric family integrations

Databricks access & integrations

Inspect the observed access state of an Airlift App deployment and the fail-closed state of its Databricks target integrations.

Databricks access & integrations

DBX1 status: this release implements and tests the access contract in the repository. It does not claim live closure until an immutable same-digest App deployment and workspace preflight are admitted for the target workspace.

Airlift renders one observed view of two distinct surfaces:

  • Deployment access — whether the Airlift App can actually reach the workspace resources it operates against: identity, organization membership, App permission, the bound SQL warehouse, and every configured surface (analytics schema, evidence Volume, model route, Genie Agent, system tables).
  • Target integrations — the five construct-independent Databricks integrations: Unity Catalog governance, Unity Catalog lineage, Unity AI Gateway, AI/BI reporting, and Databricks Genie analytics.

These surfaces share one observed-state vocabulary but answer different questions. An access preflight proves reachability; it is never integration readiness.

One shared observed-state vocabulary

Both surfaces render through the same five tokens:

StateMeaning
not_configuredNo admitted configuration for this integration.
not_observedConfigured, but no admitted workspace observation.
staleThe last admitted observation is outside its freshness window.
blockedA named blocker prevents observation.
observedA current admitted observation exists.

A preflight's observed state means "an admitted probe just proved the deployment reaches the workspace". An integration's observed state requires admitted capability evidence of workspace strength admitted through the capability registry — a stricter contract that no configuration, screenshot, dashboard tile, or model output can manufacture. No configuration flag ever renders as readiness.

Access preflight contract

The governed action airlift.access_preflight_record records one preflight observation:

  • Actor bound. Only an admitted system principal can record. Humans and agents are rejected by the airlift.access_preflight_admission.v1 policy, and the handler restates the bound.
  • Admission. A missing or unverifiable evidence identity fails closed. The deployment supplies an access-probe verifier seam; absent, the admission policy blocks.
  • Required coverage. Deployment evidence requires the App principal's observable identity and sql_warehouse checks plus every configured native surface. Participant evidence additionally requires organization_membership and app_permission, derived from the governed directory and the live delegated App request. Partial coverage, an undeclared check, or a required check marked not_applicable is rejected.
  • Derived fields. The pipeline derives the preflight digest, the per-check states, and the overall state. Caller-supplied derived fields are rejected by the strict schema; the CLI strips them before transport as a defense in depth.
  • Secret-safe output. Credential references and userinfo are rejected at both the action params schema and the recorded-event schema.
  • Replay. Malformed or digest-mismatched replays are dropped whole; a capped history keeps the newest records. The retained history also bounds the duplicate-digest guard: an evicted record's digest can be recorded again, though its freshness window will render it stale rather than observed.
  • Production seam. Governed deployments currently fail closed: no production runtime wires an admitted access-probe verifier yet, so no governed deployment can record a preflight until one is admitted. That is the deliberate, honest default — a permissive production verifier would admit arbitrary evidence. The demo environment seeds one passing preflight behind the development-assurance boundary only.

Record a preflight through the admitted probe path:

fa access record \
  --file .airlift/access-preflight.json \
  --idempotency-key access-preflight-<run-id>

Inspect the derived surface — exit 0 only when access is observed, so it works as a CI gate:

fa access show
fa access show --json

The App renders the same derivation at the Databricks access & integrations page. That page is read-only: recording is an admitted system action, and no browser form escalates a human to a system principal.

Check my workspace access

The deployed Databricks App adds one task-oriented action to the Workspace readiness section: Check my workspace access. It exists so an operator can prove reachability before migration work starts instead of discovering a missing grant mid-stage.

Pressing the button runs two checks against Databricks directly and records both through the governed system action airlift.access_preflight_record under the admitted worker principal — the button never mints its own evidence:

  • Participant check — probes with the signed-in person's delegated Databricks session (on-behalf-of). It proves what you can reach: identity, organization membership, App permission, the SQL warehouse, and the configured native surfaces.
  • Deployment check — probes as the App's own service principal. It proves what the deployment can reach when no person is signed in.

Both preflights are admitted with an idempotency key bound to the evidence digest, so a retry of the same outcome collapses to the original record. The result renders as migration impact, owner, and next step: either "Workspace access is ready for this migration", or a count of items needing attention with each blocker's five-part explanation below the button (what happened, why it blocks migration, who can fix it, the required evidence, and one primary action).

A denied or blocked state is a precondition answer, not a malfunction:

MessageMeaningRecovery
Workspace sign-in required.No authenticated App session.Sign in to the workspace App and retry.
This workspace is not available for your Airlift account.Your identity resolves to no membership in this organization.Ask a tenant admin to grant membership on the Team access page.
Your Airlift role cannot run workspace checks.Your role lacks airlift:access:observe.Ask an admin for a role that carries access-observe permission.
Databricks did not provide a delegated workspace session.The App received no on-behalf-of session, so the participant lane cannot run.Reopen the App from the workspace so Databricks forwards a delegated identity.
N workspace items need attention.One or more probe checks did not pass.Apply the named fix (usually a grant named in the blocker), then press the button again.
The workspace check could not finish.The probe itself errored.Retry once; if it persists, ask a workspace admin.

Successful checks are throttled to one run per person per 30 seconds; a failed result is never cached, so a fix-then-retry loop is never blocked by the throttle. The same blocked-state vocabulary appears in the Fix list — a failed check is normal specialist work with a named owner, never a silent zero.

Blockers

Every non-observed access state renders a five-part blocker: what happened, why it matters, who acts, the required evidence, and one primary action. A denied permission names the grant; a missing check names the coverage; a stale preflight names the window.

Honest support boundary

Access observations never raise a Databricks target integration to observed. The five integrations stay not_configured, not_observed, stale, or blocked until admitted workspace-strength evidence lands through the governed capability registry. The bounded Airlift migration assistant is a separate surface from Databricks Genie analytics; see Airlift Migration Assistant for its model-routing contract.

On this page