Note

This documentation is for a prior release of Kinetica. For the latest documentation, click here.

Security Concepts

Overview

Kinetica provides secured access to data and data services by means of role-based access control (RBAC). Permissions are assigned at the table level, schema level, or globally, and can be assigned either directly or grouped into roles for assignment.

Important

Kinetica users, roles, role assignments, and Workbench permissions should be managed through Workbench. All other database permissions can be managed through Workbench, SQL, or through one of the native APIs.

Users

Kinetica supports authentication and authorization users.

Users must be created via Workbench.

Users have a username and password (encrypted).

A username must meet the following criteria:

  • alphanumeric, including underscore; not starting with a number: [a-z_][a-z_0-9]*
  • unique among usernames and role names
  • up to 64 characters long

A password must meet the following criteria:

  • up to 1024 characters long, by default

A user can be assigned any of the following:

Default Users

Kinetica comes with up to four default users:

  • admin
    • full permissions to do anything in Kinetica
    • system_admin permission by default; unable to modify
    • password assigned during provisioning
    • password can be changed; change will be stored securely in Kinetica
  • anonymous
    • no password
    • no permissions by default
  • graph
  • planner
    • System role reserved for use by the SQL query planner engine

Roles

Roles are configurable sets of permissions, which enable easier maintenance of user authorizations within the database. A role can have any number of permissions assigned to it, and the role can be assigned to any number of users, giving those users all of the permissions associated with the role. A role can also be assigned to another role, creating a hierarchy of permissions. In this way, roles eliminate the need to manage each user's permissions individually.

An individual user's permissions are the set of all directly-granted permissions and permissions granted via roles.

Roles must be created via Workbench.

A role can be assigned any of the following:

A role name must meet the following criteria:

  • alphanumeric, including underscore; not starting with a number: [a-z_][a-z_0-9]*
  • unique among usernames and other role names
  • up to 64 characters long

A role may optionally be assigned a resource group, which will be imparted to any user assigned the role.

Important

A role cannot be assigned, as a member, to any role that is one of its member roles, whether that member role is assigned directly to it or via another role; e.g., if role A has role B as a member, role B cannot be assigned role A as a member directly, nor can role B be assigned role C, if role C has role A as a member.

Default Roles

There are two default roles within Kinetica:

  • authenticated
    • All users except anonymous are members of authenticated by default.
  • public
    • All users are members of public by default.
    • The public role will grant permissions to users who have not authenticated.

Permissions

Permissions allow users various levels of access to the database's data and management services. Permissions can be granted directly to users and also grouped within roles.

There are several categories of permissions within Kinetica:

System Permissions

System permissions govern access to both database objects and management services.

System permissions may be assigned via Workbench to users & roles.

The available permissions are:

  • system_admin
    • can create schemas
    • has table_admin on all tables
    • can manage users & roles
    • can grant/revoke permissions & roles
  • system_write
    • can create schemas
    • has table_admin on all tables and data
    • can upload symbols via /insert/symbol
  • system_read
    • has table_read on all tables
  • system_user_admin
    • can manage users & roles
    • can grant/revoke permissions & roles (except the system_admin permission or a role containing it)

Schema Permissions

Schema permissions govern access to schemas and the database objects within them. Access granted on a schema directly gives permissions to all present and future tables & views within that schema.

Schema permissions granted are cumulative with other permissions. If a user is granted read permissions on a schema and update permission on a table contained within that schema, the effective permissions on that table for that user will be both read and update.

Permissions granted on schemas are maintained separately from permissions granted on tables & views. If a user is granted admin access on a schema and read access on a table within that schema, revoking the user's schema admin access will not affect the user's table read access on the contained table.

In general, there are no negative permissions. For instance, if read access on a schema is granted, read access on a table within that schema cannot be revoked. Instead, the schema read permission would have to be revoked and then the access to the appropriate tables within the schema granted.

Schema permissions may be assigned via Workbench to users & roles.

