When cloud object storage services were originally released, they focused on the functionality of storing objects. At the time (and is frankly still good advice) the thought was that identity is the new boundary, and that traditional network security rules make cloud things complicated. The tag-phrase says something like “Identity is the new boundary”.

In the last post, we discussed the concepts behind the valet key pattern. In this post, I will walk through how to perform this operation on Azure.

The last concept we are going to talk about surrounding blob access is the idea of anonymous access. Unless you’ve been hiding under a rock this past few years, public access to object storage (particularly S3 buckets) have been a common “attack” vector against companies. In the past, S3 buckets were quite easy to mark as publicly accessible, leading to lots of issues.

My niece is employed as a recruiter and I happened to come across a post she had shared regarding Robert Half Technology’s State of Tech Hiring in Canada. I’ve always appreciated their survey data for hiring trends and in demand skill sets. What was interesting this year is just how much the cloud skill set dominated the in demand needs as well as in demand training.

In part 1, we discussed authentication options in both AWS and Azure. In this post, we will discuss the authorization options. As described in part 1, AWS makes use of a combination of user policies and resource policies to govern access. User policies are only used if the user trying to access the objects are IAM users. In this way, cross account access is also supported.

For both AWS and Azure, a REST based API has been created to facilitate blob storage operations. The REST API has two logical components, a data plane (interacting with blobs themselves) and a management plane (interacting with the service itself). The goal of this post is to talk about access options at the data plane level.