Access

Applies to VAST Cluster 5.5.

What to ask your platform team for so that your application can use a bucket or an export, how identity and bucket policies affect your requests, how to use temporary credentials, and how to check what your key can do. Creating views, users, keys and policies is an admin task; this page tells you what to request.

What to ask for

What your platform team sets up, in order, before you connect.

Identity policies

With the S3 Native flavor, identity policies are the main way to grant access. They use the AWS IAM JSON format (version 2012-10-17) with a subset of its elements, and are attached to users, groups or IAM roles. Policies are checked before S3 ACLs: an explicit deny wins, then an allow, and only if no policy decides are ACLs checked. Per-user settings in VMS (allow create bucket, allow delete bucket) are overridden by policies.

Admin task: send to your platform team. Read and write under one prefix of one bucket, and list only that prefix:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListOwnPrefix",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::analytics-landing",
      "Condition": {"StringLike": {"s3:prefix": "ingest/*"}}
    },
    {
      "Sid": "ReadWriteOwnPrefix",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:AbortMultipartUpload",
                 "s3:GetObjectTagging", "s3:PutObjectTagging"],
      "Resource": "arn:aws:s3:::analytics-landing/ingest/*"
    }
  ]
}

The actions each S3 request needs are in S3 compatibility. Conditions can test, among others, the client's address (aws:SourceIp), the user (aws:username), the listing prefix (s3:prefix) and an object's tags (s3:ExistingObjectTag/<key>). KB: Identity and Bucket Policy Reference.

The same policies also decide NFS and SMB requests that map to S3 actions on that view: a policy without s3:GetObject means no NFS reads either (multiprotocol access).

Bucket policies

A bucket policy is attached to the bucket's view and names the users or groups it applies to in a Principal. Unlike identity policies, you can manage it yourself with the S3 API if you own the bucket (or have s3:PutBucketPolicy): put_bucket_policy, get_bucket_policy and delete_bucket_policy. It needs the S3 Native flavor, there's one per bucket (a new one replaces the old), and it can be up to 20 KB.

For example, to let a group read the whole bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AnalystsRead",
      "Effect": "Allow",
      "Principal": {"Group": "analysts@example.com"},
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["arn:aws:s3:::analytics-landing", "arn:aws:s3:::analytics-landing/*"]
    }
  ]
}

import json

s3.put_bucket_policy(Bucket="analytics-landing", Policy=json.dumps(policy))
print(json.loads(s3.get_bucket_policy(Bucket="analytics-landing")["Policy"])["Statement"][0]["Sid"])

Principals are VAST users and groups by name, as name@domain for directory users, or "*" for everyone. A bucket policy's resources must be in its own bucket.

Temporary credentials

The cluster runs a Security Token Service (STS). An application can assume an IAM role and get a temporary key pair with a session token, instead of holding a long-lived key:

• AssumeRole, signed with a permanent key pair of a user the role's trust policy allows.
• AssumeRoleWithWebIdentity, with a JSON web token from an OIDC provider such as Okta, Entra ID or Keycloak, for users who have no VAST key at all.

Requests then run with the role's policies, optionally narrowed by a session policy you pass. Objects you create are owned by the role (or by the bucket owner, depending on the bucket's configuration). The STS endpoint is any protocol VIP of the cluster, over HTTPS only. The role ARN is arn:vast:iam::<tenant>:role/<role name>, and the duration can be 15 minutes to 36 hours, up to the role's maximum.

import os

import boto3
from botocore.config import Config

sts = boto3.client("sts", endpoint_url="https://s3.example.com", region_name="us-east-1")
creds = sts.assume_role(
    RoleArn="arn:vast:iam::my-tenant:role/analytics-reader",
    RoleSessionName="nightly-report",
    DurationSeconds=3600,
)["Credentials"]

s3 = boto3.client(
    "s3",
    endpoint_url="https://s3.example.com",
    region_name="us-east-1",
    aws_access_key_id=creds["AccessKeyId"],
    aws_secret_access_key=creds["SecretAccessKey"],
    aws_session_token=creds["SessionToken"],
    config=Config(signature_version="s3v4", s3={"addressing_style": "path"}),
)
print(creds["Expiration"], s3.list_objects_v2(Bucket="analytics-landing", MaxKeys=1)["KeyCount"])

Your platform team can revoke all keys issued for a role. Admin task: send to your platform team to create the role and its trust policy: Security Token Service (STS) and IAM Roles.

Creating your own key pair

If you're an Active Directory or LDAP user and your platform team has allowed it, you can create, list and delete your own S3 key pairs through the VMS REST API, with your directory credentials:

# not-run: needs a directory user and the VMS address
curl -u "<your user>" -X POST "https://<VMS address>/api/s3keys/"
curl -u "<your user>" -X GET "https://<VMS address>/api/s3keys/"

The response to the POST is the only time you see the secret key. Only users of the Active Directory domain the cluster is joined to can do this.

Anonymous access

Unsigned requests are refused unless your platform team enables anonymous access on the view. Even then, what an anonymous request may do depends on the flavor: with S3 Native, an ACL must grant the All Users group; with NFS, the mode bits must allow others; with SMB or Mixed Last Wins, anonymous requests are never allowed. For sharing single objects, prefer presigned URLs.

Check what your key can do

Try each common action on the bucket and print the result. The write test creates and deletes one object under docs-access/:

import os

import boto3
from botocore.config import Config
from botocore.exceptions import ClientError

s3 = boto3.client(
    "s3",
    endpoint_url=os.environ["AWS_S3_ENDPOINT_URL"],
    region_name="us-east-1",
    config=Config(signature_version="s3v4", s3={"addressing_style": "path"}),
)
bucket = os.environ["DATASTORE_BUCKET"]
key = "docs-access/probe.txt"

checks = [
    ("HeadBucket", lambda: s3.head_bucket(Bucket=bucket)),
    ("ListObjectsV2", lambda: s3.list_objects_v2(Bucket=bucket, MaxKeys=1)),
    ("PutObject", lambda: s3.put_object(Bucket=bucket, Key=key, Body=b"probe")),
    ("GetObject", lambda: s3.get_object(Bucket=bucket, Key=key)["Body"].read()),
    ("PutObjectTagging", lambda: s3.put_object_tagging(Bucket=bucket, Key=key, Tagging={"TagSet": [{"Key": "probe", "Value": "1"}]})),
    ("DeleteObject", lambda: s3.delete_object(Bucket=bucket, Key=key)),
    ("GetBucketPolicy", lambda: s3.get_bucket_policy(Bucket=bucket)),
]
for name, call in checks:
    try:
        call()
        print(f"{name:<17} OK")
    except ClientError as e:
        print(f"{name:<17} {e.response['Error']['Code']}")

HeadBucket        OK
ListObjectsV2     OK
PutObject         OK
GetObject         OK
PutObjectTagging  OK
DeleteObject      OK
GetBucketPolicy   NoSuchBucketPolicy

AccessDenied means the policy, ACL or file permissions refuse that action; NoSuchBucketPolicy from GetBucketPolicy means you may read the policy but there isn't one. See troubleshooting.

See also

• CI/CD and automation: views, users, keys and policies in code.
• Setup prerequisites for VAST DataBase, which uses the same keys and endpoints.