Attribute-Based Access Control (ABAC)

  • Updated on Jan 31, 2026
  • Published on Jan 26, 2026
  • 6 minute(s) read
Prev Next

Overview

Attribute-Based Access Control (ABAC) lets you authorize user access based on attributes set for users in an authentication and authorization provider.

With VAST Data implementation of Attribute-Based Access Control (ABAC), users are assigned ABAC attributes (in Active Directory), and files are assigned ABAC tags (per view on a VAST cluster). A user is granted access to an ABAC-tagged file when one of the user's ABAC attributes matches an ABAC tag of the file. The type of access - read-only or read/write - is determined based on the value set for the user's ABAC attribute in Active Directory.

In case of a conflict between ABAC access resolution and the access granted by the file's ACL, the most restrictive setting applies. For example, if an ACL allows access for a user but the user does not have the required ABAC attributes, access is denied. Similarly, if ABAC grants access to the user while the ACL does not allow user access, the access is denied.

VAST Cluster supports ABAC for NFSv4 with Kerberos authentication, SMB with Kerberos or NTLM authentication, and S3. ABAC is supported for views controlled with the SMB, S3 Native and Mixed Last Wins security flavors, as shown in the following table. ABAC is not supported for NFSv3.

NFS flavor

SMB flavor

Mixed Last Wins flavor

S3 Native flavor

NFSv3

No

No

No

No

Set POSIX ACL

No

N/A

No

N/A

NFSv4

No

No

Yes

No

Set NFSv4 ACL

No

N/A

Yes

N/A

SMB

No

Yes

Yes

No

Set NT ACL

N/A

Yes

Yes

N/A

S3

No

No

Yes

Yes

Set S3 ACL

N/A

N/A

Yes

Yes

VAST Database

N/A

N/A

N/A

No

Any files and directories within an ABAC-tagged view inherit the ABAC tags from the view. If a view is created under an ABAC-tagged view, the child view inherits the ABAC tags from the parent view.

The following rules and limitations apply to ABAC-tagged views:

  • Once assigned, you cannot edit or remove the ABAC tags of a view. Assigning new ABAC tags to an existing view or directory (storage path) is not allowed.

  • After a child view inherits ABAC tags from the parent view, you cannot update or remove the ABAC tags on the child view.

  • If you create a view for a directory that already exists, ABAC tags from the existing directory are assigned to the newly created view. In this case, there can be a delay between the view creation time and the time when the view's ABAC tags can be displayed.

  • If a user does not have any ABAC permissions, the user still can mount an NFSv4 export or map a SMB share to a local drive, but the user is not allowed to perform any operations on the files or directories.

The following features and capabilities cannot be used together with ABAC-tagged views:

  • When using NFSv4, it is not allowed to create hardlinks in views that have ABAC tags.

  • When using S3:

    • ABAC cannot be used with anonymous S3 access. You cannot set ABAC tags for views that have anonymous S3 access enabled.

    • It is not allowed to set ABAC tags on a view that is a target for S3 bucket logging.

    • Requests from S3 superusers are handled in the same way as for regular users. This means that an S3 superuser is not granted access if the ABAC access check denies access for this user.

  • A directory under which an ABAC-tagged view exists, cannot be moved to the Trash folder.

  • Bulk permission updates are not available for ABAC-tagged views.

  • Lifecycle rules cannot be set for files or directories with ABAC tags.

To configure ABAC:

  1. Define a set of ABAC values in VAST Cluster.

  2. Configure users with ABAC attributes and their values in Active Directory.

  3. Create a view and assign ABAC tags to the view in VAST Cluster.

Defining Values for ABAC Attributes

VAST Cluster expects that ABAC attributes that are assigned to users in Active Directory, have either of the following values specified:

  • A value that grants read-only access.

    When this value is specified in the user's ABAC attribute entry in the authorization provider, this user is allowed to perform operations that require read-only access (such as NFSv4 READDIR) on objects that have an ABAC tag matching the user's ABAC attribute.

  • A value that grants read/write access.

    This value must be set in the user's ABAC attribute entry to allow for read/write access.

By default, a value of ro is used to grant read-only access, and a value of rw is used to grant read/write access.

Tip

For a complete list of operations that require a read-only or read/write ABAC attribute value, see Protocol Operations and ABAC Attribute Values.

Configuring Users with ABAC Attributes in Active Directory

You assign ABAC attributes and their values to users in Active Directory, outside VAST Cluster.

The following rules and limitations apply:

  • VAST Cluster supports only Active Directory as a provider which contains ABAC attributes. NIS or LDAP providers cannot be used with VAST implementation of ABAC.

  • ABAC users may reside in multiple domains. Storing ABAC attributes in the Active Directory Global Catalog is not required.

  • An ABAC provider can include up to 2048 users with ABAC attributes and up to 128 ABAC attribute names defined.

  • Each ABAC attribute name can be up to 50 characters.

Working with Multiple ABAC Attributes

If a view has more than one ABAC tag assigned and a user is missing one of the matching ABAC attributes, permissions are resolved in the most restrictive way.

