Monday, January 21, 2019

AWSvAzure - Object Storage - Blob Access Part 3

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.

As with everything, anonymous access is done a little bit differently in each cloud provider. Azure allows for anonymous access to be turned on in a read-only fashion at the container level. From a permission perspective, there is:
  • No public access
  • Public read/list access
  • Public read access

The difference between 2 and 3 above is simple, one allows for blob enumeration, where as the other you would have to know the exact name of the blob you are trying to reference. In AWS, bucket policies are used to grant anonymous access. Since bucket policies have effectively the same settings as IAM policies, you are allowed to define a principle (in this case *) and a permission set on a set of resources.

In Azure, you can set anonymous access for a container via ARM template. See for more information. For reference:

  "name": "string",
  "type": "Microsoft.Storage/storageAccounts/blobServices/containers",
  "apiVersion": "2018-07-01",
  "properties": {
    "publicAccess": "string",
    "metadata": {}
  "resources": []

Public access is a string that can be either Container, Blob, or None. It is not a required field, and defaults to none. Container = Read/List and Blob = Read Only

In AWS, the bucket policy is easy to define. Here is an example (referenced from

      "Principal": "*",

You could specify any s3 related action you wanted in this bucket policy, allowing for more use cases such as anonymous writes (which is likely not recommended)

No comments:

Post a Comment