The migration from grants to the RBAC model is an ongoing process that will happen over a period of time. While the migration is happening:

• On UI, the User & Grants tab will no longer be available. Since the introduction of Identity and Access in Cloud Manager, all access settings take place in the Identity and Access service. To learn more about it, see Comparison of User & Grants with Identity and Access.
• In Linode API, there are two sets of API endpoints, one supporting the legacy grants and one for the RBAC model. To learn more about the new API experience, see Comparison of Linode API for grants and Identity and Access .

Cloud compute services that are fully migrated to the RBAC model are called natively enabled services. However, some services are yet to be migrated to the RBAC model. These services are called non-natively enabled. The fact that they are not yet migrated doesn’t mean any loss of functionality. These services are also managed through Identity and Access, but with a slightly different experience. To learn more about it, see Identity and Access for non-natively enabled services.

Comparison of User & Grants with Identity and Access

Until the introduction of Identity and Access there was the User & Grants tab in the Accounts tool where an account administrator could assign to specific users:

• Full access, so that the user would become an unrestricted user.
• The legacy General permissions that enabled users to add various types of entities.
• Billing access.
• The legacy Specific permissions of None, Read Only and Read-write, for each entity of a specific type.

With the introduction of Identity and Access in Cloud Manager:

1. Grants of users who were already added to your account are migrated to their closest equivalent Identity and Access roles.
2. To set access for new users, see Manage user access (link to section). To summarize the differences in experience:
   1. To make a user an unrestricted user, you need to assign them the account_admin role.
   2. For natively-enabled services, there’s a list of roles available for assignment:
      1. The legacy General permissions are now account access roles. You can decide whether you want to enable just the creation of new entities (account_*_creator roles, for example account_linode_creator) or make the user an admin for a specific entity type (account_*_admin roles, for example account_linode_admin).
      2. For billing there are two account access roles available: account_billing_viewer and account_billing_admin.
      3. The legacy Specific permissions are now entity access roles with three possible levels of access:
      1. *_viewer, that allows you to view entities.
      2. *_contributor, that allows to view, create, and update entities.
      3. *_admin, that allows to perform all operations on entities.
      Where * is a specific entity type.

There’s no None access permission. If a user doesn’t have a service- or entity- specific role assigned to them, they don’t have access to it.

3. Review how the introduction of Identity and Access may have affected access for existing users to specific services.

❗️

TBD

Comparison of Linode API for grants and Identity and Access

Until the introduction of Identity and Access there were grants endpoints that an account administrator could use to:

• Make a user an unrestricted or restricted user.
• Grant users access to specific entities or actions.

With the introduction of Identity and Access:

a) Grants of users who were already added to your account are migrated to their closest equivalent Identity and Access roles.
b) To summarize the differences in experience:

• The unrestricted user is now a user with the account_admin role. You set the restricted parameter in the Create a user or Update a user's grants operations to false and it assigns the user the account_admin role. This role allows a user to list, view, create, update, and delete all entities in the account. To see the full list of permissions this role contains, see Available roles.
• For natively-enabled services, there’s a list of roles available for assignment:
  • To make the user an admin for a specific entity type, use the account_*_admin roles, for example account_linode_admin.
  • To enable just the creation of a specific type of entities, use the account_*_creator roles, for example account_linode_creator.
  • To grant users the same level of access as the legacy read-only account_access global grant, you need to assign the user with account_billing_viewer, user_profile_viewer and account_notification_viewer roles.
  • The billing access is now managed with account_billing_viewer and account_billing_admin roles:
    • account_billing_viewer allows a user to list and view all payments, invoices, and payment methods in the account.
    • account_billing_admin allows the user to list and view all payments, invoices, and payment methods in the account, as well as make payments, create promo codes, and create, update, and delete payment methods.
  • The legacy grants for a specific object type are now entity_access roles with three possible levels of access:
    • *_viewer, that allows you to view entities,
    • *_contributor, that allows to view, create, and update entities.
    • *_admin, that allows to perform all operations on entities.
      Where * is a specific entity type, for example a linode.

Below is the list of grants operations and their corresponding Identity and Access operations. Note that each operation requires a specific grant or role to invoke the endpoint. To learn what’s required, read the respective API endpoint documentation.

🚧

Security warning

You should not combine grants and Identity and Access operations. This means that you need to decide whether you want to continue using the grants operations or switch to Identity and Access operations.

To ensure the security of your account, once you switch to Identity and Access endpoints, use the Identity and Access endpoints consistently. By mixing grants and Identity and Access operations, you may expose your account to security risks, due to differences in access control between the two systems.

API workflows

This section compares the workflows for grants and Identity and Access endpoints.

Identity and Access for non-natively enabled services

Currently, not all services available in Cloud Manager are natively enabled in Identity and Access. Read this section, to learn how the experience for these services differs.

Roles for non-natively enabled services Identity and Access don’t include a collection of associated fine-grained permissions, both in UI and API. They are directly translated into a set of roles:

• The legacy General permissions changed into account access account_*_creator roles, where * is replaced with the type of entity. For example account_volume_creator.
• The legacy Specific permissions changed into basic entity access roles:
  • The Read Only roles changed into *_viewer roles, where * is replaced with the type of entity. For example volume_viewer.
  • The Read-Write roles changed into *_admin roles, where * is replaced with the type of entity. For example vpc_admin.