Blog Post

Fabric Updates Blog
5 MIN READ

Secure data ingestion with COPY INTO and Workspace Identity (Generally Available)

fredguis's avatar
fredguis
Icon for Microsoft Employee rankMicrosoft Employee
1 month ago

Data ingestion should be simple for users and controlled for administrators. Yet many data teams face the same challenge: users need to load approved data into a warehouse, but the source files reside in restricted storage locations where they aren’t granted direct access. The work is approved, the data is approved, but the access model slows the process down.

With workspace identity support for COPY INTO now generally available, Fabric Data Warehouse supports a more governed ingestion pattern. Users can load data into a warehouse table by using the workspace identity as the credential for the source files. The user still needs permission to write to the target warehouse table, while source file access is managed centrally through the workspace identity.

COPY INTO dbo.SalesOrders FROM 'https://onelake.dfs.fabric.microsoft.com/<workspace-id>/<item-id>/Files/orders/*.csv' WITH (     FILE_TYPE = 'CSV',     FIRSTROW = 2,     CREDENTIAL = (IDENTITY = 'Workspace Identity') );

The result: users get the permissions they need in the warehouse, while source access is managed centrally through the workspace identity.

Scenarios this feature unlocks

Many organizations have a clear security policy: human users should not have broad access to raw data storage.
In regulated environments, raw zones hold sensitive data — which is exactly why the load stalls.


Until now, every option on the table came with a tax:

  • Grant direct storage access to users who only needed to load approved data.
  • Use SAS tokens or account keys, which require careful rotation and tracking.
  • Use a service principal, which introduces another identity and credential to manage.
  • Request a security exception, which can slow down approved ingestion work.

Workspace Identity provides an alternative approach.

Admins can grant the workspace identity access to the approved source location. Warehouse admins can grant users only the SQL permissions needed to load the target table. Users can run the ingestion, but they do not need direct access to browse or read the source files outside the approved operation.

Where this changes the day-to-day:

  • Regulated raw zones where users are not allowed to directly access sensitive source files.
  • OneLake-to-Warehouse ingestion where data needs to move from Fabric items into a warehouse using a workspace-level identity.
  • ADLS Gen2 ingestion behind controlled access patterns where storage access is assigned to managed identities instead of individual users.
  • Least-privilege onboarding where ingestion users receive table-level permissions without broad lake permissions.
  • Reduced credential sprawl by minimizing the need for SAS tokens, shared keys, or service principal secrets.
  • Separation of duties where storage admins manage source access and warehouse admins manage table access.

The key value is simple: approved ingestion without expanding direct user access to storage.

How it works

Workspace Identity does not replace warehouse authorization. It changes which identity Fabric uses to authenticate to the source files.

When a user runs COPY INTO with Workspace Identity, two authorization boundaries are evaluated:

  1. Fabric validates that the user has permission to load data into the target warehouse table.
  2. Fabric uses the workspace identity to access the source files.

Both checks must pass.

If the user does not have permission to write to the target table, the load is blocked. If the workspace identity does not have access to the source data, the load is blocked.

Access decision

Evaluated through

Can this user load into the target table?

SQL permissions

Can the source files be read?

Workspace Identity access

Who initiated the operation?

The calling user

This model keeps user authorization and source access separate, while preserving a familiar T-SQL ingestion experience.

A practical example

Picture the nightly load on a fraud-analytics team. Raw transaction files land in a locked ADLS Gen2 zone no analyst can open. Each morning, a handful of curated files need to reach the warehouse for reporting.

Before, someone minted a SAS token scoped to that folder and hoped it got cleaned up. Now the admin grants the workspace identity read access to that one zone, once. The engineer runs COPY INTO, the load succeeds, and they still can’t browse the raw files. Nobody minted a secret.

That’s the pattern this release enables: centralized source access, table-level authorization, and no standing user access to raw storage.

Figure: Workspace Identity configuration in Fabric workspace settings.

Before and after

Before Workspace Identity support, ingestion users often needed access to both the warehouse and the source storage location.

User -> COPY INTO -> Source files

User needs warehouse permission and direct source access

With Workspace Identity, the source access can be assigned to the workspace identity instead.

User -> COPY INTO -> Workspace Identity -> Source files

User needs warehouse permission

Workspace Identity needs source access

This reduces the need to grant storage permissions broadly and helps customers move away from secret-based ingestion patterns.

Before users run COPY INTO with workspace identity, make sure they have permission to use the workspace identity and permission to write to the target warehouse table.

What stays protected

Workspace Identity support for COPY INTO is designed to strengthen the ingestion model without weakening existing controls.

  • Users still need permission to write to the target warehouse table.
  • The workspace identity must be explicitly granted access to the source data.
  • Source access is scoped to what the workspace identity is allowed to read.
  • Existing Fabric, storage, and network controls continue to apply.
  • Users do not receive general access to browse the source storage location.

This makes Workspace Identity a strong option for customers who want managed identity-based ingestion while keeping direct user access to raw storage limited.

Getting started

To use Workspace Identity with COPY INTO:

  1. Configure Workspace Identity for the Fabric workspace.
  2. Grant the workspace identity access to the approved source location.
  3. Grant the user permission to insert into the target warehouse table.
  4. Run COPY INTO with Workspace Identity as the credential.
COPY INTO dbo.SalesOrders FROM 'https://onelake.dfs.fabric.microsoft.com/<workspace-id>/<item-id>/Files/orders/*.csv' WITH (     FILE_TYPE = 'CSV',     FIRSTROW = 2,     CREDENTIAL = (IDENTITY = 'Workspace Identity') );

Workspace Identity support for COPY INTO gives Fabric Data Warehouse customers a simpler and more secure way to operationalize ingestion. Users can load the data they are approved to load, admins can centralize source access, and organizations can reduce the need for direct user access to raw storage.

Learn more

Explore the official Microsoft documentation for COPY INTO in Fabric Data Warehouse:

Updated 1 month ago
Version 3.0
No CommentsBe the first to comment