The available permissions are:

  • table_insert
    • can insert records into tables within the specified schema(s) (upserting, via /insert/records using the update_on_existing_pk parameter, requires the table_update permission, as well)
  • table_update
    • can update records in tables within the specified schema(s) (upserting, via /insert/records using the update_on_existing_pk parameter, requires the table_insert permission, as well)
  • table_delete
    • can delete records from tables within the specified schema(s)
  • table_read
    • can read (select) records from tables & views within the specified schema(s)
  • table_admin
    • has all four schema permissions above
    • can create, alter, or drop any table or view under that schema

Table Permissions

Table permissions govern access to database objects and the data contained within them. These apply to tables and both native & SQL views.

Table permissions granted are cumulative. If a user is granted read permission on a table through one role and update permission on that same table through another role, the effective permissions on the table for that user will be both read and update.

In general, there are no negative permissions. For instance, if read access on a table is granted, read access on a subset of rows or columns within that table cannot be revoked. Instead, the table read permission would have to be revoked and then the access to the appropriate rows or columns within the table granted.

Both row-level security and column-level security are available to be applied to a table, either separately or together.

Table permissions may be assigned via Workbench to users & roles.

The available permissions are:

  • table_insert
    • can insert records (upserting, via /insert/records using the update_on_existing_pk parameter, requires the table_update permission, as well)
  • table_update
    • can update records (upserting, via /insert/records using the update_on_existing_pk parameter, requires the table_insert permission, as well)
  • table_delete
    • can delete records
  • table_read
  • table_admin
    • has all four table permissions above
    • can alter & drop the granted table

Note

The creator of a materialized view will automatically be given table_admin permission on it, but will not have the permission to grant other users access to it; granting permission is reserved for users with the system_admin or system_user_admin permission.

Row-Level Security

Read access can be granted for a subset of the rows in a given table by employing row-level security. An expression is used to filter the records that should be accessible.

Note

Row-level access must be revoked by revoking access to all rows for that table (or column). To effectively revoke a partial subset, revoke access to the column and then regrant the appropriate access.

Row-level security could be useful in restricting users' access to their own employee records, department managers' access to the data relevant to their departments, or analysts' access to the cases assigned to them.

Row-level permissions may be assigned on a table via Workbench.

See GRANT Row-Level Security Examples & REVOKE Row-Level Security Examples for examples and granting & revoking row-level read access in SQL, respectively.

Column-Level Security

Read access can be granted for a subset of the columns in a given table by employing column-level security. Column-level security functions can be applied to those columns to either obfuscate or mask the values the user sees.

Note

Column-level access is revoked by specifying the column name(s) to revoke, regardless of what security functions may have been applied to the column when granted.

Column-level security, in general, is useful for preventing users from accessing restricted columns within a table that they can access, or for preventing users from accessing restricted characters within a string column they can otherwise access.

Important

Primary keys and shard keys are only visible to (and usable by) a user if the user has unrestricted access to all columns comprising the key. Applying any column-level security functions to key columns will restrict this access. Without full access to these keys, operations that require them, such as table joins, may fail.

Obfuscating a column's values will result in a unique non-negative number being returned for each unique original column value; rows with the same column value will return the same obfuscated number for that value. This can be useful in performing analysis on patient data, where records need to be attributable to unique individuals, but the identities of those individuals need to be kept private.

Masking a column's values allows certain characters of a string to not be displayed--instead, replacing them with * (or other) characters. This can be useful in displaying the last four digits of a user's social security number for verification purposes without disclosing the entire SSN.

When a user is granted multiple levels of access to a given column, the values shown to a user will be determined based on the least restrictive access the user has been granted. Access restrictiveness is determined in the following order, from least restrictive to most restrictive:

  • Full access
  • Masked access
  • Obfuscated access
  • No access

Column-level permissions may be assigned on a table via Workbench.

See GRANT Column-Level Security Examples & REVOKE Column-Level Security Examples for examples and granting & revoking column-level read access in SQL, respectively.

Column-Level Security Functions

The following security functions can be used when employing column-level security on the following effective types with string base types:

  • char[N] strings
  • ipv4
  • decimal
  • ulong
  • date
  • time
  • datetime
FunctionDescription
HASH(column)Returns a non-negative integer representing an obfuscated version of column
MASK(column, start, length[, char])

