Getting Started With Files

When you add or update a file, Vendia stores a copy of the source object from its original location in each participant in your Uni. While Vendia handles the complexities of participant-to-participant copies within any given uni, the initial copy (sometimes referred to as “on-chaining” the file) requires that any node handling the Files operations has access to any cloud resources used as source data.

Vendia abides by security best practices for each of our supported Cloud Service Providers. The instructions for granting Vendia access to add or update files depends on the Cloud Service Provider for a given node.

AWS Nodes

For AWS nodes, performing Files mutations requires that the Vendia proxy account assigned to your node has been granted read access to the S3 bucket being used as a source.

Getting a Node’s Proxy Account ID

Each node has its proxy AWS account ID recorded as a part of the Vendia_UniInfo entity, which can be fetched with the following GraphQL query

Sample Request

query getNodeAccountInfo {
  getVendia_UniInfo {
    name
    nodes {
      name
      vendiaAccount {
        accountId
        csp
      }
    }
  }
}

Sample Response

{
  "data": {
    "getVendia_UniInfo": {
      "name": "an-example-uni.unis.vendia.net",
      "nodes": [
        {
          "name": "SomeNode",
          "vendiaAccount": {
            "accountId": "[YOUR NODE ACCOUNT ID]",
            "csp": "AWS"
          }
        }
      ]
    }
  }
}

Make note of the value returned at data.getVendia_UniInfo.nodes[].vendiaAccount.accountId.

Update the Bucket Policy on your S3 bucket

Paste that account ID twice into the IAM policy document below and fill in your S3 bucket name for the resource. The /* resource can be scoped to any specific prefix of the S3 bucket, such as /my-archive/photos/*.

Sample Bucket Policy

{
  "Version": "2012-10-17",
  "Id": "AllowVendiaToReadFiles",
  "Statement": [
    {
      "Sid": "AllowBucketInfoRead",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::[YOUR NODE ACCOUNT ID]:root"
      },
      "Action": ["s3:GetBucketLocation", "s3:GetBucketVersioning"],
      "Resource": "arn:aws:s3:::your-bucket-name-here"
    },
    {
      "Sid": "AllowObjectRead",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::[YOUR NODE ACCOUNT ID]:root"
      },
      "Action": ["s3:GetObject", "s3:GetObjectVersion"],
      "Resource": "arn:aws:s3:::your-bucket-name-here/*"
    }
  ]
}

Azure Nodes

For Azure nodes, Vendia leverages Microsoft’s stance on use of URLs as a means to access data sourced by Azure Blob Storage within any given storage account.

Pre-signed URLs

Pre-signed URLs containing shared access signatures (SAS) for blobs provide limited delegated access to resources in a storage account. The signed URL specifies the permissions granted to the resource and the interval over which the signature is valid. Microsoft’s documentation provides more information on how a shared access signature works.

The caveat that comes with use of a pre-signed URL as a pointer to a data source is that anyone with access to that value inherently has access to the underlying data. As such, Vendia guarantees that this sensitive information is not, and never will be, written to the ledger.

Anonymous public access URLs

Azure Storage supports optional anonymous public read access for containers and blobs, which must be explicitly enabled when you create your cloud resources; however, Microsoft recommends that this access model be disabled wherever possible.

While Vendia recommends scoping access to your blob data according to the principle of least privilege, using the URL of a publicly-available blob as a data source is supported.

If you are using anonymous public read access for your blob storage and wish to disable it, please see Microsoft’s recommended approach to remediation.