Access Controls
This version of the Anyscale docs is deprecated. Go to the latest version for up to date information.
This feature is enabled by default for newly created Anyscale Organizations. Organizations created before August 2023 will be automatically migrated by the end of 2023. Please reach out to your Anyscale account team for more information.
Overview
Anyscale allows specifying application level granular access controls for organizations, clouds, and projects.
Separate access controls cannot currently be provided on cluster environments, compute configs, or resources within the project. Instead
- All cluster environments can be used by all users in the organization
- Compute configs referencing a cloud can be used by all users with access to the cloud
- Clusters, jobs, services, and workspaces inherit permissions from the project based on Project Permissions rules
A strict resource tree hierarchy exists between organization, clouds, projects, and resources within projects (Eg: clusters, jobs, services, workspaces), where permissions can only be granted to a particular resource if permissions already exist on the parent resource.
- As a result, not granting a user access to a particular resource prevents that user from accessing any child resource.
- Generally, inheritance is not used by Anyscale permissions. Eg: Granting a user access to a cloud does not give them access to all resources in the cloud, but will give access to public resources in the cloud.
- There are some exceptions to this with admin permissions and project permissions.
Implicit vs Explicit Permissions
A user may have both explicit and implicit permissions in Anyscale. Both types of permissions grant access with the roles described in Organization Permissions, Cloud Permissions, and Project Permissions. Explicit permissions are granted at the individual user level, and implicit permissions are given to a user because of a particular resource they have access to.
Most permissions discussed here refer to explicit permissions, and the only examples of implicit permissions are organization admin permissions, and public projects.
If a user has multiple permissions, they will be able act as the strongest granted role. More examples in sections about organization admin permissions and public projects.
Organization Permissions
Two types of permissions can be granted at the organization level:
- Owner: There can be one or more organization owners for an organization. These users have full admin rights for the organization.
- In addition to all the collaborator actions, the organization owners can perform management actions on the organizations. These include:
- Inviting users to the organization
- Converting an existing collaborator to an owner
- Accessing the billing and costs dashboard
- Only organization owners can create clouds, and after doing so they get explicit permissions as a cloud owner.
- Organization owners also have implicit admin permissions on all Anyscale resources, which allows them to access even resources they don't have explicit permissions to.
- In addition to all the collaborator actions, the organization owners can perform management actions on the organizations. These include:
See User Management for instructions on how to perform organization owner actions.
- Collaborator: Collaborator is the default role assigned to a user when they are invited to the organization.
- Collaborators don't have access to the "My Organization" page, and cannot change their or other users' status in the organization.
- By default, collaborators only have access to cluster environments, which are public to all users in the organization.
- A collaborator must be added to a cloud to be able to take additional actions on other Anyscale resources in the cloud.
Because organization owners have admin permissions in addition to their individual user permissions, we recommend organization owners adding themselves to clouds and private projects they intend to develop on, so they have the same development experience as other collaborators (including if they are even demoted from admin).
Admin Permissions
Admin permissions are a type of implicit permission granted to organization owners. Admin permissions give the user the strongest "Owner" access to all resources in Anyscale, which allows organization owners to easily troubleshoot any issues.
You may notice organization owners don't show up in the pages which list users with access to a cloud or project (if they were not assigned access to these resources as individuals), and this is a result of the admin permissions being implicit. If an organization owner creates a project in a cloud they don't have access to as an individual, they are similarly not listed as the "Owner" of that project.
Ex-Admin Permissions
When an organization owner is demoted to a collaborator, they lose their implicit admin permissions but still keep any permissions granted explicitly to them as an individual.
- This includes both owner and collaborator permissions for a cloud, because those are granted at the individual level
- If an organization owner had access to a cloud and created projects in the cloud, they would still keep those project permissions as an ex-admin.
- However, the ex-admin would no longer be able to access any private projects they created in clouds they didn't have individual access to.
- These projects may not have an explicit owner anymore, so they can now only be accessed by other organization owners through their admin permissions.
Removing users from an organization
Any organization collaborator can be removed from an organization. Resources created by the user still exist in the organization, but the user will no longer be able to log into the organization or use their tokens to access these resources. Any private resources that only this user had access to will still be accessible to organization owners through admin permissions.
We don't currently support re-adding a user who was previously removed from an organization.
Cloud Permissions
Like organizations, clouds also support Owner and Collaborator roles.
- Owner: The organization admin who creates a cloud becomes the first owner of that cloud.
- Cloud owners can manage which users have either "Owner" or "Collaborator" permissions to a cloud.
- Only users in the organization are eligible to be granted either of these two cloud permissions.
- Only organization owners are eligible to be granted cloud "Owner" permissions at the individual level.
- Users will not get any additional implicit permissions (like organization admin permissions because they have the cloud owner permissions.
- However, it is likely the cloud owner is also an organization owner (unless they were demoted to organization collaborator), so they will get implicit organization admin permissions as an organization owner.
- Cloud owners also have all cloud collaborator permissions.
- Cloud owners can manage which users have either "Owner" or "Collaborator" permissions to a cloud.
At this time we do not support adding a non organization admin as a cloud owner. Cloud owner permissions are only granted to the organization admin (implicitly) or to the user who created a cloud (explicitly). We recommend all users who need to have cloud owner permissions be made admins of the organization.
- Collaborator: Cloud collaborators can view details about the cloud, and use the cloud to create any child Anyscale resources.
- All public resources within the cloud (compute configs and public projects) are accessible to cloud collaborators by default.
- Private resources can only be accessed within a cloud if permissions are separately granted. Eg: A cloud collaborator can access a private project by either being the owner of that private project or having the project shared with them.
Cloud details and owner actions are available at https://console.anyscale.com/configurations/clouds.
Removing users from a cloud
When a user is removed from a cloud, they lose access to all resources within the cloud. This could result in some projects that the user was previously an owner of to show up as (Removed user). Organization owners will still have implicit owner privileges on these projects through organization admin permissions, so they can explicitly re-assign another user as the owner to these.
Owners or collaborators can be directly removed from a cloud. However, owners cannot remove themselves, and instead must be removed by another cloud owner or through the implicit admin permissions of any organization owner.
If a user is re-added to a cloud they were previously removed from, they will only get access to public resources in the cloud (like any new cloud collaborator).
Auto add user to cloud
The auto add user feature can be enabled for clouds that should be accessible to all users in the organization. Cloud owners can modify this field in the UI in the cloud detail and owner actions page at https://console.anyscale.com/configurations/clouds. It can also be modified through the CLI with the anyscale cloud edit and anyscale cloud update commands (based on if the cloud is a managed cloud).
If this feature is enabled, all individual users in the organization will be granted cloud collaborator permissions and appear in the cloud collaborator table view. Cloud permissions can no longer be manually modified while the feature is enabled because all users need to have access. Note: It may take up to 30 seconds for cloud collaborator permissions to be granted after enabling this feature or if a new user is added to the organization.
Disabling this feature causes no change in cloud permissions for individual users. If some users received cloud collaborator permissions while the "auto add user" feature was enabled, those users will continue to have cloud collaborator permissions if the feature becomes disabled until a cloud owner manually modifies their individual permissions.
Project Permissions
To access a private project, a user must have Owner, Write, or Readonly permissions to the project. These permissions are not required to access public projects.
- 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, but a project owner can also make any cloud owner or cloud collaborator an owner on the project.
- Owners cannot modify their own role on the project
- Write: Users with "Write" permissions on a project can create and access any resource within the project, but cannot modify users who can access the project or their roles.
- This "Write" role is most similar to the "Collaborator" roles of organizations and clouds.
- Unlike organization or cloud collaborators, project writers can view other users who can access the project.
- This "Write" role is most similar to the "Collaborator" roles of organizations and clouds.
- Readonly: Users with "Readonly" permissions on a project cannot create/modify resources within the project but they can access these resources per the following rules. Readonly users can view which other users have access to the project, but cannot modify these user roles.
- Detailed permissions for resources in a project for a user with Readonly access:
- Cluster: Cannot modify cluster state or access Web Terminal. Can run Ray jobs, Serve deployments, and access Jupyter, Grafana, and Ray dashboard. Can access all logs through Anyscale UI or CLI.
- Anyscale Jobs/Services: Cannot modify the state of jobs/services or their underlying clusters, and cannot access Web Terminal of underlying cluster. Can still run Ray jobs, Serve deployments, and access Jupyter, Grafana, and Ray dashboard of underlying ephemeral cluster. Can access all logs through Anyscale UI or CLI.
- Workspaces: Cannot modify state of workspace or snapshot and duplicate the workspace. Cannot access Web Terminal on the workspace or the underlying cluster. Can open VSCode, Jupyter, Grafana, and Ray dashboard through the workspace. Can still run Ray jobs, Serve deployments, and access Jupyter, Grafana, and Ray dashboard of underlying cluster. Can access all logs through Anyscale UI or CLI.
- Note: The "Readonly" role doesn't guarantee a user cannot run code on clusters running in the project. Eg: it is possible to still run code through a terminal in Jupyter or Ray jobs on a cluster.
- This role primarily means a user cannot modify the state of the project itself by creating/modifying the state of child resources.
- Detailed permissions for resources in a project for a user with Readonly access:
Project permissions can be managed through the "Share project" popup from the "Share" button in the top left corner of project detail page (https://console.anyscale.com/projects/{project_id}).
Inheritance to child resources
Because there are no granular access controls for resources below a project, all clusters, workspaces, jobs, and services inherit permissions from their project.
Public vs Private Projects
Projects in Anyscale can either be public or private. Private projects are only accessible to project Owners or users who have been granted project level Write or Readonly access. Note: Implicit admin permissions allow organization owners to also access private projects as a project Owner.
In contrast, all members of the cloud have access to public projects with implicit Write permissions. Users with these implicit Write permissions will not show up in the "Share project" popup UI.
- It is still possible to grant the above individual user permissions to public projects. If a user has individual permissions assigned for a public project, the user will be able to act as the max of the implicit and explicit permissions.
- Eg: If the user is Readonly on a public project, they will be able to act with Write permissions.
- Eg: If the user is an Owner on a public project, they will continue to act as an Owner.
Each cloud has a public default project that is created on cloud creation. This project gets selected when a user creates a child resource in a cloud without specifying a project.
Removing users from a project
When a user is removed from a project, they no longer have permissions as an individual to access any resource in the project. However, any implicit permissions of the user (Eg: if the project is public, or the user is an admin) will continue to be valid.
Users with any project level permissions (Owner, Writer, Readonly) can be directly removed from a project. However, owners cannot remove themselves, and instead must be removed by another owner in the project or an organization owner with implicit admin permissions.
Because there are no granular access controls to resources below projects, if a user is re-added to a project they were previously removed from, they will continue to get access to all child resources with their new permission level.