Version:

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 another 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.

Note

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

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 configuration parameter
  • 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: @username

Note

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

Roles

Important

A role cannot recursively contain itself.

  • 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
  • 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

  • System-level

    • system_admin -- read/write access to tables and data, add users and roles, and grant/revoke permissions to users
    • system_write -- read/write access to tables and data, but 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 and can also create and delete
    • table_insert -- can insert records
    • table_update -- can update records
    • table_delete -- can delete records
    • table_read -- can read (select) records

    Note

    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

    • 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

    • 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
    • Allows for updating a given user's password
    • Can be called by any user to change their own password, but requires system_admin permission to change another user's password

Role Endpoints

Important

Calling role endpoints require system_admin permission.

Permission Endpoints

Note

Users can't grant access to tables they create, so a user with system_admin permission will need to do so