AWSvAzure - Object Storage - Blob Access Part 2

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.

User policies are standard IAM policies. Allowed permissions can be found https://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html. What is interesting about defining user policies is that you can limit the allowed actions based on resource identifiers. Resources are specified in ARN format and can be specified as the entire bucket or keys within the bucket. Because these are ARN format, you can make use of policy variables and also wildcards. Pretty powerful.

Azure's story (at least for controlling administrator access via RBAC controls) is not as granular. If you remember from part 1, any user with access to the listkeys action will have full access to all objects stored in that storage account. You can find information about the built-in roles and their capabilities https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#storage-account-contributor.

The key difference is that, using the built-in RBAC engines, you can enforce down to the key level permissions in AWS but you can't do the same in Azure.

From a user permission perspective, in AWS you would continue to use IAM users/policies and bucket policies. In Azure, however, the pattern for this type of access is to use SAS tokens with associated SAS policies. SAS tokens solve some of the problems described above, but ultimately, are container level elements. So they do not provide granular access down to the key level.