15. Multi-Protocol Access (NFS + S3)

VAST supports multi-protocol access, allowing the same data to be accessed concurrently via NFS (v3/v4) and S3 through a unified, native namespace. This enables seamless access to a single dataset across both file and object protocols, without requiring data duplication, gateways, or transformation. The VAST Element Store provides a shared namespace where file and object protocols operate on the same underlying data structures, ensuring strong consistency and eliminating the need for synchronization between systems. This significantly simplifies data pipelines by avoiding copies and replication, enabling diverse workloads, such as AI/ML training pipelines, analytics workflows, and agentic AI systems, to access and process the same dataset natively across protocols.

NFS Access Model

NFS provides file-based access using POSIX semantics, where authentication and authorization are based on user identity and filesystem permissions.

S3 Access Model

S3 provides object-based access to data using API calls (e.g., GET, PUT, LIST), authenticated via access keys and authorized using a policy-based access control model.

VAST Security Flavors (Permission Enforcement Model)

The Security Flavor defines how permissions are enforced for a View - Configured per View via View Policy to determine:

• Which protocol can set permissions

• How access is evaluated

• How new objects get initial permissions

Available VAST Security Flavors:

• NFS: POSIX mode bits

• SMB: NTFS ACLs

• Mixed (Last Wins): Combined ACL model - Last writer determines permissions

• S3 Native: S3 policies

Reference: Controlling File and Directory Permissions Across Protocols

Using Security Flavors in Multi-Protocol Environments

When exposing the same data via NFS and S3:

• The Security Flavor defines how access is enforced

• There is one permission authority per View

Option 1 – NFS Security Flavor (POSIX Authoritative)

Permissions are defined using POSIX (UID/GID + mode bits)

NFS is authoritative; S3 is a non-native access path

Configuration

• View Policy

  • Security Flavor = NFS

  • Define default POSIX permissions (for non-native access)

• View

  • NFS namespace (path)

• NFS Connectivity

  • VIP Pool

  • Client access (IP / CIDR)

• Identity

  • Local / LDAP / AD (UID/GID mapping)

• S3 Access

  • S3 users (access keys) for connectivity only

  • S3 policies/ACLs are not used for enforcement

Access Flow

• NFS

  • UID/GID provided by client

  • Access enforced using POSIX permissions

• S3

  • Auth via access key

  • Access enforced using POSIX permissions

Option 2 – S3 Native Security Flavor (S3 Authoritative)

Permissions are defined using S3 policies (identity, bucket, ACL)

S3 is authoritative; NFS is a non-native access path

Configuration

• View Policy

  • Security Flavor = S3 Bucket

• View

  • Exposed as S3 bucket namespace

• S3 Setup

  • Enable S3 service (tenant)

  • Create users (access key / secret key)

  • Define permissions via:

    • Identity policies

    • Bucket policies

    • (Optional) ACLs

• NFS Access

  • Client access (IP / CIDR) for mount only

  • No permission control via NFS

Access Flow

• S3

  • Auth via access key

  • Access evaluated using S3 policies and ACLs

• NFS

  • Access evaluated using the S3 permission model

Example Workflow – Multi-Protocol Access (NFS + S3)

This workflow demonstrates how to configure and validate multi-protocol access (NFS + S3) using S3 Native Security Flavor, where:

• S3 is the authoritative permission model

• Identity policies control access (user/group)

• NFS acts as an access path only

• The same data is accessed via both protocols without duplication

This example validates role-based access control (RBAC) using:

• Full-access user

• Read-only group user

Step 1 – Create Identity Policy

Identity policies define what actions a user or group is allowed to perform on S3 resources (e.g., read, write, list).  User Management → Identity Policies → Create

Example Policy

In the example below, the identity policy grants full read/write access to the admin user while restricting the group to read-only access (list and read operations only).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "UserFullAccess",
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    },
    {
      "Sid": "GroupReadOnly",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetObject"
      ],
      "Resource": "*"
    }
  ]
}

Step 2 – Create Group

