how do i share an internal app securely with the right people

Summary

• Databricks Apps uses two permission levels: CAN_USE allows users to view and run the app, while CAN_MANAGE grants administrative control. Assign permissions to individual users, groups, or service principals through the app's Share UI.
• Organization-wide access can be restricted to explicitly authorized users, or opened to all account members with varying permission levels. Apps cannot be made public; users must authenticate through your identity provider.
• Apps use dedicated service principals for resource access, with two authorization models: app-level (service principal) where all users share the same identity, or user-level (on-behalf-of) where apps respect individual user permissions for downstream resources.
• Secure deployment by requiring all apps to come from Git repositories, enabling code review and CI/CD scanning before production. Use separate workspaces or environments for development, staging, and production.
• Protect sensitive apps with IP access controls, PrivateLink for network isolation, audit logging to track app usage, and least-privilege grants on databases, warehouses, and serving endpoints.

how do i share an internal app securely with the right people

Securing Databricks Apps means controlling who can access them, what permissions they have, and how they authenticate to other resources. Databricks Apps use two permission levels, can be shared at the app level or organization-wide, and support two authorization models depending on whether the app acts on behalf of itself or the calling user. Every user authenticates through your identity provider; apps cannot be made public. The combination of permission controls, workspace isolation, Git-enforced deployment, and audit logging lets you share apps safely with exactly the right audience.

What is a Databricks App?

A Databricks App is an internal web application built on Node.js or Python that runs inside your workspace. Each app has a dedicated service principal representing its identity when accessing downstream resources.

Permission and access levels

Control	Description	Who to grant it to
CAN_USE	View and run the app	Users, groups, or service principals who need to use the app
CAN_MANAGE	Modify, delete, or redeploy the app	Workspace admins or trusted developers responsible for the app
Organization-wide CAN_USE	All account members can run the app	Use when the app is a shared utility, company-wide tool, or read-only dashboard
Explicit allowlist	Only specified users, groups, or service principals can access	Use for sensitive or internal-team apps; start here for principle of least privilege

How Databricks approaches secure app sharing

Permission assignment and least privilege
Databricks Apps uses a central Share interface to grant permissions. Users can be added individually, but best practice is to add groups or service principals for easier scalability and governance. To share an app:

1. Open the app's overview tab.
2. Click Share.
3. Choose a user, group, or service principal from the dropdown.
4. Select CAN_USE (view and run) or CAN_MANAGE (modify and manage).
5. Click Add, then Save.

Start with CAN_USE and grant CAN_MANAGE only to developers who actively maintain the app. If sharing across the organization, restrict to account members rather than allowing public access; apps cannot bypass identity provider authentication.
App authorization: service principals vs. user identity
Databricks Apps support two authorization models:

• App-level (service principal): All users run the app with one shared identity. Use for apps where everyone sees the same data, like company dashboards.
• User-level (on-behalf-of): The app respects each user's individual permissions, filtering data by who's logged in. Use for role-based or personalized apps.

Resource access and service principal least privilege
Grant each app's service principal only what it needs: CAN USE on warehouses, CAN QUERY on endpoints, SELECT on tables. Never hardcode PATs, don't share credentials across apps, and rotate credentials if the app creator leaves.
Secure deployment and monitoring
Enforce Git-deployment-only via Settings > Development > Apps, so all code is peer-reviewed and CI/CD-scanned. For sensitive apps, use IP access controls or PrivateLink to restrict connections, and review audit logs showing who ran which app and when.

Use cases

Shared metrics dashboard – A company-wide app for sales metrics or utilization trends. Grant CAN_USE to all account members and CAN_MANAGE to the analytics team. Use app-level authorization so everyone sees the same view.
Role-based data explorer – An app showing customer or inventory data, filtered by the logged-in user's role and permissions. Use user-level authorization; Unity Catalog row filters enforce per-user visibility.

FAQs

Can I share a Databricks App with someone outside my organization?

Yes, if they are added as an account user through your identity provider and SCIM provisioning (or just-in-time provisioning). External collaborators don't need a workspace access grant, but they must be recognized as account users. Apps cannot be made publicly available; SSO is always required.

What's the difference between app-level and user-level authorization?

App-level: all users see the same data with one shared identity. User-level: data is filtered by the user's permissions. Choose app-level for dashboards everyone should see identically, and user-level for personalized or role-gated apps.

How do I prevent an app from accessing a resource it shouldn't?

Grant the service principal minimal permissions: only the warehouses, tables, and endpoints it needs. Use Unity Catalog row filters to enforce access. Review code before deployment.

What if the app creator leaves?

Rotate the app's service principal credentials. Ensure CAN_MANAGE is held by at least two people so the app isn't orphaned.