Consider the following example:

A view named MyAssets has two ABAC tags, engineering and marketing. Users are configured as follows:

  • Marta has two matching ABAC attributes that grant read/write access to both engineering and sales information: engineering=rw and marketing=rw.

  • Jim is configured to have read/write access to engineering resources and read-only access to marketing information: engineering=rw and marketing=ro.

  • Karen is assigned engineering=rw and marketing=ab, where the latter grants unknown access type ab to marketing information.

  • Sofia has no matching ABAC attributes assigned.

As a result of this configuration:

  • Marta can view and modify resources on the MyAssets view.

  • Jim can view the resources but cannot modify them.

  • Karen and Sofia cannot view or modify the resources.

Creating an ABAC-Tagged View

In VAST Cluster, create a view and assign ABAC tags to the view.

An ABAC-tagged view cannot have NFSv3, S3 Endpoint or Database listed among its access protocols.

If NFSv4 is enabled on the view:

  • Kerberos authentication is required.

  • Root squashing needs to be disabled.

Up to 20 ABAC tags can be defined per view. ABAC tags are case-sensitive and can include up to 50 alphanumeric characters, hyphens (-), colons (:), plus signs (+), and underscores (_).

To assign ABAC tags when creating a view:

  • In VAST Web UI, go to Element Store -> Views and click the Create View button. In the Create View dialog that opens, go to the Attribute-Based Access Control (ABAC) tab and enter a comma-separated list of ABAC tags in the Attribute field.

    Tip

    For a complete view creation procedure, see Creating Views.Creating Views

Note

When creating an ABAC-tagged view, VAST Cluster always creates a new directory for the newly created view even if the corresponding option has not been specified.

Protocol Operations and ABAC Attribute Values

The following table shows which access protocol operations require that a user has an ABAC attribute value that grants read/write or read-only access to an ABAC-tagged view.

ABAC Attribute Value

NFSv4

SMB

S3

A value for read-only access (ro)

  • OPEN

  • READ

  • GETATTR

  • READDIR

  • LOCKT

  • READLINK

  • CREATE (when opening an existing file or directory, or truncating a file)

  • READ

  • QUERY_DIRECTORY

  • QUERY_INFO

  • CHANGE_NOTIFY

  • LOCK

  • IOCTL:

    • FSCTL_DFS_GET_REFERRALS

    • FSCTL_DFS_GET_REFERRALS_EX

    • FSCTL_PIPE_PEEK

    • FSCTL_PIPE_WAIT

    • FSCTL_PIPE_TRANSCEIVE

    • FSCTL_SRV_ENUMERATE_SNAPSHOTS

    • FSCTL_SRV_REQUEST_RESUME_KEY

    • FSCTL_SRV_READ_HASH

    • FSCTL_LMR_REQUEST_RESILIENCY

    • FSCTL_QUERY_NETWORK_INTERFACE_INFO

    • FSCTL_VALIDATE_NEGOTIATE_INFO

  • Bucket-level operations:

    • GetBucketAcl

    • GetBucketLocation

    • HeadBucket

    • ListBucketMultipartUploads

    • ListObjects

    • ListObjectsV2

    • ListBucket

    • ListParts

    • GetBucketTagging

    • GetLifecycleConfiguration

    • GetBucketObjectLockConfiguration

  • Object-level operations:

    • GetObject

    • GetObjectAcl

    • HeadObject

    • GetObjectTagging

    • GetObjectRetention

    • GetObjectVersion

    • GetObjectVersionAcl

    • GetObjectLegalHold

    • ListObjectVersions

A value for read/write access (rw)

  • CREATE

  • OPEN (when creating a new file or truncating an existing file)

  • LINK

  • REMOVE

  • RENAME

  • WRITE

  • SETATTR

  • LOCK

  • CREATE (when creating a new file or directory)

  • SET_INFO

  • WRITE

  • IOCTL:

    • FSCTL_SRV_COPYCHUNK

    • FSCTL_SRV_COPYCHUNK_WRITE

    • FSCTL_SET_REPARSE_POINT

    • FSCTL_FILE_LEVEL_TRIM

  • Bucket-level operations:

    • CopyObject

    • DeleteObject

    • DeleteObjects

    • DeleteBucket

    • CreateMultipartUpload

    • UploadPart

    • UploadPartCopy

    • AbortMultipartUpload

    • CompleteMultipartUpload

    • PutBucketAcl

    • PutObject

    • PutBucketTagging

    • DeleteBucketTagging

    • PutLifecycleConfiguration

    • PutBucketObjectLockConfiguration

    • PutBucketVersioning

    • PutBucketPolicy

    • DeleteBucketPolicy

    • PutBucketNotificationConfiguration

    • PutBucketOwnershipControls

    • DeleteBucketOwnershipControls

    • PutBucketLogging

  • Object-level operations:

    • PutObjectAcl

    • PutObjectTagging

    • DeleteObjectTagging

    • DeleteObjectVersion

    • PutObjectLegalHold

    • PutObjectRetention

    • BypassGovernanceRetention

Related articles