Predefined roles and permissions in watsonx.data

Controlling access to the engines and other components is a critical requirement for many enterprises. To ensure that the resource usage is under control, IBM® watsonx.data provides the ability to manage access controls on these resources. A user with admin privileges on the resources can grant access to other users.

watsonx.data on IBM Software Hub

All users have access to the default iceberg-storage and hive-storage MinIO buckets, and default iceberg_data and hive_data Presto catalogs. An admin must grant explicit privileges to users who need access to the presto-01 engine.

The access control at the infrastructure level allows administrators to grant specific access to the wxd components—engines, catalogs, buckets, services, and databases.

  • With watsonx.data version 2.0 and earlier:
    • Users from CPD cluster must have admin role to activate their storage.
    • Users with manager role on the engine can register their own storage but cannot activate the storage. They must contact the admin to activate their storage.
  • With watsonx.data version 2.0.1 and later, users without admin role also can add their storage. The storage becomes online without activation.
  • Data access by using Presto engines is controlled by catalog roles (controlling the admin and user role privileges). The watsonx.data roles are mapped to their roles in the platform.
  • The catalog user role can access data only if the user is the data owner (that is, the creator of the schema or table) or has specific permissions such as select, insert through data policies.

Default roles in watsonx.data

In watsonx.data, the following default roles are supported:
  • Admin
  • User
  • Metastore Admin
  • Metastore Viewer

The following table explains the allowed actions for each role.

Table 1. Role-based access and privileges in watsonx.data
Action Admin User Metastore Admin Metastore Viewer
Create Presto (Java) or Presto (C++) engines ✓      
Register Spark engines ✓      
Create Milvus services ✓      
Delete Milvus services ✓      
View Milvus services ✓      
Restart the internal HMS ✓      
Scale Presto (Java) or Presto (C++) engines ✓      
Unregister any storage ✓      
Unregister any DB Connection ✓      
Activate cataloged buckets (restart HMS) ✓      
Register and unregister own storage ✓ ✓ ✓ ✓
Register and unregister own DB connection ✓ ✓ ✓ ✓
Access the metastore ✓   ✓  
Read access to HMS API ✓   ✓ ✓
Run Spark ingestion jobs ✓   ✓  

Engines

An admin must grant explicit privileges to users who need access to an engine. The following tables explain the permitted actions for each role.

Presto (Java) or Presto (C++)
The following table explains the allowed actions for each role.
Table 2. Role-based access and privileges for Presto (Java) or Presto (C++) engine
Action Admin Manager User
Delete ✓    
Grant and revoke access ✓    
Pause and resume ✓ ✓  
Restart ✓ ✓  
Associate and disassociate catalog ✓ ✓  
Access the Presto (Java) or Presto (C++) query monitor UI ✓ ✓  
View the engine ✓ ✓ ✓
Run workloads against the engine ✓ ✓ ✓
External Spark
The following table explains the allowed actions for each role.
Table 3. Role-based access and privileges for external Spark engine
Action Admin Manager User
Delete ✓    
Grant and revoke access ✓    
Update Spark engine metadata (like tags and description) ✓ ✓  
View the engine ✓ ✓ ✓
Run workloads against the engine ✓ ✓ ✓
Native Spark
The following table explains the allowed actions for each role.
Table 4. Role-based access and privileges for native Spark engine
Actions Admin Manager User
Delete an engine ✓    
Grant access ✓    
Revoke access ✓    
Update Spark engine details (tags, description, version and configuration) ✓ ✓  
View an engine ✓ ✓ ✓
Run workloads against the engine ✓ ✓ ✓
Start Spark history server ✓ ✓ ✓
Stop Spark history server ✓ ✓ ✓
View Spark history UI ✓ ✓ ✓
View Spark UI ✓ ✓ ✓
Associate catalog ✓ ✓  
Disassociate catalog ✓ ✓  
Co-located Spark (deprecated)

Role-based access control (RBAC) is based on zen service instance roles on Spark IAE instances.

Services

