Skip to main content

Access control

Overview​

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.

Users are the identities that sign in and make requests, whether a person or a service account. A user must be added to a metalake before it can do anything there. Users arrive from your identity provider, through directory provisioning, or as local accounts. 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. Membership comes from your identity provider or directory, or is kept locally for local accounts. 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 role granted to a user or a group gives them exactly those privileges, and 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.

Quick start​

Giving someone read access to one schema takes three steps. The commands reuse ADMIN_PASSWORD, METALAKE, and the port forward to localhost:8090 from Install with Helm, and run as the admin account, which owns the metalake it created.

Set the user, catalog and schema
NEW_USER={user_name}
CATALOG={catalog_name}
SCHEMA={schema_name}
API="http://localhost:8090/api/metalakes/$METALAKE"

  1. Add the user to the metalake.

    Add the user to the metalake
    curl -s -u "admin:$ADMIN_PASSWORD" -X POST -H "Content-Type: application/json" \
      -d "{\"name\": \"$NEW_USER\"}" \
      "$API/users" | jq '{code, name: .user.name}'

  2. Create a role with the privileges. Reading a schema needs USE_CATALOG and USE_SCHEMA to reach it and SELECT_TABLE to read its tables.

    Create the schema_reader role
    curl -s -u "admin:$ADMIN_PASSWORD" -X POST -H "Content-Type: application/json" -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\"}
            ]
          }
        ]
      }" \
      "$API/roles" | jq '{code, name: .role.name}'

  3. Grant the role to the user. To grant it to everyone in a group instead, replace users/$NEW_USER in the path with groups/{group_name}.

    Grant the role to the user
    curl -s -u "admin:$ADMIN_PASSWORD" -X PUT -H "Content-Type: application/json" \
      -d '{"roleNames": ["schema_reader"]}' \
      "$API/permissions/users/$NEW_USER/grant" | jq '{code}'

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. All three steps can also be done in the UI.

Where to go next​

Roles lists every privilege, the objects it binds to, and what it allows.

Users covers service administrators, adding users to a metalake, and local accounts.

Groups covers where group membership comes from and how a role granted to a group reaches its members.

Privileges covers the authorization model in full: ownership, how a request is evaluated, allow and deny, server configuration, and reviewing grants.

Last updated on