Permissions

Anyscale allows for granular access controls at the following levels:

• Organization, a group of Anyscale users
• Cloud, a deployment of Anyscale that specifies where clusters launch
• Project, a group of workspace, job, or service clusters

Examples of cloud resources include storage, access controls, and secrets management.

Typically system administrators create and manage user access to the organization and clouds. Organization and cloud permissions follow a strict hierarchy with implicit permissions, inherited through the hierarchy.

Users create clusters and manage access to them using projects. A user can restrict access to projects and its clusters with an explicit access list. Generally, each hierarchy has two types of roles that a user can have:

• Owner, who manages user access with role assignments
• Collaborator, who has edit access to some but not always all clusters at that level of hierarchy

Projects don’t have a collaborator role, but the project write role is similar.

Organization roles

To create and use Anyscale clusters, a user must be in an Anyscale organization. Any user can create an organization. The creator of the organization becomes the first organization owner who can then add other users, assigning them one of two roles:

• Organization collaborator
• Organization owner

Organization collaborator

The collaborator role:

• Is a necessary requirement to access any cloud
• Can be promoted to the organization owner role by another organization owner
• Has access all container images in the organization

When an organization owner adds a user to the organization, the default role is an organization collaborator.

Organization owner

Any organization must have one or multiple organization owners. Permissions for organization owners allow them to perform the following tasks:

• Manage users (add, remove, assign, or change a user’s role)
• Create clouds
• Troubleshoot clusters with admin access
• Manage billing and costs

An organization owner’s permissions are hierarchical. They have full administrative rights for cloud owner and project owner roles, so they can troubleshoot problems. They don't need to explicitly appear in access lists. They have implicit permissions.

User removal​s

Removing a user from an organization prevents the user from logging into or using tokens to access Anyscale resources. Anyscale doesn't support re-adding a user who has been removed from an organization.

Removal doesn't delete the clusters they created. These private clusters remain accessible to the organization owners through implicit admin permissions.

Owner to collaborator demotions

If an organization owner changes an organization owner to be an organization collaborator, Anyscale removes the implicit permissions they had to all clouds, even if they created them. The organization owner should explicitly add the removed organization owner as a cloud collaborator on the cloud they intend to work on, to retain access to those clusters. This action is required because Anyscale layers cloud owner permissions for a cloud owner on top of their permissions as a cloud collaborator.

Cloud roles

Use clouds to separate permissions and access controls to gate access to different deployments of Anyscale. With clouds you can also set regions and availability zones, or other configurations for where and how you situate and make those resources available.

Organization owners create clouds. The cloud creator becomes the sole cloud owner who can add users as cloud collaborators. A user must have a cloud role to create projects and clusters. Three roles exist for the cloud level:

• Cloud collaborator
• Cloud owner
• Cloud read only

Cloud collaborator

Cloud owners can assign the cloud collaborator role to a user in the organization.

Cloud collaborators have access to the cloud to:

• Create projects and resources
• Access to public projects
• Access private projects they own or have explicit permission for
• Can view the list of projects they have access to
• View cloud details
• Access and create compute configs

Cloud owner

To be a cloud owner, a user must be an organization owner. The cloud owner has explicit permissions to:

• Manage users in the cloud (add and remove collaborators only)
• Perform all cloud collaborator tasks

Cloud read only

A read only user for a cloud must be an organization collaborator. The read-only user has permission to view:

• Projects and resources
• Resources in public projects or private projects they have permission for, including the default project
• The health and status of clusters including metrics

Setting a user to be cloud-read-only allows the user to be a read-only user for all projects within that cloud.

User removal

Removing a user from a cloud revokes their access to all resources within that cloud. Removed users may appear as Removed user in resource lists. Organization owners retain access through implicit admin permissions. Cloud owners can’t remove themselves from the cloud.

Auto add users

If a cloud owner enables the auto add user feature, they grant all individual users in the organization cloud collaborator permissions, and all users appear in the cloud collaborator table view. Cloud owners can no longer manually modify cloud permissions while this feature is enabled because all users need to have access. When enabled, Anyscale automatically assigns cloud collaborator permissions within 30 seconds of user additions.

Disabling the feature doesn’t change existing permissions but stops automatic additions.

Project roles

Cloud collaborators can create projects to manage access to clusters. Workspace, job, and service clusters inherit permissions from their project. While all cloud users have access to public projects, finer grain access for private projects exists at three levels:

• Project read only
• Project write
• Project owner

Project read only

Users with project read-only permissions can access the project’s existing clusters but they can’t create or modify them. This role can’t modify the state of the project itself by creating or modifying the state of child clusters.

Read-only users:

• Can view which other users have access to the project
• Can’t modify the user roles

Read-only users have limitations in what actions they can perform on clusters within the project.

• For Anyscale Workspaces, Jobs, and Services, read-only users:

  • Can't run commands in a running job or service through VS Code, Jupyter, or the web terminal
  • Can't duplicate a workspace
  • Can't access the Ray Dashboard
  • Can't modify the state of workspaces, jobs, or services
  • Can download logs and view metrics related to the cluster

info

You should set users who require a read-only permission within a cloud, to a read-only role at the cloud level.

A cloud collaborator with a project read-only role doesn't guarantee that the user can't run code on clusters running in a different project, because all clusters within a cloud share the same data plane infrastructure. However, the user won't be able to change the state of a cluster within the project if they're read only for that project.

Project write

The project write role is most similar to the collaborator role in organizations and clouds.

Project write users:

• Can create and access any cluster within the project
• Can view other users who can access the project
• Can’t modify a user's access to the project or their role

Note: The project write user can see who has access to the project. This role is unlike the organization and cloud collaborator roles who can't see which users have access to the organization or cloud.

Project owner

Project owners can manage other users on the project and have full-write access to the project and any resource in the project. Project creators are owners by default.

Project owners:

• Can make any cloud owner or cloud collaborator an owner on the project
• Can manage other users' permissions on the project
• Can’t modify their own role on the project

User removals

When a project owner removes a user from a project, the removed user loses individual access to all clusters in the project. However, implicit permissions, such as when the project is public or the user is an organization owner, remain valid. Project owners can remove users with project-level permissions, such as project owner, project write, and project read only. However, a project owner can't remove themselves from a project. Another project owner or organization owner with implicit admin permissions must remove them.

Because no granular access controls exist for resources below projects, if a project owner re-adds a previously removed user, that user regains access to all child resources with their new permission level.

Container images and compute configs

Container images are accessible by all users within the organization. Compute configs referencing a cloud can be used by all users with access to that cloud.