I have a frontend container, backend container and the azure blob storage. User using the front/backend are authenticated. Thus the backend validates the user credentials and users are allowed to access their media files stored in the azure blob storage.
I would like that users access their media files directly at the azure blob storage in order not to stress the backend to much by using it as a proxy. The media references for each user are stored in the backend.
How would you achieve this by using the azure blob storage and its access control (or is it a misuse of the azure blob storage)?
You can implement security by generating a SAS token for your blob container/individual blob
With a SAS, you can grant clients access to resources in your storage account, without sharing your account keys
Related
I want to authorize backend (Web API in Azure Active Directory) to distribute SAS for uploading into Blob Storage.
It would be perfect if SAS can be issued only for one blob upload. I assume that client will send a request with a file name to upload, then backend will return SAS that could be used only to upload one blob with previously set file name.
I found the Storage Blob Delegator role, but as far as I know roles can only be set to user account (person).
How in this case the backend should be authorized?
Shared key
Fake account
Long SAS
Or is there another way to solve this problem? I have checked a lot of articles in docs but all of them solves slightly different problems.
I would like to check my understanding of azure sas token.
we can access a BLOB storage using SAS token instead of azureAD certification. Does this mean that a person who does not have azure account can access a BLOB storage???
Or a person who has azure account can use SAS token and access a BLOB storage.
Yes, a person or script that has a SAS token can access BLOB storage, according to the permissions set in the token. That person or script does not need to have an azure account. Of course, that person would not be able to use the Azure portal to see the blob container, but he can access the storage account using programatically using the Azure API. He can also fetch blobs using HTTP GET requests.
As an example, I have a build script that pushes to storage and a deploy script to read from storage. These scripts contain the access token so they can run from any machine.
If I wanted to revoke the privileges of that access token I would need to replace the key that I used to generate the token with.
How we can read data from Azure blob storage without using SAS token and master key? If the user already has some role like Contributor or Reader of storage account or container.
Since you do not want to use either SAS token or account key, you can leverage AAD authentication by assigning any of the following RBAC roles to your spark.
Storage Blob Data Owner: Use to set ownership and manage POSIX access control for Azure Data Lake Storage Gen2. For more information, see Access control in Azure Data Lake Storage Gen2.
Storage Blob Data Contributor: Use to grant read/write/delete permissions to Blob storage resources.
Storage Blob Data Reader: Use to grant read-only permissions to Blob storage resources.
Storage Blob Delegator: Get a user delegation key to use to create a shared access signature that is signed with Azure AD credentials for a container or blob.
https://learn.microsoft.com/en-us/azure/storage/blobs/authorize-access-azure-active-directory#azure-built-in-roles-for-blobs
We are building an app that allows users to upload their own files (ex. images) in Azure Storage.
We are using Azure Storage and plan to use containers to separate the content of each user.
I am a bit lost in the part about security. What would be the best way to secure the container of each user? For example, would each container have a different key?
And if I want to display the image, do I point it directly to the azure storage URL or do I need to have a middle API service that gets it from Azure Storage then returns it?
You have a key per storage account, not per container. You basically have two options - each requires a middleware:
1: Upload the files through you middleware. The client will send the files to your middleware which knows the storage account credentials to store the file in the desired container.
2: Direct upload to Azure Storage. The second option is to directly upload the files to the storage account. Since you don't want to expose storage account credentials to your clients, you will need some kind of middleware that gives your app a temporary SAS Token that allows it to upload the requested file (known as Valet Key pattern). Further information: (File upload in Cloud Applications: The Options)
If you want to display the image, you can point it directly to the Azure Storage URL (if you want them to be public readable) or you can again return the URLs with temporary SAS Token for each authorized user....
In your case, the best way I think is to Authorize the storage with Azure AD, assign the RBAC role for the different users at the container level. Then they will just be able to access their own container, see this link.
To let the user upload files from an app via Azure AD Auth, you could refer to this doc - Authorize access to blobs and queues with Azure Active Directory from a client application.
To display the image, just click the ... of your image(blob) in the portal -> Generate SAS -> Generate blob SAS token and URL -> copy the Blob SAS URL, you could access it directly in the browser.
I have created a blob storage at Azure and I want to share this container with my colleagues who may or may not have azure account and can upload files in this blob storage without providing access to resource groups or storage account. Is it possible with blob storage or there is any other alternative to do that where they can drop there files time to time and I can access them from my azure pipeline. I have tried Secured Acess Signature but it is not working may be I have less knowledge to do that. I have creatred SAS URL by clicking right click on container and shared the link with colleagues.