Masks length characters of column, beginning at the position identified by start, with * characters (or the character specified in char):

Function CallResult
MASK('Characters', 5, 5)Char*****s
MASK('Characters', 5, 2, '#')Char##ters
OBFUSCATE(column)Alias for HASH

Credential Permissions

Credential permissions govern access to external system credentials. Any user can create and use a credential.

Credential permissions may be assigned via Workbench to users & roles.

The available permissions are:

  • credential_read
    • allows a user to see the given credential's configuration and use it
  • credential_admin
    • allows a user to modify or drop the given credential, as well as use it and display its configuration.

Note

The creator of a credential will automatically be given credential_admin permission on it, but will not have the permission to grant other users access to it; granting permission is reserved for users with the system_admin or system_user_admin permission.


Data Source Permissions

Data source permissions govern access to external data sources.

Data source permissions may be assigned via Workbench to users & roles.

The available permissions are:

  • connect
    • allows a user to connect to an external data set through the given data source, and view the configuration of the data source
  • datasource_admin
    • allows a user to modify or drop the given data source

Note

The creator of a data source will automatically be given datasource_admin permission on it, but will not have the permission to grant other users access to it; granting permission is reserved for users with the system_admin or system_user_admin permission.


Data Sink Permissions

Data sink permissions govern access to external data sinks.

The available permissions are:

  • connect
    • allows a user to connect to an external data consumer through the given data sink, and view the configuration of the data sink
  • datasink_admin
    • allows a user to modify or drop the given data sink

Note

The creator of a data sink will automatically be given datasink_admin permission on it, but will not have the permission to grant other users access to it; granting permission is reserved for users with the system_admin or system_user_admin permission.


Function Permissions

Function permissions govern access to User-Defined Functions (UDFs) and Python UDF function environments.

Permission can be granted on:

  • specific UDFs
  • all present and future UDFs

These two scopes of grants exist independently of each other and are managed separately, as well.

Important

Revoking a user's permission on all UDFs will not revoke any specific UDF permission that user has been granted. To revoke any permission on specific UDFs that a user has, each specific UDF permission needs to be revoked individually from the user.

Administrative access to all present and future UDFs also allows management access to function environments.

Permissions on UDFs & function environments can also be managed via SQL.

Function permissions may be assigned via Workbench to users & roles.

The available permissions are:

  • proc_execute
    • allows a user to execute the given UDF; or all UDFs, if granted without a UDF specified
  • proc_admin
    • allows a user to manage the given UDF; or all UDFs and function environments, if granted without a UDF specified

Graph Permissions

Graph permissions govern access to network graphs.

The available permissions are:

  • table_admin
    • allows a user to create a graph in the schema on which their table_admin is granted
  • graph_read
    • allows a user to query, match, solve, & show the given graph
  • graph_write
    • allows a user to modify the given graph
    • includes graph_read permission
  • graph_admin
    • allows a user to drop the given graph
    • includes graph_write permission

Note

The creator of a graph will automatically be given graph_admin permission on it, but will not have the permission to grant other users access to it; granting permission is reserved for users with the system_admin or system_user_admin permission.


KiFS Permissions

KiFS permissions govern access to directories and the files they contain. Only a user with system_admin permission can create a directory.

KiFS permissions may be assigned via Workbench to users & roles.

The available permissions are:

  • directory_read
    • allows a user to list, download, and use files within the given directory, in Kinetica features that make use of KiFS
  • directory_write
    • allows a user to upload and delete files within the given directory
    • includes directory_read permission

Procedure Permissions

Procedure permissions govern access to SQL Procedures.

For managing permission on SQL Procedures, see the SQL Procedure Security section.

Procedure permissions may be assigned via Workbench to users & roles.

The available permissions are:

  • sql_proc_execute

Table Monitor (SQL Stream) Permissions

Table monitor permissions govern access to table monitors (SQL Streams).

The available permission is:

  • monitor_admin
    • allows a user to drop the given table monitor

Note

The creator of a table monitor will automatically be given monitor_admin permission on it, but will not have the permission to grant other users access to it; granting permission is reserved for users with the system_admin or system_user_admin permission.