--- title: "Access" slug: "dev-datastore-operations-access" updated: 2026-10-30T18:18:46Z published: 2026-10-30T18:18:46Z canonical: "docs.vastdata.com/dev-datastore-operations-access" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.vastdata.com/llms.txt > Use this file to discover all available pages before exploring further. # 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 ![Five items, in order, then your client connects. 1, platform team: a view with the S3 Bucket protocol, and NFS or SMB on the same view if you need them, with a host rule for NFS clients; or an S3 Endpoint view under which you may create buckets. 2, platform team: the view policy's security flavor, S3 Native for S3-first applications, which decides whose permissions apply. 3, platform team: an endpoint, the DNS name or virtual IPs of a pool that serves your tenant and protocols, over HTTP or HTTPS. 4, platform team: a VAST user with an S3 access key pair. 5, platform team: an identity policy on that user, and bucket policies if you need them. Then your client connects: boto3, the AWS CLI or Spark with the endpoint and key, or an NFS mount of the view.](https://cdn.us.document360.io/89b91113-5dc6-49db-86ec-57b16dc8ce56/Images/Documentation/ds-setup-flow.svg?sv=2026-02-06&spr=https&st=2026-11-08T08%3A55%3A10Z&se=2026-11-08T09%3A55%3A10Z&sr=c&sp=r&sig=fTV9AyO8ORnna3wvIMlkard46GqTocGyetXS4CutUvg%3D) *What your platform team sets up, in order, before you connect.* | You need | Who provides it | Notes | | --- | --- | --- | | A bucket, or an S3 Endpoint view where you may create buckets | Platform team | A view with the S3 Bucket protocol and a bucket owner. KB: [Creating S3 Buckets via VMS](/docs-5-5/docs/creating-s3-buckets-via-vms), [Managing S3 Request-Initiated Bucket Creation](/docs-5-5/docs/managing-s3-request-initiated-bucket-creation). | | NFS (or SMB) on the same view, if you need it | Platform team | Plus a host rule for your clients' addresses. KB: [Managing Views](/docs-5-5/docs/managing-views). | | The view policy's security flavor | Platform team | Decides whether policies apply at all ([concepts](/develop/docs/dev-datastore-concepts-index#what-decides-whether-a-request-is-allowed)). For S3-first applications ask for **S3 Native**. It can't be changed later on a view with a bucket. | | An endpoint | Platform team | The DNS name or VIPs of a virtual IP pool that serves your tenant and protocols, and whether to use HTTP or HTTPS (and the CA certificate if it isn't publicly trusted). | | A user with an S3 access key pair | Platform team | One key pair per application is easiest to audit and rotate. KB: [Managing S3 User Permissions](/docs-5-5/docs/managing-s3-user-permissions). | | An identity policy on that user (or its group) | Platform team | See below. KB: [Managing Identity Policies](/docs-5-5/docs/managing-identity-policies). | | An IAM role, if your application should use temporary credentials | Platform team | See [temporary credentials](/develop/docs/dev-datastore-operations-access#temporary-credentials). | ## 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](/develop/docs/dev-datastore-reference-s3-compatibility#supported-requests). 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](/docs-5-5/docs/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](/develop/docs/dev-datastore-guides-multiprotocol#ownership-and-permissions)). ## 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](/docs-5-5/docs/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 "" -X POST "https:///api/s3keys/" curl -u "" -X GET "https:///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](/develop/docs/dev-datastore-guides-s3-objects#share-an-object-with-a-presigned-url). ## 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](/develop/docs/dev-datastore-troubleshooting-index#access-denied). ## See also - [CI/CD and automation](/develop/docs/dev-datastore-operations-ci-cd): views, users, keys and policies in code. - [Setup prerequisites](/develop/docs/dev-database-operations-setup-prerequisites) for VAST DataBase, which uses the same keys and endpoints.