Azure Table Storage permissions to prevent deletion
It would be nice to be able to lock certain areas of Azure Storage to prevent operators/developers from deleting a table/container/queue by accident. Our specific need right now is for Azure Storage Tables but could potentially be for containers and queues. For example, it would be nice to lock a table to not allow deletion.
While this feature is under review, Shared Access Signatures (http://blogs.msdn.com/b/windowsazurestorage/archive/2012/06/12/introducing-table-sas-shared-access-signature-queue-sas-and-update-to-blob-sas.aspx) can be used to specify exact permissions for a table, partition, or entity, and distribute those to calling applications. Using this can reduce the risk of accidental deletions.
Dillon Brown commented
This workaround is not much better than SAS, but if you stop short of giving the users full key access to the account and instead assign appropriate Data Action operations using RBAC, you can allow read, write etc. while preventing deletion.
Please implement this. Shared Access Signatures don't generate an audit trail. I want to be able to give developers fine grained access (read rights) on production Blob storage/Table storage through Active Directory. Right now, there is a "Storage Blob Data Reader (Preview)" role, but when I give a user this role, in Storage Explorer I get the error "Could not obtain keys for Storage Account. Please check that you have the correct permissions", so this is not usable yet.
Jason Steele commented
Please do implement this. It is far too easy to delete a Blob Container - even with the confirmation dialog. It would be great to be able to add a lock like this: https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-lock-resources
I was working with one of the Red Gate's tools, mainly Azure Explorer, and guess what? I accidentally deleted the whole container by accident! I thought my mouse has selected a blob, but it selected a container, and it was gone before I knew it...it was very, very bad. It would extremely helpful to have some kind of a programmatic, or a GUI way, to prevent deletions of containers. It simply too dangerous to have it like this. Good thing I was in staging...otherwise ALL the pictures of my customer's properties would have been GONE. So please, do consider this one seriously, container deletions, if set to be prevented, should be only allowed via special permissions, or a key/password of some sort. You'd be saving jobs, literally;)
I agree. We've already had one user accidentally delete a container and all the content! She's a nervous wreck that she might do it again. It would be nice if I could lock that container from deletion, than the worst she could is delete just a single blob.
István Hartung commented
For our current needs it would be good to be able to lock an account to prevent both "update" and "delete" methods (or anything that modifies previously added data), and allow only "Insert" and "Select"...
This would be very important to prevent application errors or any other problems.
Almost all my customerts are complaining that storage is too open for mistake and hack.
Nate Pickett commented
For tables, it would be nice to have a deletion lock that would prevent deleting any entity or deleting the whole table when the lock is enabled.
For blobs, it would be nice to have a deletion lock that would prevent deleting any blob or deleting the whole container when the lock is enabled.
For queue, it would be nice to have a deletion lock that would prevent deleting any message or deleting the whole queue when the lock is enabled.
As I mentioned earlier, our need right now is only for table storage but I can see how this would be useful for other storage options.