Topics
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.
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 have a username and password (encrypted), which are both stored within Kinetica.
An internal username must meet the following criteria:
[a-z_][a-z_0-9]*
Password must meet the following criteria:
min_password_length
parameter configured in the gpudb.conf
fileExternal 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:
@
prepended:
@external_username
Note
Once authenticated, user authorization does not distinguish between internal and external users
Kinetica comes with two default users:
admin
system_admin
permission by default; unable to modifyadmin
by default but
must be updated after the first loginanonymous
Calling user endpoints generally requires system_admin
permission.
system_admin
permission to change their own passwords)system_admin
permission to view their type and
roles &
permissions granted)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:
[a-z_][a-z_0-9]*
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.
There are two default roles within Kinetica:
authenticated
anonymous
are members of authenticated
by
default.public
public
by defaultpublic
role will grant permissions to users who have not
authenticatedCalling role endpoints generally requires system_admin
permission.
system_admin
permission to view the
roles granted to them)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 & system-level.
Table-level permissions govern access to database objects and the data contained within them. These apply to tables, views, and collections.
The available permissions are:
table_insert
update_on_existing_pk
parameter, requires the
table_update
permission, as well)table_update
update_on_existing_pk
parameter, requires the
table_insert
permission, as well)table_delete
table_read
table_admin
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.
System-level permissions govern access to both database objects and management services.
The available permissions are:
system_admin
table_admin
on all tablessystem_write
table_admin
on all tables and datasystem_read
table_read
on all tablesCalling permission endpoints generally requires system_admin
permission.
system_admin
permission to view the
permissions granted to them)