Security Concepts

Overview

Kinetica's security model is similar to most SQL databases. Permissions are defined on individual tables, collections of tables, and the Kinetica instance itself. Users can be added to the database and assigned these permissions. Roles can be created and assigned permissions, with all users added to those roles getting the related permissions. Roles can also be added to a role, with the lower level role inheriting the permissions of the higher level role. The permissions a user has is the union of all permissions granted individually to the user and through roles. In all these ways, security in Kinetica is similar to what you have seen in most databases.

Where Kinetica security differs, is in the creation of users and some specifics about the permissions.

User Types

Internal

• username and password(encrypted) are stored within Kinetica,
• authentication is done by Kinetica
• username format: [a-z_][a-z_0-9]\*
• the minimum password length is set in gpudb.conf in the min_password_length setting.

External

• username and password or user certificate is stored in an external LDAP
• uses proxy server for LDAP lookup & pass-through to Kinetica
• username duplicated in Kinetica, but with an @ prepended.
• username format: @LDAPFormat

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

Roles

• name format: [a-z_][a-z_0-9]\*
• name must be unique system-wide
• roles contain members, which can be any user or other role, except when a role would recursively contain itself.
• all role members are granted the permissions associated with the role
• an individual user's permissions are the union of all directly-granted permissions and permissions granted via role

Permissions

Kinetica has two separate sets of permissions: system-level and table-level.

system-level

• system_admin - read/write access to tables and data; add users and roles; grant/revoke permissions to users;
• system_write - read/write access to tables and data; no user or process administration
• system_read - read-only access to tables and data

table-level (applies to tables, views, and collections)

• table_admin - read/write access, create & delete (only apply to collections)
• table_insert - insert records
• table_update - update records
• table_delete - delete records
• table_read - read(select) records

Notes:

The creator of a table or collection will automatically be given table_admin permission on that table. Other users can only be granted permissions by a user with the system_admin permission. Granting a user permission to a collection, gives the user that permission to all tables in the collection. If no collection is specified, the root level collection is assumed.

Default Users

• admin

  • has full permissions to do anything in Kinetica
  • system_admin permission by default; unable to modify
  • password is admin by default
  • password can be changed; change will be stored securely in Kinetica

• anonymous

  • blank password
  • no permissions by default

Default Roles

• public

  • all users are members of public by default
  • the public role will grant permissions to users who have not authenticated

• authenticated

  • all users except anonymous are members of authenticated by default.

User Endpoints

• alter_user

  • sets user password
  • can be called by any user to change their own password, but requires system_admin permission to change another person's password

Role Endpoints

• create_role
• delete_role
• grant_role
• revoke_role

Role endpoints require system_admin permission

Permission Endpoints

• grant_permission_system
• grant_permission_table
• revoke_permission_system
• revoke_permission_table

Reminder: Users can't grant access to tables they create; need a 3rd party user with system_admin permission