Skip to main content

Roles and Permissions

info

Roles and Permissions in the Earthmover platform are under active development. Expect this section to evolve rapidly.

The Earthmover platform uses a role-based access control (RBAC) system to determine which users have access to which resources and actions. This page describes the general concepts used in the platform. For a hands-on guide to setting roles and permissions, see managing users and access controls

info

Fine-grained permissions are constrained by the access-control functionality of the underlying storage provider. To support full fine-grained access control with Arraylake, buckets must be in AWS or Google Cloud and should be configured with Role-based Access Delegation. Buckets using HMAC keys are not able to support fine-grained access control at this time.

Principals​

Identities in the Earthmover Platform are called principals. Principals can be one of two types:

  • Users - Actual human users. Each user is associated with an email address.
  • API Keys - API keys are intended for non-human "service accounts", suitable for use in automated data processing jobs, dashboards, or other machine-to-machine connections.

Organizations​

All principals and roles are scoped to an organization (org). There are no cross-organization entities or roles. If a user needs to access data in multiple organizations, they must be explicitly added to each.

Organization-Scoped User Roles​

Users can have one or more roles within an organization.

  • Member - An organization member can log in to the platform but can't actually do anything. This role is currently a placeholder.
  • Repo Reader - A repo reader has read only access to repos. They can view and list repos from the web and CLI and access repo data via Python. Cannot create or delete repos, or configure repo settings.
  • Repo Writer - A repo writer can perform all Repo Reader actions, and can also write to repos, create repos, delete repos, and modify repo configuration.
  • Admin - An organization admin can perform all Repo Write actions, and can also manage the organization (add and remove users and API keys, configure buckets, start and stop flux services, etc.)

Organization-Scoped API Key Permissions​

API keys can be given explicit permissions to perform actions. Within an organization, API keys can be given the following permissions:

  • Read Repos With Flux - Permission to read data from repos within the organization via Flux services. This does not grant access to the repo's data in the web or client.
  • Read Repos - Permission to read data from repos within the organization. Currently, this permission also grants all Read Repos With Flux permissions. This role also allows access to the repo via Flux services.
  • Write Repos - Permission to write data to repos within the organization. Currently, this permission also grants all Read Repos permissions.

API Keys can be granted these permissions via the API Key Management page.

Repos​

All repos within an organization inherit the roles and permissions from the organization. However, the user can supplement the organization-level permissions with repo-level permissions. When a user has both organization-level and repo-level roles or permissions, the most permissive of the two is used.

For example, if a user has the Repo Reader role at the organization level, they can read data from all repos in the organization. If they also have the Writer role for a given repo, they can read and write data to the repo only.

If users have no organization-level permissions, they will only have access to the repos they are explicitly given roles or permissions for. They will only see the repos they have explicit access to in the web and CLI.

Repo-Scoped User Roles​

Users can be given explicit permissions to perform actions within a specific repo. The available roles are:

  • Member - No explicit capabilities to do anything. This role is currently a placeholder.
  • Reader - A reader has read only access to the repo. They can view and list the repo from the web and CLI and access repo data via the Arraylake client library. They cannot create or delete repos, or configure repo settings. This role also allows access to the repo via Flux services.
  • Writer - A writer has read and write access to the repo. They can view and list the repo from the web and CLI, access repo data via the Arraylake client library, and write data to the repo. They cannot delete repos or configure destructive repo settings.
  • Admin - An admin has read, write, and admin access to the repo. They can view and list the repo from the web and CLI, access repo data via the Arraylake client library, and write data to the repo. They can also delete repos and configure all repo settings.

Only users that have been added to an organization can be given repo-level roles.

Repo-Scoped API Key Permissions​

API Keys can be given explicit permissions to perform actions. Within a repo, API Keys can be given the following permissions:

  • Read With Flux - Permission to read data from the repo via Flux services. This does not grant access to the repo's data in the web or client library.
  • Read - Permission to read data from the repo. Currently, this permission also grants all Read With Flux permissions.
  • Write - Permission to write data to the repo. Currently, this permission also grants all Read permissions.

Only API keys that have been added to an organization can be given repo-level permissions.