This example uses local groups and user:  User Management → Local Groups → Create

Step 3 – Create Users

We’re creating 2 different users in the same tenant, but they have different access keys - both tenants are in the same group as well. User Management → Local Users → Create

Note: You need to generate the access key after the users are created.

First user: ‘s3-test-user’:

Step 4 – Create View Policy (S3 Native)

Creating a view policy that uses S3 native security flavor for this example:

Element Store → View Policies → Create

Configuration summary:

Step 5 – Create View (Shared NFS + S3 Namespace)

The View defines the shared namespace that is exposed simultaneously as an S3 bucket and as an NFS export, allowing both protocols to access the same underlying data. The bucket owner is the first user ('s3-test-user'), which means that the second user ('s3-test-user2') has read and list access only in this bucket (view).

Element Store → Views → Create

Configuration summary:

Validation Test

Step 1 – Validate Write via S3 (User1 – Full Access)

export AWS_ACCESS_KEY_ID=<user1_access_key>
export AWS_SECRET_ACCESS_KEY=<user1_secret_key>
export AWS_DEFAULT_REGION=us-east-1

echo "written by user1" > user1.txt

aws --endpoint-url http://172.200.203.3 \
s3 cp user1.txt s3://s3-test/

aws --endpoint-url http://172.200.203.3 \
s3 cp user1.txt s3://s3-test/test.txt

Expected:

✔ User1 can create and overwrite objects

Step 2 – Validate S3 Access (User1)

aws --endpoint-url http://172.200.203.3 s3 ls s3://s3-test/

aws --endpoint-url http://172.200.203.3 \
s3 cp s3://s3-test/test.txt -

Expected:

✔ List

✔ Read

Step 3 – Validate Read-Only Access (User2 via Group)

export AWS_ACCESS_KEY_ID=<user2_access_key>
export AWS_SECRET_ACCESS_KEY=<user2_secret_key>
export AWS_DEFAULT_REGION=us-east-1

aws --endpoint-url http://172.200.203.3 s3 ls s3://s3-test/

aws --endpoint-url http://172.200.203.3 \
s3 cp s3://s3-test/test.txt -

Expected:

✔ List

✔ Read

Step 4 – Validate Write Restriction (User2)

This step is expected to fail because User2 has read-only access.

echo "test write" > fail.txt

aws --endpoint-url http://172.200.203.3 \
s3 cp fail.txt s3://s3-test/

Expected result:

✔ AccessDenied

Step 5 – Mount via NFS

sudo mount -o proto=tcp,nconnect=32,vers=3,remoteports=dns \
172.200.203.3:/s3-test /mnt/mordi

Step 6 – Validate NFS Access (User1)

sudo -u s3-test-user ls -lh /mnt/mordi

Step 7 – Validate NFS → S3 Consistency

Write via NFS:

sudo -u s3-test-user bash -c 'echo "hello from nfs" > /mnt/mordi/nfs.txt'

Read via S3:

export AWS_ACCESS_KEY_ID=<user1_access_key>
export AWS_SECRET_ACCESS_KEY=<user1_secret_key>

aws --endpoint-url http://172.200.203.3 \
s3 cp s3://s3-test/nfs.txt -

Expected:

✔ hello from nfs

Step 8 – Validate S3 → NFS Consistency

Write via S3:

echo "hello from s3" > s3file.txt

aws --endpoint-url http://172.200.203.3 \
s3 cp s3file.txt s3://s3-test/s3file.txt

Read via NFS:

sudo -u s3-test-user cat /mnt/mordi/s3file.txt

Expected:

✔ hello from s3

Step 9 – Validate NFS Access (User2)

User2 must exist on Linux with a matching UID/GID.

sudo -u s3-test-user2 ls -lh /mnt/mordi
sudo -u s3-test-user2 cat /mnt/mordi/test.txt

Expected:

✔ Read works

Step 10 – Validate NFS Write Restriction (User2)

sudo -u s3-test-user2 bash -c 'echo "test write" > /mnt/mordi/fail.txt'

Expected:

✔ Permission denied