Access control

Access in Datastrato Enterprise is granted to people through three things: users, groups, and roles. A role holds privileges on objects, and a role is granted to users and to groups. Nobody receives a privilege directly, so every question of who can do what comes back to which roles they hold and which objects they own.

When authorization is enabled, the server checks every request against the caller's roles and ownership before the operation runs. A request it denies ends there.

Users are the identities that sign in and make requests, whether a person or a service account. A user reaches nothing in a metalake until it belongs to the metalake and holds a role there. See Users.

Groups collect users so that access can be granted once for all of them. A role granted to a group applies to every member. See Groups.

Roles are named sets of privileges, each privilege bound to an object such as a catalog or a schema and marked ALLOW or DENY. A user holds the combined roles granted to them directly and through their groups. See Roles.

Alongside roles, whoever creates an object owns it, and ownership carries administrative rights over the object and everything beneath it without any role. How privileges and ownership combine to decide a request, including why a DENY always wins, is covered in Privileges.

In the UI, all of this is under Authorize, for the selected metalake. Overview counts the metalake's users (active and suspended), groups, and roles, and shows access by catalog. Roles, Users, and Groups each list what the metalake holds.

Quick start

Giving someone read access to one schema takes a role with three privileges: USE_CATALOG and USE_SCHEMA to reach the schema, and SELECT_TABLE to read its tables. The steps run as the metalake's owner.

UI

1. Create the role with its member. Select the metalake, open Authorize → Roles, and click + Role. Enter schema_reader as the Role name, choose Users under Member type, select the user, and click Add role. The user is added to the metalake.

2. Grant reach on the catalog. Click schema_reader, select the Privileges tab, and click + Privilege. Choose Catalog as the Object type and the catalog as the Object, leave the Effect at Allow, select Use Catalog, and click Grant privilege.

3. Grant read on the schema. Click + Privilege again, choose Schema and the schema, select Use Schema and Select Table, and click Grant privilege.

REST

1. Add the user to the metalake.

   Add the user to the metalake

   curl -sS -X POST "https://{gravitino_host}/api/metalakes/{metalake}/users" \
     -H "Accept: application/vnd.gravitino.v1+json" \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer $TOKEN" \
     -d '{"name": "{user}"}'

2. Create the role with its privileges.

   Create the schema_reader role

   curl -sS -X POST "https://{gravitino_host}/api/metalakes/{metalake}/roles" \
     -H "Accept: application/vnd.gravitino.v1+json" \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer $TOKEN" \
     -d '{
     "name": "schema_reader",
     "properties": {},
     "securableObjects": [
       {
         "fullName": "{catalog}",
         "type": "CATALOG",
         "privileges": [{"name": "USE_CATALOG", "condition": "ALLOW"}]
       },
       {
         "fullName": "{catalog}.{schema}",
         "type": "SCHEMA",
         "privileges": [
           {"name": "USE_SCHEMA", "condition": "ALLOW"},
           {"name": "SELECT_TABLE", "condition": "ALLOW"}
         ]
       }
     ]
   }'

3. Grant the role to the user. To grant it to everyone in a group instead, add the group with /groups in step 1 and replace users/{user} in the path with groups/{group}.

   Grant the role to the user

   curl -sS -X PUT "https://{gravitino_host}/api/metalakes/{metalake}/permissions/users/{user}/grant" \
     -H "Accept: application/vnd.gravitino.v1+json" \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer $TOKEN" \
     -d '{"roleNames": ["schema_reader"]}'

Each response shows "code": 0.

The user can now read every table in the schema, including tables created there later, and nothing else in the metalake.

How people get into a metalake

Users and groups enter the server-wide Directory in three ways: created locally under Configure → Directory, provisioned over SCIM by the identity provider, or recorded just in time when a user who is not provisioned signs in through the identity provider. Being in the Directory lets a user sign in and grants nothing inside a metalake.

In the UI, assigning a role in a metalake to a Directory user or group adds that user or group to the metalake, with no separate step. Over the REST API, the user or group is added to the metalake first and granted roles after. See Users and Groups for the details, Directory for local accounts, and SCIM provisioning for provisioned ones.

Related

• Roles, for creating roles, granting privileges, and assigning members
• Users, for how users get into a metalake, service administrators, and suspension
• Groups, for where group membership comes from and how a role reaches its members
• Directory, for local users and groups and the server-wide Directory
• SCIM provisioning, for users and groups pushed by your identity provider
• Privileges, for the full privilege model: ownership, evaluation, allow and deny, server configuration, and reviewing grants