User roles and privileges
Within an Elastic Cloud organization, users can have one or more roles and each role grants specific privileges.
You can assign user roles when you invite users to join your organization. You can also edit the roles assigned to a user later.
On this page, you'll learn the following:
- How to edit a user's roles
- The types of roles available, the levels where they can be applied, and the scope of each role type
- The predefined roles available for Elastic Cloud Hosted and Elastic Cloud Serverless
To edit the roles assigned to a user:
- Log in to Elastic Cloud.
- From the navigation menu, select Organization > Members.
- Select the user on the Members tab of the Organization page.
- Click Edit to change the user's roles.
There are two types of roles you can assign to users:
- Organization-level roles: These roles apply to the entire organization and are not specific to any serverless project or hosted deployment.
- Cloud resource access roles: These roles are specific to each serverless project or hosted deployment.
- Organization owner: The role assigned by default to the user who created the organization. Organization owners have all privileges to Elastic Cloud resources including Elastic Cloud Hosted deployments and Elastic Cloud Serverless projects, as well as users, organization-level details and properties, billing details and subscription levels. They are also able to sign on to deployments with superuser privileges.
- Billing admin: Can manage an organization’s billing details such as credit card information, subscription and invoice history. Cannot manage other organization or deployment details and properties.
You can set cloud resource access roles at two levels:
- Globally, for all Elastic Cloud Hosted deployments, or for all Elastic Cloud Serverless projects of the same type (Elasticsearch Serverless, Observability, or Elastic Security). In this case, the role will also apply to new deployments, or projects of the specified type type, created later.
- Individually, for specific deployments or projects only. To do that, you have to leave the Role for all hosted deployments field, or the Role for all for the project type, blank.
Elastic Cloud Hosted deployments and Elastic Cloud Serverless projects each have a set of predefined cloud resource access roles available:
If you're using Elastic Cloud Serverless, you can optionally create custom roles in a project. All custom roles grant the same access as the Viewer cloud resource access role with regards to Elastic Cloud privileges. To grant more Elastic Cloud privileges, assign more roles. Users receive a union of all their roles' privileges. To assign a custom role to users, go to Cloud resource access and select it from the list under the specific project it was created in.
For Elastic Cloud Hosted deployments, the following predefined roles are available:
- Admin: Can manage deployment details, properties and security privileges, and is able to sign on to the deployment with superuser privileges. This role can be scoped to one or more deployments. In order to prevent scope expansion, only Admins on all deployments can create new deployments.
- Editor: Has the same rights as Admin, except from deployment creation and management of security privileges. Editors are able to sign on to the deployment with the “editor” stack role. This role can be scoped to one or more deployments.
- Viewer: Can view deployments, and can sign on to the deployment with the viewer Stack role. This role can be scoped to one or more deployments.
There are two ways for a user to access Kibana instances of an Elastic Cloud Hosted deployment:
- Directly with Elasticsearch credentials. In this case, users and their roles are managed directly in Kibana. Users in this case don’t need to be members of the Elastic Cloud organization to access the deployment. If you have several deployments, you need to manage users for each of them, individually.
- Through your Elastic Cloud organization. In this case, users who are members of your organization log in to Elastic Cloud and can open the deployments they have access to. Their access level is determined by the roles assigned to them from the Organization page. Elastic Cloud roles are mapped to Elastic Stack roles on a per-deployment level. When logging in to a specific deployment, users get the stack role that maps to their Elastic Cloud role for that particular deployment.
The following table shows the default mapping:
| Cloud role | Cloud API role_id |
Stack role |
|---|---|---|
| Organization owner | organization-admin |
superuser |
| Billing admin | billing-admin |
none |
| Admin | deployment-admin |
superuser |
| Editor | deployment-editor |
editor |
| Viewer | deployment-viewer |
viewer |
You can apply the following predefined roles to Elastic Cloud Serverless projects. Some roles are only available to certain project types.
In the following table, the privileges outlined in Project access require Cloud Console, Elasticsearch, and Kibana access to be granted for the relevant projects.
You can optionally create custom roles in a project and apply them to your organization users.
Roles are assigned to every member of an organization and can refer (or be scoped) to one or more specific deployments, or all deployments. When a role is scoped to all deployments it grants permissions on all existing and future deployments.
This list describes the scope of the different roles:
- Organization owner: This role is always scoped to administer all deployments.
- Billing admin: This role does not refer to any deployment.
- Cloud resource access roles, including Admin: These roles can be scoped to either all deployments or projects, or specific deployments, project types, or projects.
Members are only able to see the role assignments of other members under the organization they belong to, for role assignments they are able to manage. Members with the Organization owner role assigned are able to see the role assignments of every member of their organization.
Members with the Admin role assigned are able to see role assignments for deployments or projects within their scope. For example, admins of all deployments and projects are able to see role assignments scoped to all and specific deployments and projects in the organization, while admins of specific deployments or projects only see role assignments scoped to those specific deployments or projects. This ensures that members assigned to specific deployments or projects do not try to remove role assignments from other members, and that the existence of other deployments or projects are not revealed to these members.
When you grant Organization owner access, or Cloud resource access for one or more Serverless projects, you can select the surfaces the user can access:
| Access | Grants |
|---|---|
| Cloud Console, Elasticsearch, and Kibana (default) | Grants access to the Elastic Cloud Console, plus the Kibana interface and Elasticsearch service for the applicable projects. |
| Cloud Console | Grants access to only the Elastic Cloud Console for the applicable Serverless projects. |
The Access selection impacts the behavior of the selected role. Most roles require Cloud Console, Elasticsearch, and Kibana access to take full effect. However, you might choose to only grant Cloud Console access if the user does not need to interact with the project directly.
When Cloud Console, Elasticsearch, and Kibana access is not granted, roles that are designed to work inside of the project have limited access, and can't open the project in Kibana. For example:
- If you select the Admin role, the user is able configure project settings and network security in Elastic Cloud, but can't log in to the relevant projects as superuser.
- Several predefined roles that are intended for project users, such as the Security Tier 1 analyst role, can view the relevant projects on the Elastic Cloud Console home page, but can't open the project to view their dashboards and visualizations.
- Custom roles always require Cloud Console, Elasticsearch, and Kibana access. Without it, users have only Viewer access in the Elastic Cloud Console, and can't log in to the project.
For details on the permissions granted for each role, refer to the predefined roles table.
When inviting a user to your organization with the Elastic Cloud API, you can set their access surfaces in the invitation request. To grant Elastic Cloud Console-only access, pass an empty application_id array in the role assignment. For an example, refer to Manage users.