Version:

Table Of Contents

  1. Docs
  2. Installation & Configuration
  3. Security
  4. Security Concepts

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, collection level, or globally, and can be assigned either directly or grouped into roles for assignment.

Note

Kinetica users, permissions, and roles can be managed through GAdmin's Security interface or through one of the APIs. See Security Usage for details.

Users

Kinetica supports authentication and authorization of both internal users, whose credentials are maintained within the database, and external users, whose credentials are maintained by another directory service (LDAP, AD, etc.).

Roles are maintained within the database for both types of users, though group memberships held by external users can be mapped to roles to automatically authorize those users to the appropriate level of access. See HTTPD + External Authentication for instructions on how to configure this mapping of external groups to roles.

Internal Users

Internal users have a username and password (encrypted), which are both stored within Kinetica.

An internal username must meet the following criteria:

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

Password must meet the following criteria:

  • up to 1024 characters long, by default; governed by the min_password_length parameter configured in the gpudb.conf file

External Users

External users have a username and password or user certificate stored in an external directory service and a corresponding user name stored within Kinetica. A proxy server is used to authenticate users to the external directory service and pass the authenticated request on to the database.

An external username must meet the following criteria:

  • identical to the external username, but with an @ prepended: @external_username
  • unique among external usernames

Note

Once authenticated, user authorization does not distinguish between internal and external users

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 is admin by default but must be updated after the first login
    • 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

User Endpoints

Calling user endpoints generally requires system_admin or system_user_admin permission.

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.

One or more roles can automatically be granted to any external user, based on that user's group memberships within the external directory service used. See HTTPD + External Authentication for instructions on how to map external group memberships to roles.

A role name must meet the following criteria:

  • alphanumeric, including underscore; not starting with a number: [a-z_][a-z_0-9]*
  • unique among internal 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

Role Endpoints

Calling role endpoints generally requires system_admin or system_user_admin permission.

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 two categories of permissions within Kinetica:

Table-Level

Table-level permissions govern access to database objects and the data contained within them. These apply to tables, views, and collections.

Permissions granted to tables are cumulative. If a user is granted read permission to 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 to a collection is granted, read access to a table within that collection cannot be revoked. Instead, the collection read permission would have to be revoked and then the access to the appropriate tables within the collection granted. Similarly, a user with read access on a table cannot have read access to a subset of the rows or columns revoked.

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

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-level permissions above
    • can alter & drop the granted table
    • when granted on a collection, can create tables under that collection, as well as employ table-level permissions on any table in the collection
    • when granted at the root level, can employ all other table-level permissions on any table in the system

Note

The creator of a table or collection will automatically be given table_admin permission on that table, but will not have the permission to grant other users access to it; granting permission is reserved for users with the system_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.

See Managing Table Permissions at the Row Level for examples and granting & revoking row-level read access.

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.

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

See Managing Table Permissions at the Column Level for examples and granting & revoking column-level read access.

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
Function Description
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 Call Result
MASK('Characters', 5, 5) Char*****s
MASK('Characters', 5, 2, '#') Char##ters
OBFUSCATE(column) Alias for HASH

System-Level

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

The available permissions are:

  • system_admin
    • has table_admin on all tables
    • can manage users & roles
    • can grant/revoke permissions & roles
  • system_write
    • 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)

Procedure-Level

Procedure-level permissions govern access to both user-defined functions and SQL procedures.

Execute permission can be granted to:

  • specific UDFs
  • all present and future UDFs

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

Important

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

For managing permission on SQL procedures, see the SQL procedure security section.

The available permissions are:

Permission Endpoints

Calling permission endpoints generally requires system_admin or system_user_admin permission.

© Copyright 2020, Kinetica. Created using Sphinx.