Row and Column Security

The VAST Database supports row and column security features to restrict access to specific rows or columns in a table based on user identity.

These features are applied using statements in identity or bucket policies. These statements determine access to specific database resources according to user identity.

The following security features are supported:

These row filters and column masks are applied by the Query Engine (the filter clauses to be applied are returned by the VAST Database).

To configure row and column security, include a RowColumnSecurity block statement inside the Identity Policy framework:

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect": "RowColumnSecurity",
         ("Resource" | "NotResource"): ("*" | [<resource1>, <resource2>, ...])
         ("ColumnAllow"|"ColumnDeny"): ("*" | ["<column_name1>", "<column_name2>", ...]),
         "RowFilter": [{"QueryEngine":("*"|[<query_engine1>, <query_engine2>, ...]),
                        "FilterString": <row_filter_string1>},
                       {"QueryEngine":("*"|[<query_engine1>, <query_engine2>, ...]),
                        "FilterString": <row_filter_string2>}, ...]
         "ColumnMask": [{"QueryEngine":("*"|[<query_engine1>, <query_engine2>, ...]),
                         "ColumnName": <column_name1>,
                         "MaskString": <function_string1>},
                        {"QueryEngine":("*"|[<query_engine1>, <query_engine2>, ...]),
                         "ColumnName": <column_name2>,
                         "MaskString": <function_string2>}, ...]
          "RowFilterByS3PathAuth": ("True"|"False")
      }
   ]
}

Note

The Resource element parameter block targets a specific database table, view layout schema, or object directory path path string.

The RowFilter policy statement acts as an automated constraint that dynamically filters matching rows out of data query results.

Review the following configuration block snippet example:

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect": "RowColumnSecurity",
         "Resource": ["my_bucket/my_schema/*"],      
         "RowFilter": {"QueryEngine":"Trino", "FilterString": "COL1='abc'"}   
      }  
   ]
}

This policy statement introduces a supplementary logical constraint equivalent to an inline SQL WHERE COL1='abc' conditional parameter clause. This action restricts query outputs for tables inside the my_bucket/my_schema path directory whenever column COL1 equals string target value 'abc'.

The ColumnAllow or ColumnDeny parameters restrict column visibility within table query outputs.

Consider the following configuration block snippet example:

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect": "RowColumnSecurity",
         "Resource":  ["my_bucket/my_schema/*"],
         "ColumnDeny": ["my_col1", "my_col2"] 
      }
   ]
}

This statement block prevents columns my_col1 and my_col2 from rendering within query profiles inside my_bucket/my_schema. Unlisted columns are returned normally.

Note

Including a ColumnAllow entry automatically excludes all unlisted columns from query outputs. Conversely, using ColumnDeny outputs all table variables except those explicitly blocked. If both statement types are defined concurrently, all target columns are excluded except for entries validated by ColumnAllow.

Caution

Security tracking elements can only evaluate top-level parent database columns. Nested structurally embedded child variables are not supported.

The ColumnMask attribute replaces or obfuscates core records returned by database queries using regular expression evaluations, such as regexp_replace.

Consider the following configuration block snippet example:

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect": "RowColumnSecurity",
         "Resource":  ["my_bucket/my_schema/*"],
         "ColumnMask": [{"QueryEngine":["Trino", "Spark"],
                         "ColumnName": "my_col_email",
                         "MaskString": "regexp_replace(my_col_email, '.*', '***')"}]
      }
   ]
}

This policy rule configuration masks records matched within my_col_email, substituting data text blocks with a generic '***' literal sequence.

The following example demonstrates how to overwrite columns matching type Int with a static value string replacement placeholder:

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect": "RowColumnSecurity",
         "Resource":  ["my_bucket/my_schema/*"],
         "ColumnMask": [{"QueryEngine":["Trino", "Spark"],
                         "ColumnName": "my_col_email",
                         "MaskString": "CAST('123' AS INT)"}]
      }
   ]
}

To activate verification mechanisms, toggle the boolean parameter flag within the policy structure:

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "RowFilterByS3PathAuth": "True"
      }
   ]
}

When enabled, the system evaluates rows inside the target table's vastdb_s3_path_auth column directory. This path column has comma-separated objects structured as "bucket_name/object_name" strings. The query engine matches user permissions against applicable bucket policy structures. If the endpoint identity maintains valid get-object action clearance for all entries declared inside the row cell, the record data is returned.

Consider the following sample source validation data layout table mapping:

+----------------+-----------+------------------------------------------------+
| COL1           | COL2      | vastdb_s3_path_auth                            |
+----------------+-----------+------------------------------------------------+
| record_01      | data_01   | "my_bucket/path1"                              |
+----------------+-----------+------------------------------------------------+
| record_02      | data_02   | "my_bucket/path2"                              |
+----------------+-----------+------------------------------------------------+
| record_03      | data_03   | "my_bucket/path1","my_bucket/path2"            |
+----------------+-----------+------------------------------------------------+
| record_04      | data_04   | "my_bucket/path1/path3"                        |
+----------------+-----------+------------------------------------------------+

If the requesting identity holds explicit get_object clearance for path1 but lacks authorization for path2 or sub-directories like path3, the filtered database query execution drops rows two, three, and four, returning only row one.

Caution

The vastdb_s3_path_auth column can only be defined during initial table creation. Once initialized, this tracking variable framework cannot be modified, structurally updated, or dropped. Cells may contain null entries; however, write or update insertions are strictly validated against standard pathname path structural validation schemas.

Using row and column security statements requires user impersonation parameters to be enabled for cluster database transformations. This allows client query engines to forward original user credentials directly during evaluations, ensuring permissions are measured against the active query owner rather than background engine access accounts.

Consider the syntax statement structure below for activating credential proxy tracking parameters inside the Identity Policy framework:

{
  "Version": "2012-10-17",
  "Statement": [
     {
      "Sid": "Get row and column security configuration for Tabular operations",
      "Effect": "Allow",
      "Action": "s3:TabularGetRowColumnSecurity",
      "Resource":  ["arn:aws:s3:::my_bucket/my_schema/*"]
    },
    {
      "Sid": "Allow end user impersonation on Tabular operations",
      "Effect": "Allow",
      "Action": "s3:TabularEndUserImpersonation",
      "Resource":  ["arn:aws:s3:::*"]
    }
  ]
}

Alternatively, you can configure these options within the management console interface by adding custom rule statements located under Database/Advanced Security/EndUserImpersonation and TabularGetRowColumnSecurity.

Security rule operations are supported for these Query Engines, whether run as Managed applications on a VAST cluster, or as an external client:

Caution

While Spark environments execute table transformations, native proxy user impersonation parameters are not supported within Spark query operations.

If row filtering or column masking clauses are defined in a policy for a user on a table, then the user may only query the table using one of the query engines specified in the policy.