Roles and permissions

View Markdown

Roles and permissions

Anyscale provides role-based access control at the organization, cloud, and project levels. This page defines each role and its permissions.

For an overview of the Anyscale organization hierarchy, see Anyscale organization levels.

note

Service accounts are non-user identities for production integrations. Service accounts are always organization collaborators. You manage cloud and project permissions for service accounts the same way you manage user permissions.

Service accounts can't access the Anyscale console. See Anyscale service accounts.

Organization roles

Users in an Anyscale organization are either owners or collaborators. If you create an Anyscale organization, you are an 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 to 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:

• Add and remove users from the organization. See Manage users.
• Manage organization roles.
• Create clouds.
• 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 removals

Removing a user from an organization prevents the user from logging into or using tokens to access Anyscale resources. If you invite a previously deleted user back to an organization, the new user has a different user ID, meaning that roles and permissions don't restore for the user.

Anyscale doesn't delete clusters, workloads, or other assets created by a user removed from the organization.

Owner to collaborator demotions

Demoting an organization owner to organization collaborator removes all implicit permissions for Anyscale clouds in the organization.

You must explicitly grant the cloud collaborator role to a user to allow them to interact with resources in an Anyscale cloud.

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 can perform the following actions in a cloud:

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

Auto add users

Cloud owners can enable auto add to grant all organization users cloud collaborator permissions automatically. When enabled, Anyscale assigns cloud collaborator permissions within 30 seconds of user additions to the organization. See Auto add users to a cloud.

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

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.

note

The organization owner that creates a cloud is the cloud owner, but all organization owners have implicit cloud owner permissions on all clouds in an organization.

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.

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.

note

If you need to enforce read-only access across a cloud, assign the cloud read-only role instead of project-level read-only roles.

A cloud collaborator with a project read-only role can still run code on clusters in other projects they have access to, because all clusters within a cloud share the same data plane infrastructure.

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.