Sharing data safely with OpenSharing

Sharing is a decision about control

Sooner or later another organisation needs your data: a supplier, a partner, a regulator, a research group. The old answers are exports, e-mailed files and shared storage keys. Each of them hands over a copy you can no longer see, update or withdraw.

OpenSharing is the Databricks data sharing platform. The current documentation uses that name. Older material, and a lot of existing code and blog posts, call it Delta Sharing. If you read both names, they refer to the same sharing approach, so search for both when you look for examples.

In this lesson we decide when to share, which kind of sharing to use, and how to keep control after the data leaves. We do not cover Marketplace listings or clean rooms in depth.

What it is

The documentation describes OpenSharing as the secure data sharing platform in Databricks for sharing data and AI assets with people outside your organisation, whether or not they use Databricks. It is an open protocol that also underpins Databricks Marketplace and Clean Rooms.

Three concepts carry the model:

The provider keeps the data where it is. The recipient reads a live view of the shared objects, so there is no copy to e-mail and the provider can change or end the share.

Two ways to share

Choose by the recipient. A partner who works on another platform needs the open route. A sister company on Databricks gets the richer Databricks-to-Databricks route, where they mount the share as a catalog. Mounting needs the CREATE CATALOG privilege, and accepting an e-mail invitation for a Databricks-to-Databricks share needs the CREATE PROVIDER privilege.

The documentation labels one feature as Beta: OpenSharing by email, which an account admin must enable on the Previews page. It has limits, such as no OIDC federation and no group or service principal recipients. Treat it as a pilot until its status changes.

The sharing steps

In outline: create the share, add the objects, create the recipient, grant the recipient access to the share.

-- Schematic outline. Confirm the exact syntax in the current OpenSharing reference.
CREATE SHARE prd_finance_invoices_for_partner;
 
ALTER SHARE prd_finance_invoices_for_partner
  ADD TABLE prd_finance.gold.invoices_shared;     -- a curated table, never raw data
 
CREATE RECIPIENT partner_acme;                    -- open recipient: you send an activation link
 
GRANT SELECT ON SHARE prd_finance_invoices_for_partner TO RECIPIENT partner_acme;

The documentation notes that CREATE RECIPIENT does not support e-mail sharing. Follow the current reference for the exact flow that matches your recipient type.

Share a curated object

The most important design rule: share a purpose-built gold table or view, never your working tables. The recipient sees exactly what is in the share, and nothing else is exposed, so the share is also your privacy control.

• Create a dedicated schema, for example gold_share, with a table per recipient purpose.
• Include only the columns the recipient needs. Apply data minimisation: if the partner needs a status and a date, do not share names.
• Pseudonymise or aggregate when the purpose allows it.
• Document the purpose, the legal basis or agreement, the owner and the end date for each share.

Row filters, masks and sharing

Lesson 4 listed a limit that matters here: the documentation states that tables with table-level row filters or column masks cannot be shared through OpenSharing. Do not try to share a protected table and rely on the filter. Instead, build a physical, minimised table for the share from a pipeline step that applies the same rules, and share that table. It also gives you a table you can test and version.

Governance of shares

Because shares and recipients are securable objects, the standard governance applies:

• Ownership by a group. The platform data-sharing group owns shares and recipients.
• Least privilege on who can share. Creating shares and recipients, and granting them, is a privileged action. Put it behind a group and review it.
• Review quarterly. List active shares and recipients, owners and last access. End shares nobody uses.
• Audit. Sharing events appear in the audit logs of lesson 5. Alert on a new recipient and on a new object added to an existing share.
• Agreements first. Before a share exists, there is an agreement: purpose, permitted use, retention and a contact.

Define shares and recipients in Terraform, like grants, so changes go through a pull request (lesson 7).

Security of the credential

A token-based recipient receives an activation link and a credential file. Treat it like a secret.

• Send it through a channel the recipient controls, not through a shared mailbox.
• Set an expiry and rotate it.
• If a credential leaks, revoke it and issue a new one. The share and the data stay as they are.
• Prefer OIDC federation over bearer tokens where the recipient's platform supports it.

Regions and residency

Check where the data may go. For EU clients, keep personal data in the agreed region, and confirm that the recipient's reading location is acceptable under the agreement. A live share avoids a copy, which helps, but reading data across a border is still a transfer.

Common mistakes

• Sharing working tables. Share a curated table.
• A filter instead of a minimised table. Filters and masks block sharing, and a copy is cleaner anyway.
• No end date. Shares outlive projects.
• Leaked credentials by e-mail. Use a controlled channel and an expiry.
• Sharing before the agreement is signed.

Summary

Use OpenSharing for controlled, live access to curated data. Pick the open route or the Databricks-to-Databricks route by recipient. Share a minimised gold table, govern shares and recipients as securable objects, define them in code and audit them.

Next lesson: the final piece, governance as code with Terraform.