I am new to azure and trying to learn azure storage. Suppose I have created a storage acoount and stored few documents, and want everyone to access mt document. If I give my URL, everyone can access it but I want few users to access my storage account and can also upload documents they want.
Please refer me how to achive this and if possible please refer and link which will be usefull for me.
Thanks in Advance.
There are a couple of ways you can do this:
Generate and distribute SAS tokens with read/write privileges. This will give a Url which expires at a given point in time. You can do all this through the portal, through code, or by using context menus within Azure Storage Explorer. Here is a sample of how to do it with code.
You can also assign the AAD users to a role which has permission to manipulate resources in the storage account. Here is a list of current roles so you can select the proper one based on your use case. There are preview roles which don't appear to be working.
EDIT: MS just announced the preview of AAD support down to the scope of a container or queue. This is likely the granularity you were looking for.
EDIT 2 : Full RBAC support for storage is now available
You can generate SAS token
This way you can grant access to others without sharing the account keys.
You can create SAS token on specific Service( Blob, Queue, File ) or an Account SAS which allows you to grant permission to multiple services within storage account.( Queue and Table for eg. )
SAS tokens give you granular control over types of access including:
The interval over which the SAS is valid, including the start time and the expiry time.
The permissions granted by the SAS. For example, a SAS for a blob might grant read and write permissions to that blob, but not delete permissions.
An optional IP address or range of IP addresses from which Azure Storage will accept the SAS. For example, you might specify a range of IP addresses belonging to your organization.
The protocol over which Azure Storage will accept the SAS. You can use this optional parameter to restrict access to clients using HTTPS.
Azure Storage offers these options for authorizing access to secure resources:
Azure Active Directory (Azure AD) integration (Preview) for blobs and queues. The Azure AD provides role-based access control (RBAC) for fine-grained control over a client's access to resources in a storage account. For more information, see
Authenticating requests to Azure Storage using Azure Active Directory (Preview).
Shared Key authorization for blobs, files, queues, and tables. A client using Shared Key passes a header with every request that is signed using the storage account access key. For more information, see
Authorize with Shared Key.
Shared access signatures for blobs, files, queues, and tables. Shared access signatures (SAS) provide limited delegated access to resources in a storage account. Adding constraints on the time interval for which the signature is valid or on permissions it grants provides flexibility in managing access. For more information, see
Using shared access signatures (SAS).
Anonymous public read access for containers and blobs. Authorization is not required. For more information, see
Manage anonymous read access to containers and blobs.
By default, all resources in Azure Storage are secured and are available only to the account owner. Although you can use any of the authorization strategies outlined above to grant clients access to resources in your storage account, Microsoft recommends using Azure AD when possible for maximum security and ease of use.
Related
Azure Storage Account
In one of our use case, we would like to use Azure Storage for sharing it with customers so that they can upload their data to us.
In that context, we are planning to create storage account per customer. In order for customer to access the account, we are planning
to share the storage account keys.
We are facing following issues
How to create keys specific to azure storage account container, so that customer can only access specific container.
Is it possible to have individual keys and access at container level.
For certain container, we want to give read-write access.
For others, we want to give only read access.
If i have storage account keys, does that mean i have access to everything under that storage account.
Is there a better solution to this ? Essentially we need a ftp site for customers to upload data.
Sounds like you want to use a shared access signature (SAS):
https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview
A shared access signature (SAS) provides secure delegated access to resources in your storage account without compromising the security of your data. With a SAS, you have granular control over how a client can access your data. You can control what resources the client may access, what permissions they have on those resources, and how long the SAS is valid, among other parameters.
You can't have access key for a container level, there are for the whole Storage Account
To give access at a container level (or even finer grain) you need a Shared Access Signature. Documentation here
You can have as many SAS as you need, and you are allowed to define them with the desired permissions (read, read-write etc...)
Per my understanding, there are two types of SAS tokens when it comes to Azure Storage Account.
Account-level SAS tokens
Blob container/Queue level SAS token
I observed that if we do not choose to use the primary/secondary keys to authenticate with the storage account and use the account level SAS tokens as an authentication mechanism then I can not create the Blob container level SAS tokens using Stored Access Signature. Why is that? Is there a way to make it work? I do not want to provide access to my service to the account level keys and want to create SAS tokens to implement the RBAC at the runtime, is there any way for same?
I observed that if we do not choose to use the primary/secondary keys
to authenticate with the storage account and use the account level SAS
tokens as an authentication mechanism then I can not create the Blob
container level SAS tokens using Stored Access Signature. Why is that?
This is by design. A container level SAS only lets you work at the container level where you can perform operations on the blobs inside that container. Creation of a blob container is an account level activity and thus you would need to use an Account SAS. At this time, Account SAS do not have a concept of Shared Access Policy.
I do not want to provide access to my service to the account level
keys and want to create SAS tokens to implement the RBAC at the
runtime, is there any way for same?
Yes, there is. Azure Blob Storage support Azure AD based authentication/authorization and has support for Role-based Access Control (RBAC) available in Azure Subscription. You can assign granular RBAC roles to your users in Azure AD and they will be able to perform only the operations allowed by their roles. You can read more about it here: https://learn.microsoft.com/en-us/azure/storage/common/storage-auth-aad.
You can find more details about various authorization options available in Azure Storage here: https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-requests-to-azure-storage.
We have recruitment that need to store the file in Blob Storage. The blob storage account which i have created for a company. There are multiple site for a same company. We need to restrict the site member to see other site files. So I need the access key based on container level.
The container will be created dynamically from C#. The credential / access key that should be created while creating the container from C# and the container level access key / credential will be shared with site members not the storage account access key. Storage account key will be in application configure side. So storage account key will be hidden from the site members.
How do I get the container level access key / credential in Azure blob storage?
I think SAS could meet your requirements.With a SAS, you can grant clients access to resources in your storage account, without sharing your account keys. And you could set the interval over which the SAS is valid and the permissions granted by the SAS. For example, a SAS for a blob might grant read and write permissions to that blob, but not delete permissions.
You could create SAS pointing to one or more resources and including a token that contains a special set of query parameters.
Here are two examples about how to use SAS, first SAS examples and create SAS.
If you still have other questions, please me know.
Is there any role based access control for Azure Blob Storage? I'm aware of SAS tokens and ACL, which are great, but ACL allows only for 5 entries.
Is there any role based access control for Azure Blob Storage?
Not as of today. You have to use Shared Access Signature for access control. The limit of 5 access policies is per container. One possibility would be to have multiple containers.
One of the approaches is to have middleware which does RBAC or ACL stuff then on succession, generate short expiration SAS token from Azure and next is to redirect(via HTTP header) user to the SAS URI.
Ref: https://learn.microsoft.com/en-us/azure/storage/common/storage-dotnet-shared-access-signature-part-1
I have a resource group in Azure which contains cloud service and a storage account. I want to give access to the resource group to my developers so that they can access the resources and make changes. However, there is one particular table in the storage account which contains sensitive user details. The table is being updated through our client app using SAS tokens.
I want only few selected people from my team to be able to see the complete contents of the table. Is there any way in azure to do this?
Azure Storage access is gated by its account name+key. Anyone with access to that key has access to any object(s) within a storage account, whether, blob, queue, or (in your case) table.
If developers have access to the resource group, and the resource group contains the storage account, then those developers have full access to the storage account contents.
If you wanted to prevent your developers from accessing storage, this storage account would need to reside within another resource group (which the developer does not have access to). And then you would have the choice to provide the developer(s) with the storage account+key, or with a SAS to a particular table.
However: If a developer has been granted co-admin permissions to the Azure subscription itself, then they have access to 100% of resources within the subscription, regardless of resource group or SAS.