Skip to main content
Version: v3.0.0

Permissions

Permissions determine the level of access that a user has to various components of the Feature Store. For example, depending on the level of permission granted, a user may be authorized to edit feature sets, while another user with limited view-only permission can only observe the feature set.

Levels of permission​

Feature Store has six levels of permission:

These roles apply both at the workspace level (governing the workspace and, as a prerequisite, access to the feature sets it contains) and at the feature set level (governing a single feature set). See Workspaces API for how workspaces replace the legacy Projects concept.

Additionally, Feature Store also has the concept of an admin account. An admin is any user with the admin role specified in their identity provider. Admin users can perform additional management tasks.

note

The name of the claim storing the roles and name of admin role is configurable during Feature Store deployment.

Owner​

You become the owner by creating a workspace. As the owner, you can delete the workspace, manage its access level, and assign roles to other users (currently only through the UI — see the note below). As a workspace owner, you can manage every feature set within the workspace.

note

As the owner, you have all the other permissions.

  • Editor
  • Sensitive consumer
  • Consumer
  • Viewer
  • Metadata viewer

Editor​

If you have the editor role on a workspace, you are authorized to update the workspace's metadata and register new feature sets within it. As a workspace editor, you can also manage the feature sets within the workspace.

note

As an editor, you also have the following permissions,

  • Sensitive consumer
  • Consumer
  • Viewer
  • Metadata viewer

Sensitive consumer​

If you have the sensitive consumer role on a workspace, you are authorized to list and obtain feature sets from the workspace, with sensitive consumer access to those feature sets.

note

As a sensitive consumer, you also have the following permissions:

  • Consumer
  • Viewer
  • Metadata viewer

Consumer​

If you have the consumer role on a workspace, you are authorized to list and obtain feature sets from the workspace. In other words, as a consumer of a workspace, you can retrieve data from its feature sets.

note

As a consumer, you also have the following permissions:

  • Viewer
  • Metadata viewer

Viewer​

If you have the viewer role on a workspace, you are authorized to see which feature sets are within the workspace. This behaviour is also influenced by the Workspace access levels.

note

As a viewer, you also have the following permission:

  • Metadata viewer

Metadata viewer​

If you have the metadata viewer role on a workspace, you are authorized to see which feature sets are within the workspace. This is metadata-only access — you cannot retrieve or preview data. Metadata viewer is the default level of access for public workspaces, granting the minimum access needed to discover and inspect feature sets without accessing underlying data.

Workspace access levels​

Access levels on a workspace control what users can additionally do and are reflected internally by permissions. See Workspace access levels for more information.

Feature set permissions API​

Permission grant, revoke, request, and listing operations are performed on a feature set. First obtain the feature set through its workspace:

workspace = client.workspaces.list(name="default")[0]
fs = workspace.feature_sets.get_by_name("training_fs")

Working with users​

The add_* and remove_* methods operate on users, not raw email strings. A user is either a User object (returned by the users API and by the list_* methods below) or a "users/<UUID>" resource name.

When you only know someone's email address, resolve it first with client.users.find_by_email(...). Email is not guaranteed to be unique in the identity provider, so this returns a list of every matching user. Make sure you pick the right one before granting:

matches = client.users.find_by_email("bob@h2o.ai")
if len(matches) != 1:
    raise ValueError(f"ambiguous email: {matches}")
bob = matches[0]

alice = client.users.find_by_email("alice@h2o.ai")[0]
note

Before you can grant a feature set role to a user, that user must already hold a workspace-level role on the parent workspace. Otherwise the server rejects the grant.

Granting a workspace-level role to another user is not currently exposed through the Python client — the workspace creator is granted the owner role automatically, but there is no add_* equivalent for workspaces. This is achieved through the workspace UI instead.

Add permissions to a feature set​

Each add_* method accepts a single user or an iterable of users:

fs.add_owners(bob)
fs.add_editors(bob)
fs.add_consumers([bob, alice])
fs.add_sensitive_consumers(alice)
fs.add_viewers(alice)
fs.add_metadata_viewers(alice)

Remove permissions from a feature set​

Each remove_* method accepts the same inputs as its add_* counterpart:

fs.remove_owners(bob)
fs.remove_editors(bob)
fs.remove_consumers([bob, alice])
fs.remove_sensitive_consumers(alice)
fs.remove_viewers(alice)
fs.remove_metadata_viewers(alice)

List feature set permissions​

Each list_* method returns the users that currently hold the corresponding role. The returned items are User objects, additionally carrying the access_type and resource_type the role was granted through, so they can be passed straight back into the matching remove_* method:

fs.list_owners()
fs.list_editors()
fs.list_consumers()
fs.list_sensitive_consumers()
fs.list_viewers()
fs.list_metadata_viewers()

# Example: revoke Bob's owner role, matching on email
for user in fs.list_owners():
    if user.email == "bob@h2o.ai":
        fs.remove_owners(user)

Request access to a feature set​

When cooperating with several users, you may not have the specific permission you need on a feature set. You can request one from the feature set owners.

To begin, check your current access:

from h2o_featurestore.core.access_type import AccessType

my_access = fs.current_permission
# returns an AccessType, or None if you have no active permission

If your level of permission is not sufficient, request access:

request_id = fs.request_access(AccessType.CONSUMER, "Preparing the best model")

You can track your pending permission requests through the client API:

my_requests = client.acl.requests.feature_sets.list()

If you change your mind before a request is processed, you can cancel it by withdrawing it:

requests = list(client.acl.requests.feature_sets.list())
request = requests[0]  # pick the request you want to withdraw
request.withdraw()

When a request no longer appears in the pending list, it has been processed. To see the outcome, list your active permissions. The filters argument is an optional list of permission-state strings — "GRANTED", "REJECTED", or "PENDING". It defaults to ["GRANTED"] (the most common case). If you do not find your original request granted, it was most likely either rejected, or granted and then revoked.

# Granted permissions (default)
my_permissions = client.acl.permissions.feature_sets.list()

# Verify a rejected request by specifying the corresponding filter
rejected = client.acl.permissions.feature_sets.list(["REJECTED"])

Manage requests and permissions​

As a feature set owner, other users can request access to your feature set.

To list the requests pending for you to handle, and either approve or reject them, call:

manageable = list(client.acl.requests.feature_sets.list_manageable())
request = manageable[0]  # pick the request you want to handle
request.approve("it will be fun")
# or: request.reject("it's not ready yet")

To revoke access you have previously granted, list the manageable permissions (not requests) and call revoke() on the one you want to remove:

manageable = list(client.acl.permissions.feature_sets.list_manageable())
permission = manageable[0]  # pick the permission you want to revoke
permission.revoke("user left the workspace")

Inspecting permissions and requests​

The objects returned by the list() and list_manageable() methods expose their state through properties (not method calls). The following is not exhaustive:

for request in client.acl.requests.feature_sets.list_manageable():
    request.user            # the user associated with the request
    request.access_type     # requested AccessType
    request.status          # permission state
    request.reason          # reason provided with the request
    request.resource_id     # id of the target feature set
    request.resource_type   # resource type
    request.created_on
    request.last_update_on

    fs = request.get_feature_set()  # load the target feature set
Feedback