Overview

Identity and Access in Cloud Manager is used to manage identities within an account and manage operations that those identities may perform. By authenticating identities and authorizing them to access specific services and entities, Identity and Access ensures that the right identities access the right entities. Identity and Access uses the role-based access control (RBAC) model to authorize operations on entities.

❗️

UPDATE NEEDED

Currently, Identity and Access in Cloud Manager is natively enabled for ENTER INTEGRATED SERVICES. To learn about the experience for non-natively enabled services, see Identity and Access for non-natively enabled services.

📘

Identity and Access in Control Center and in Cloud Manager

Identity and Access in Control Center and Identity and Access in Cloud Manager are two different services. This documentation is for Identity and Access in Cloud Manager. The documentation for Identity and Access in Control Center is available here.

Glossary

These terms will help you understand and work with Identity and Access in Cloud Manager.

• Role-based access control (RBAC). In the RBAC model, each service has a set of fine-grained permissions that control access to a specific service API endpoint. These permissions are then combined into predefined, functional roles that can be assigned to users.

• Identity. An identity can be authenticated in Identity and Access and represents a human user.

  • User. A user is a type of identity that can be authenticated through Identity and Access. The user identity is represented by a username.
  • Authentication methods. In Akamai cloud computing, an identity can be verified by credentials or third-party authentication.

• Account. An account represents an entry point for users to access and manage Akamai cloud compute’s settings, billing, and cloud computing services, including identities and access control. To prevent services and settings from being shared between accounts, each account has its own unique ID with which all services and settings are associated. To learn more about accounts, see Accounts.

• Entity. An object that has a life-cycle and can be managed by an authorized user within an account, for example: a specific virtual machine or firewall rule set. A user manages an entity over time by performing operations on it.

  • Entity type. A service or capability that an entity corresponds to. For example, your virtual machines have an entity type of Linode, and your firewall rule sets have an entity type of Firewall.

• Operation. Each entity in Akamai cloud computing has a defined list of operations that an identity can potentially perform on it, for example create a Linode. Each operation is mapped to one corresponding permission.

• Permission. A permission is the lowest, granular level of access defined by ​Akamai​. It represents a single API endpoint and its name derives from corresponding operations. For example, the resize_linode permission represents the Linode’s API Resize a Linode operation.

• API (Application Programming Interface). A set of rules, definitions, and protocols that allow software applications to communicate with each other or users to interact with a software. It defines how requests and responses should be structured and provides access to specific functionalities of a system. Each API typically exposes a set of endpoints that clients can interact with.
  The Linode API for Identity and Access allows users to interact with the Akamai Cloud platform and manage entities.

  • API endpoint. An API endpoint is a URL where an API receives requests from clients. Each endpoint corresponds to a unique operation on an entity and serves as the access point for interacting with the API. The API server checks if the user has the appropriate permission to invoke the API, and if so, processes the request at the endpoint and returns a response.

• Role. A role is a collection of permissions. It represents a function that a user has in a business organization. The role enables the necessary access to perform the allowed operations on the corresponding entities satisfying the function that the user or system has.
  There are two types of roles:

  • Account access roles. These roles give access to:

    • Account level operations, such as account settings, service transfers, billing and payment. Examples of such a role are account_viewer or account_billing_admin.
    • Instances of entities in the account both existing and to be created in the future. An example of such a role is account_linode_admin that enables to create new Linode as well as manage the existing ones.
    • Create new entities. An example of such a role is account_firewall_creator that enables you to create new firewalls.

  In Linode API for Identity and Access, you’ll see these roles as account_access. In the list of roles on the user interface (UI), in the Roles tab, these roles have the Account Access role type and when assigning such role to a user, you’ll see that they have All entities assigned by default.

  • Entity access roles. These roles provide access to specific entities already available on the account, for example linode_admin. In Linode API for Identenity and Access you’ll see these roles as entity_access. In the list of roles on UI, in the Roles tab, these roles have the Entity Access role type and when assigning such roles to a user, you’ll need to select specific entities you want to provide access to.

  Example:
  The account_linode_admin role is an account access role. It gives administrative access to all of the Linode in the account, including any that are created in the future.

  The linode_admin role is an entity access role. It gives administrative access only to the specific existing Linode instances attached to the role. In contrast to the account_linode_admin account role, users with the linode_admin role won’t get access to new Linodes until they are attached to the linode_admin role assigned to them.

Example

❗️

DIAGRAM TBD

On this account there are two users. User A is the administrator of the account, as they have the account_admin role that includes all permissions to all services. This role applies to all entities currently available on the account, and because this is the account access role, it also applies to entities to be created in the future.

This user added another user to the account: User B.

User B has has two roles assigned: firewall_viewer and account_linode_creator:

1. The firewall_viewer role is an entity access role. This means that when assigning this role to the user, the administrator had to select firewall rules sets the User B should have access to: firewall1 and firewall2.
   Each of the permissions included in the role reflect a single API operation:

📘

In the context of firewall, permissions contain the term device instead of entity, but these terms are equivalent.

2. The account_linode_creator role is an account access role that applies only to one type of entity, namely Linodes. Each of the included permissions reflect one API operation: