AWSvAzure - Object Storage - Blob Access Part 1

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.

	AWS	Azure
Authentication Types	Root Account IAM Users	Azure RBAC Azure Active Directory Shared Keys SAS Tokens
Access Policies	IAM Roles Bucket Policies Object Policies Storage ACL	AAD RBAC SAS Token Configuration Anonymous Read Access
Anonymous Access	Yes	Yes

Authentication Types

Both AWS and Azure have their services setup such that permissions on the management plane can bleed into permissions on the data plane.

In the case of AWS, identities for object storage access are either the root account or IAM users. Depending on which is in use, different authentication flows can be utilized. IAM users have the added steps of verifying authentication information and policies with IAM before making the request to S3. Here is an example of a authentication flow that shows all the options.

Important to note is that bucket owners are owners on all objects inside that bucket, regardless of any policies set within that bucket. See https://docs.aws.amazon.com/AmazonS3/latest/dev/access-control-overview.html for more information. Obviously, the guidance from AWS is to not use root credentials for access to storage accounts, rather create an IAM user and apply appropriate policies.

Azure storage functions in a very similar fashion to AWS S3. Firstly, anyone with appropriate permissions to the management plane of a storage account can also have full access to all items in the storage account. This is controlled via access to one of the two storage access keys (shared keys) that are provisioned with every account. RBAC permissions here are fairly important (which we will talk about later).

SAS tokens were originally introduced to solve issues with using shared keys for temporary access to the object storage. SAS tokens provide a way of generating temporary credentials that can be used to a subset of permissions for a period of time.

SAS tokens are not associated with users, which has inherent benefits and tradeoffs. The benefit is that I don't need to have a user object associated with each token. The tradeoff is that managing and revoking SAS tokens becomes a bit of a chore. In a way, SAS Policies can be seen as an entity equivalent to IAM users. AWS STS can be seen (used) in a similar fashion to SAS tokens.

In short, it seems like both solutions (while architected quite differently) facilitate many of the common use cases one may require.

1. Administrative access to buckets and objects

In AWS and Azure this is inherent in the design. Having appropriate access at the management plane level allows for access at the data plane level. In AWS, this is done via the policy system whereas in Azure this is done by controlling access to the shared access keys.

2. Granular user access

In AWS, this type of access is easily provisioned as part of IAM users/roles configuration. In Azure, SAS tokens are used to provide granular access, but are not tied to users specifically. Concepts such as SAS Policies can be used to facilitate this. AAD based permissions (currently in preview) provides a better story around this use case.

3. Temporary credentials

The valet key pattern is a core pattern from an application architecture standpoint. In Azure, this is easily accomplished via SAS tokens and policies. Each request can generate an appropriate SAS token which expires automatically.

In AWS, this is likely a combination of IAM users and AWS STS for issuing temporary credentials.