User roles and privileges
Elastic Cloud Hosted Serverless
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:
- Go to the user icon on the header bar and select Organization.
- Find the user on the Members tab of the Organization page. Click the member name to view their roles.
- Click Edit to change the user's roles.
There are two types of roles you can assign to users:
- Oranization-level roles: These roles apply to the entire organization and are not specific to any serverless project or hosted deployment.
- Instance 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 instances (Elastic Cloud Hosted deployments and Elastic Cloud Serverless projects), 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 instance access roles at two levels:
- Globally, for all Elastic Cloud Hosted deployments, or for all Elastic Cloud Serverless projects of the time 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 instance 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
instance 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 Instance access roles 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. Note that 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.
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.
- Instance 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.