Milvus
The following table explains the allowed actions for each role.
Table 5. Role-based access and privileges for Milvus
Action Admin Editor Viewer User Database creator (implicit role) Collection creator (implicit role) Partition creator (implicit role)
View assigned Milvus service ✓ ✓ ✓ ✓      
Delete assigned Milvus service ✓            
Grant access to assigned Milvus service ✓            
Revoke access from assigned Milvus service ✓            
Pause Milvus service ✓            
Resume Milvus service ✓            
Collection CreateIndex ✓ ✓     ✓ ✓  
Collection DropIndex ✓ ✓     ✓ ✓  
Global CreateCollection ✓ ✓     ✓    
Global DescribeCollection ✓ ✓ ✓   ✓ ✓  
Global ShowCollections ✓ ✓ ✓   ✓    
Global CreateAlias ✓ ✓     ✓    
Global DropAlias ✓ ✓     ✓    
Global DescribeAlias ✓ ✓ ✓   ✓    
Global ListAliases ✓ ✓ ✓   ✓ ✓  
Global FlushAll ✓ ✓          
Global CreateResourceGroup ✓            
Global DropResourceGroup ✓            
Global DescribeResourceGroup ✓            
Global ListResourceGroups ✓            
Global TransferNode ✓            
Global TransferReplica ✓            
Global CreateDatabase ✓ ✓          
Global DropDatabase ✓ ✓     ✓    
Global ListDatabases ✓ ✓ ✓        
Collection IndexDetail ✓ ✓ ✓   ✓ ✓  
Collection Search ✓ ✓ ✓   ✓ ✓ ✓
Collection Query ✓ ✓ ✓   ✓ ✓ ✓
Collection Load ✓ ✓     ✓ ✓ ✓
Collection GetLoadingProgress ✓ ✓     ✓ ✓  
Collection GetLoadState ✓ ✓     ✓ ✓  
Collection Release ✓ ✓     ✓ ✓ ✓
Collection RenameCollection ✓ ✓     ✓ ✓  
Collection DropCollection ✓ ✓     ✓ ✓  
Collection Insert ✓ ✓     ✓ ✓ ✓
Collection Delete ✓ ✓     ✓ ✓ ✓
Collection Flush ✓ ✓     ✓ ✓  
Collection GetFlushState ✓ ✓     ✓ ✓  
Collection Upsert ✓ ✓     ✓ ✓ ✓
Collection GetStatistics ✓ ✓     ✓ ✓  
Collection Compaction ✓ ✓     ✓ ✓  
Collection Import ✓ ✓     ✓ ✓  
Collection LoadBalance ✓ ✓     ✓ ✓  
Collection CreatePartition ✓ ✓     ✓ ✓  
Collection DropPartition ✓ ✓     ✓ ✓ ✓
Collection ShowPartitions ✓ ✓ ✓   ✓ ✓  
Collection HasPartition ✓ ✓ ✓   ✓ ✓ ✓

Storage

All users can add their own storage and have admin access to it. Other users do not have access until they are granted explicit access. The following table explains the allowed actions for each role.

Table 6. Role-based access and privileges for storage
Action Admin Writer Reader Users without an explicit role
Unregister ✓      
Update storage properties (credentials) ✓      
Grant and revoke access ✓      
Modify files ✓ ✓    
Browse (storage browser in UI) ✓ ✓ ✓  
View the storage ✓ ✓ ✓ ✓
S3 REST API permissions (specific to IBM Spark and DAS)
Users can get a relative storage role for all subfolders and files in a storage or can be granted file action for particular folders or files. The following tables explain the storage-level and data-object-level S3 REST API permissions.
Note: The following tables are applicable only if you are using IBM Spark that by default uses a DAS signature or if you are using DAS proxy.
Storage-level access control
To assign storage-level access, go to Access control > Infrastructure or go to Infrastructure manger > select storage and assign roles.
Table 7. Storage-level access control
Storage role S3 REST API permission
Reader GET; HEAD
Writer GET; HEAD; PUT; POST; PATCH; DELETE
Admin GET; HEAD; PUT; POST; PATCH; DELETE
Data-object-level access control
To assign data-object-level access control, go to Access control > Policies.
Table 8. Data-object-level access control
Data object action S3 REST API permission
Read GET; HEAD
Write GET; HEAD; PUT; PATCH; POST without ?delete parameter
Delete DELETE; POST with ?delete parameter

Database

All users can add their own database and have admin access to it. Other users do not have access until they are granted explicit access. The following table explains the allowed actions for each role.

Table 9. Role-based access and privileges for database
Action Admin Writer Reader Users without an explicit role
Unregister ✓      
Update db conn properties (credentials) ✓      
Grant and revoke access ✓      
Modify database objects ✓ ✓    
View the database ✓ ✓ ✓ ✓

Catalog

Every storage or a database must have a catalog that is associated with it. Admin of the storage or database is the admin of the associated catalog. Other users do not have access until they are granted explicit access.

The following table explains the allowed actions for each role.

Table 10. Role-based access and privileges for catalog
Action Admin User
Delete ✓  
Grant and revoke access ✓  
Access to data ✓ Based on data policy
View the catalog ✓ ✓
Note: If you want to delete a catalog, you must first dissociate the catalog from the engine.

Schema

The following table explains the allowed actions for each role.

Action Catalog Admin or schema creator Others
Grant and revoke access ✓  
Drop ✓  
Access ✓ based on access data control policies defined in watsonx.data by admin
Create table ✓ based on access data control policies defined in watsonx.data by admin

Table

The following table explains the allowed actions for each role.

Action Catalog Admin or schema admin or table creator Others
Create, drop, and alter ✓ based on access data control policies defined in watsonx.data by admin
Column access ✓ based on access data control policies defined in watsonx.data by admin
Select ✓ based on access data control policies defined in watsonx.data by admin
Insert ✓ based on access data control policies defined in watsonx.data by admin
Update ✓ based on access data control policies defined in watsonx.data by admin
Delete ✓ based on access data control policies defined in watsonx.data by admin