[Enhancement]: Azure Blob Storage private container support

[anttip1]

What features would you like to see added?

I'd like LibreChat to support a private access mode for Azure Blob Storage containers. Currently, files stored in Azure Blob Storage need to be public and are accessed via direct URLs. This feature would add an option to store files in private containers and serve them through an authenticated proxy endpoint, improving security.

More details

The implementation would need to:

1. Add a proxy endpoint ( e.g. /api/files/proxy/azure/:user_id/:filename) that would authenticate requests before serving files from private containers.
2. Use the existing environment variable AZURE_STORAGE_PUBLIC_ACCESS to indicate "private mode"
   • When set to "true" (default): File URLs are the public blob storage URLs as they are now
   • When set to "false": File URLs are proxy URLs
3. Modify these azure blob file operations to accommodate the private mode:
   • saveBufferToAzure, streamFileToAzure, and getAzureURL now return proxy URLs when in private mode.
   • getAzureFileStream converts proxy URL to Azure Blob URL before downloading in private mode
   • deleteFileFromAzure converts the proxy URL to Azure Blob URL before deletion

The proxy endpoint authentication could work like this:

• Extract the user's JWT refresh token from cookies and verify it against the JWT_REFRESH_SECRET.
• Compare the user ID in the token with the user ID in the URL path
• Query the database to verify the requested file belongs to the authenticated user
• Reject the request if any authorization check fails with appropriate status codes (401, 403, 404)

Which components are impacted by your request?

Other

Pictures

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[danny-avila]

I've thought about this, and it adds some complexity to the project. You would need to make it "provider-agnostic" at least with the route definition and go from there with dependency injection in mind.

I think it would be better as an adapter to the existing methods when creating the URL, and even better as an addition to that, best served as an independent API external to LibreChat, as proxying externally is preferable and gives you the maximum amount of customization for your use case, and necessary code changes to LibreChat would be minimal in this regard.

This won't be on my radar to tackle for a while but PR's are always welcome.

[jerbob92]

@danny-avila would it be an idea to use signed URLs for this for now? This would probably make it way easier to implement (probably can just implement it here.

This will allow people to access the files directly using the Azure URL, without the need of a proxy, but with security.

[ion-elgreco]

Presigned urls is the way to go for this, and is much more simpler

[npeham]

@anttip1 @danny-avila I wanted to share how we approached a similar issue where private access to Azure Blob Storage was required, maybe this can work for you as well. Instead of implementing an authenticated proxy as suggested, we leveraged Azure's built-in features to achieve the desired level of security.

Here's how we set it up:

1. Private Endpoint: We configured a private endpoint for our Azure Blob Storage. This ensures that all communication happens over a private network and is isolated from public internet access.

2. Dedicated Subnet: The private endpoint is hosted within its own subnet, providing additional control and network isolation.

3. Private DNS Zone: We use a private DNS zone to resolve the Blob Storage's private endpoint within our Azure Virtual Network (VNet).

With this setup, we were able to configure Azure Blob Storage to operate in private mode. The LibreChat pod running in our AKS (Azure Kubernetes Service) cluster can still access the storage using the "azure_blob" strategy, as all traffic stays within the private network.

This approach solved the problem for us, eliminated the need to introduce a proxy endpoint, and kept things secure using Azure's native capabilities. Additionally, it simplified our implementation by avoiding code-level changes in file handling operations as outlined in your proposal.

[lkchao-majority]

Hi @npeham,

I’ve tried this method on my end, it works fine for storing files.
But users still can’t access the uploaded files from LibreChat as the links returned point directly to the bucket resources, which are private.

How did you handle that part?

Thanks!

[npeham]

@lkchao-majority Hi and sorry for the late reply, but yes we just encounter the same problem. IMO the backend of LibreChat should download the image from the blob storage and then pass it down to the browser so the user can download it, because the managed identity only allows the librechat pod to access the blob storage.

Did you find a solution in the meantime?

[npeham]

@lkchao-majority If I rethink this again then the best solution is to implement signed urls as mentioned above in the comments.

[lkchao-majority]

@npeham No worries thanks for the reply.
For now we stopped using storage account for better user experience until private one is fully supported.

[RolRodr]

On our end,

We wanted to keep our container access private, so what we we did was:

1. Generate a Connection String with SAS and set that as the AZURE_STORAGE_CONNECTION_STRING value
2. Added a new ENV variable: AZURE_SAS_TOKEN
3. I added a small patch toapi/server/services/files/azure/crud.js:

Line 10:
From:

const { AZURE_STORAGE_PUBLIC_ACCESS = 'true', AZURE_CONTAINER_NAME = 'files' } = process.env;

To:

const {
  AZURE_STORAGE_PUBLIC_ACCESS = 'true',
  AZURE_CONTAINER_NAME = 'files',
  AZURE_SAS_TOKEN = 'none',
} = process.env;

Adjusted the deleteFileFromAzure function:
Line 107:


From:

const blobPath = file.filepath.split(`${AZURE_CONTAINER_NAME}/`)[1];

To:

const blobPath =
  AZURE_SAS_TOKEN === 'none'
    ? file.filepath.split(`${AZURE_CONTAINER_NAME}/`)[1]
    : file.filepath.split(`?${AZURE_SAS_TOKEN}`)[0].split(`${AZURE_CONTAINER_NAME}/`)[1];

Without the patch to api/server/services/files/azure/crud.js, we were able to create and read resources but unable to delete resources from the blob storage because file.filepath still contained the signature after the split. Now we're able to successfully create, read, and delete resources.

@danny-avila Is this something we might want a PR for?

[adamfisher]

I have added a PR for this. Any idea on timeline @danny-avila for getting this merged in if it all looks good?

Feature PR: #11137
Documentation PR: LibreChat-AI/docs#474