How do I build a rich storage ACL policy system with Azure storage?
I want to have a blob container that has the following users:
public - read-only against some set of blobs
Uploader - read-write against some subset of blob names, these keys are shared out to semi-trusted build machines
shared admin - full capabilities against this blob subset
Ideally these users are accounts driven through Azure AD, so I can use the full directory service power with them... :)
My understanding of shared access keys is that they are (1) time-limited and (2) have to be created with hand-tooled code. My desire is that I can do something similar to AWS IAM policies on S3... :-)
Thing like AWS IAM Policies for S3 does not exist for Azure Blob Storage today. Azure recently started a Role Based Access Control (RBAC) and is available for Azure Storage but it is limited to performing management activities only like creating storage accounts etc. It is yet not available for perform data management activities like uploading blobs etc.
You may want to look at Azure Rights Management Service (Azure RMS) and see if it is a right solution for your needs. If you search for Azure RMS Blob you will find one of the search results link to a PDF file which talks about securing blob storage with this service (the link directly downloads the PDF file and hence I could not include it here).
If you're looking for a 3rd party service to do this, do take a look at the "Team Edition" of Cloud Portam (a service I am building currently). We recently released the Team Edition. In short, Cloud Portam is a browser-based Azure Explorer and it supports managing Azure Storage, Search Service and DocumentDB accounts. The Team Edition makes use of your Azure AD for user authentication and you can grant permissions (None, Read-Only, Read-Write and Read-Write-Delete) on the Azure resources you manage through this application.
Paul,
While Gaurav is correct in that Azure Storage does not have AD integration today, I wanted to point out a couple of things about shared access signatures from your post:
My understanding of shared access keys is that they are (1) time-limited and (2) have to be created with hand-tooled code
1) A sas token/uri does not need to have an expiry date on it (it's an optional field), so in that sense they are not time-limited and need not be regenerated unless you change the shared key with which you generated the token
2) You can use PS cmdlets to do this for e.g.: https://msdn.microsoft.com/en-us/library/dn806416.aspx. Some storage explorers also support creation of sas tokens/uris statically without you having to write code for it.
Related
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.
Is there a service or a(n open-source) library that could help in programmatically manage files stored on Azure blob storage. By manage I mean search with security trimming, authorizing download, document-versioning.
I've looked online but most of the solutions are more of end-user solutions. Should I build my own layer to talk to blob storage or there's a way that can take a part of this burden off my shoulders?
A solution that could work with both cloud (blob) and on-premise storage would be great!
I am not aware of any such library. That being said the storage platform does include the underlying capabilities upon which you could implement these features. For example, for authorizing access to objects you could issue SAS tokens to authorized users. For document versioning you can create snapshots on objects etc.
Our team has Windows Azure MSDN - Visual Studio Premium subscriptions for all our devs. I have been taking advantage of the $100 per month allowance and am building more infrastructure in the cloud.
However, I would like other members of our team to access certain of the assets. I am quite new to the Azure infrastructure, so this might be a dumb question. But can they access my blobs? and can I control exactly who can access my blobs?
They can obviously RDP into my VMs, that's not an issue. I assume they can hit my VMs too, via the IP address, inside Azure, etc. However, I am more interested in the Blobs. Mostly because I am starting to upload a lot of utility data (large sample datasets, common software we all install, etc.) and I would like to avoid all of us having to upload all of it again for each subscriptions.
As of today (11/8/2013), you cannot "pool" MSDN resources meaning..have 4 subscriptions add up to $400/month and do ala carte cloud services
You can have one admin/or several for multiple subscriptions, this will allow you to view the different subscriptions in the portal and manage them in a single spot
You can also have different deployment profiles, so one Visual Studio instance can deploy to different Azure accounts.
Specific to your question, you have blob access keys and if you share the name of the storage account and key...yes they can access your data located there.
Yes, it is possible to control access to your blobs by using SAS (Shared Access Signatures)
SAS grants granular access to container, blob, table, & queue
This should be a good resource to start with :
Manage Access to Windows Azure Storage Resources
Create and Use a Shared Access Signature
However, I would like other members of our team to access certain of
the assets. I am quite new to the Azure infrastructure, so this might
be a dumb question. But can they access my blobs? and can I control
exactly who can access my blobs?
To answer specifically this question, Yes your team members can access the data stored in any blob storage account in any of your subscription. There are two ways by which you can provide them access to blob storage:
By giving them account name/account key: Using this, they get full access to storage account and essentially become owners of that storage account.
By using Shared Access Signature: If you want to give them restricted access to blob storage, you would need to use SAS as described by Dan Dinu. SAS basically gives you a URL using which users in possession of that URL can explore storage (by writing some code), however it is not possible to identify which user accessed which storage. For that you would need to write something on your own.
I have registered a Free-Trial account on Azure site.
In documentation I found:
http://msdn.microsoft.com/en-us/library/windowsazure/dd179428.aspx
that I need some Shared Keys to use APIs.
But where are they located on Azure Management Portal?
I could not find them at all.
Do I need a paid account for this?
If you open the Azure portal, click on the "Hosted Servcies, Storage Accounts & CDN" link on the lower left and then pick "Storage Accounts". Once you click on "New Storage Account" and create a storage account, you will see "Primary access key" and "Seconardy access key" on the right hand side if you select that storage account in the middle.
More info:
Creating a storage account: http://msdn.microsoft.com/en-us/library/windowsazure/gg433066.aspx
Viewing keys: http://msdn.microsoft.com/en-us/library/windowsazure/hh531566.aspx
Note, if you are meaning Shared Access Signatures for blob storage, look at: http://blog.smarx.com/posts/new-storage-feature-signed-access-signatures
Each storage account you create will have a primary and secondary key, which is ultimately used in the REST header for accessing tables, blobs, and queues. If you're using .NET, Java, PHP or any other language where you've found a library wrapping the REST API, you won't have to worry about constructing REST headers; instead, you'll just create a storage endpoint using your primary or secondary key.
Making this easier, the key can be stored in your configuration settings. Then, if you ever change your storage account (maybe one for development, one for production), it's a simple matter of changing your configuration settings instead of changing code.
FYI - these keys are created automatically when you create a new storage account. And... you may use either key, and invalidate / re-create either key at any time (which is great if, say, you share your secondary key with a 3rd-party service and then want to terminate your relationship with that service).
I'd suggest grabbing the Windows Azure Training Kit and trying out a few of the first exercises, as you'll see exactly how to reference a storage account this way.
I'm trying to get up-and-going with Windows Azure. I understand that I need to create a "Storage Account". However, what I'm confused about is, how I should set it up. For instance, my Azure subscription is set to my company name. I intend to have multiple ASP.NET web applications (web roles) associated with my subscription. Each web application will have its own database.
My question is, should each web application have its own storage account? Or should only one storage account be used for all of my projects?
Thank you!
There's no one way to answer this, but here are some thoughts to help your decision:
Each storage account is limited to 100TB. If you feel that you will push the limits of this across multiple websites, then create multiple storage accounts for sure.
To make billing easier, I'd suggest separate storage accounts
Storage accounts have an SLA of a few thousand transactions per second across the entire storage account. For performance purposes, it's probably better to have separate storage accounts
Consider putting your diagnostic data in a separate storage account. This way, you can safely give your Storage Account key to a 3rd-party like ParaLeap (creators of AzureWatch) for monitoring your app, while not giving away the key to real customer data, for instance.
If you need more than 5 storage accounts, you'll need to contact Customer Support to increase this number.
Windows Azure Storage server is for simple blob storage. This is for when your app needs a file store. Any application, not just Azure web roles, can target a storage service. It's kind of like Amazon S3 if you're familiar with that.
Storage services are not required to run Azure applications. You just need a "compute" instance.