Manage custom roles

Astra uses role-based access control (RBAC) to manage the levels of access that users and applications have to your databases and organizations.

Roles define the level of access that an entity has to your organization and databases. Roles are assigned to users and application tokens. Then, users and applications can interact with your Astra resources according to the permissions granted by the assigned roles.

You can use default (built-in) and custom roles. All roles have a set of permissions and resource scopes.

When you create and assign roles, consider your organization’s security policies and industry best practices for RBAC, such as the principle of least privilege.

You can use an IdP for Astra entitlement management and SSO. For more information, see Use SCIM for Astra entitlement management and Configure single sign-on for Astra.

Use custom roles to tailor granular permissions for your teams and applications. For example, you could create one custom role with access to a few databases and another custom role with access to specific keyspaces in one database only.

Prerequisites

To manage custom roles for an organization, you must have a role with the Read Custom Role, Write Custom Role, and Delete Custom Role permissions, such as the Organization Administrator role.

To manage custom roles for an enterprise, you must have a role with the Read Enterprise Role and Write Enterprise Role permissions, such as the Enterprise Administrator role.

Inspect roles

Before creating custom roles, inspect the existing roles to avoid duplicating roles.

There are several ways to inspect roles and the permissions granted those roles.

Inspect roles in the Astra Portal

There are two ways to inspect roles in the Astra Portal:

Tokens page

In the Astra Portal, you can inspect role permissions when creating application tokens at the organization or enterprise level. You don’t need to create the token, but you can use the Tokens page to preview a role’s permissions

In the Astra Portal header, click Settings.
In the Settings navigation menu, make sure the enterprise/organization filter is set to the enterprise or organization that you want to manage.

To view an organization that belongs to an enterprise, you must filter on the enterprise, and then click the organization name in the Organizations list.
In the Settings navigation menu, click Tokens.

The Tokens page for an enterprise exposes enterprise roles only.

The Tokens page for an organization exposes organization roles only.
In the Generate new token section, select a role to view the roles permissions.

Roles page

In the Astra Portal, you can inspect custom roles on the Roles page.

This method exposes custom roles only. To inspect built-in roles, you must use another method.

In the Astra Portal header, click Settings.
In the Settings navigation menu, make sure the enterprise/organization filter is set to the enterprise or organization that you want to manage.

To view an organization that belongs to an enterprise, you must filter on the enterprise, and then click the organization name in the Organizations list.

In the Settings navigation menu, click Roles.

The Role management page for an enterprise exposes custom enterprise roles only.

The Role management page for an organization exposes custom organization roles only.

Custom roles named DATABASE_NAME Database Administrator are automatically created when you generate an application token scoped to a database, and you can edit these roles like any other custom role.

Inspect roles with the DevOps API

This is the only method that exposes resource scopes for all roles.

To get information about all built-in and custom roles in an organization, use GET /v2/organizations/roles:

curl -sS -L -X GET "https://api.astra.datastax.com/v2/organizations/roles" \
--header "Authorization: Bearer APPLICATION_TOKEN" \
--header "Content-Type: application/json"

The returned roles depend on the scope of the application token. Organization-scoped application tokens return the roles in that organization. Enterprise-scoped application tokens return the roles in that enterprise.

For each role, the response includes the following:

id: Role ID

Once you have a role’s ID, you can use GET /v2/organizations/roles/ROLE_ID to get information for that role only.

name: Role name

last_update: The date and time when the role was last edited
policy: An object defining the role’s permissions and resource access, including the following fields:
- description: The role name.
- resources: An array of resource IDs that define the role’s access to Astra resources. For more information, see Resource scopes.
- actions: The permissions granted to the role.
- effect: Indicates that the role grants access to the named resources and permissions. This is always allow.

The following example is truncated for clarity:

Result

[
  {
    "id": "ad0566b5-2a67-49de-89e8-92258c2f2c98",
    "name": "Organization Administrator",
    "policy": {
      "description": "Organization Administrator",
      "resources": [
        "drn:astra:org:__ORG_ID__",
        "drn:astra:org:__ORG_ID__:db:*",
        "drn:astra:org:__ORG_ID__:db:*:keyspace:*",
        "drn:astra:org:__ORG_ID__:db:*:keyspace:*:table:*",
        "drn:astra:org:__ORG_ID__:stream:*",
        "drn:astra:org:__ORG_ID__:role:*"
      ],
      "actions": [
        "accesslist-read",
        "accesslist-write",
        "org-read",
        "org-write",
        ...TRUNCATED...
        "db-table-alter",
        "db-table-drop",
        "db-manage-thirdpartymetrics"
      ],
      "effect": "allow"
    },
    "last_update_date_time": "0001-01-01T00:00:00Z",
    "last_update_user_id": ""
  },
  {
    "id": "b73e44b2-b9e9-43b8-a7c1-c6a2fe2dab50",
    "name": "R/W User",
    "policy": {
      "description": "R/W User",
      "resources": [
        "drn:astra:org:__ORG_ID__",
        "drn:astra:org:__ORG_ID__:db:*",
        "drn:astra:org:__ORG_ID__:db:*:keyspace:*",
        "drn:astra:org:__ORG_ID__:db:*:keyspace:*:table:*"
      ],
      "actions": [
        "accesslist-read",
        "org-db-view",
        ...TRUNCATED...
        "db-cql"
       ],
      "effect": "allow"
    },
    "last_update_date_time": "0001-01-01T00:00:00Z",
    "last_update_user_id": ""
  }
]

Create a custom role

You can use the Astra Portal and the DevOps API to create and manage custom roles for your Astra organizations and enterprise.

Create a custom role in the Astra Portal

You can create custom enterprise and organization roles in the Astra Portal:

Create a custom enterprise role

In the Astra Portal header, click Settings.
In the Settings navigation menu, make sure the enterprise/organization filter is set to your enterprise.
In the Settings navigation menu, click Roles.
Click Add Custom Role.
Enter a name for the role.
Assign enterprise permissions and resource scope.
Click Create Custom Role.

Create a custom organization role in the Astra Portal

In the Astra Portal header, click Settings.
In the Settings navigation menu, make sure the enterprise/organization filter is set to the organization that you want to manage.

If the organization belongs to an enterprise, you must filter on the enterprise, and then click the organization name in the Organizations list.
In the Settings navigation menu, click Roles.
Click Add Custom Role.
Enter a name for the role.
Select permissions to grant to the role.
In the Add Databases section, define the role’s resource scope.

You can select specific databases and keyspaces. Or, you can enable Apply permissions to all databases in this organization to allow access to all current and future databases, as well as the keyspaces within those databases.

For more granular control over resource scopes, use the DevOps API to create the role.
Click Create Role.

Next, assign roles to users and application tokens. Then, users and applications can interact with your enterprise, organization, and databases according to the permissions granted by the assigned roles.

Create a custom role with the DevOps API

Use GET /v2/organizations/roles to get a template for the custom role configuration:
```
curl -sS -L -X GET "https://api.astra.datastax.com/v2/organizations/roles" \
--header "Authorization: Bearer APPLICATION_TOKEN" \
--header "Content-Type: application/json"
```
The returned roles depend on the scope of the application token. Organization-scoped application tokens return the roles in that organization. Enterprise-scoped application tokens return the roles in that enterprise.

From the response, find any role that is similar to your new role, and then copy the role’s name and policy, including all policy subfields (description,resources, actions, and effect). For example:

"name": "Demo Custom Role",
"policy": {
  "description": "Demo Custom Role",
  "resources": [
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e",
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:*",
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:*:keyspace:*",
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:*:keyspace:*:table:*"
  ],
  "actions": [
    "accesslist-read",
    "org-db-view",
    "db-cql"
   ],
  "effect": "allow"
}

Use POST /v2/organizations/roles to create a custom role:
```
curl -sS -L -X POST "https://api.astra.datastax.com/v2/organizations/roles" \
--header "Authorization: Bearer APPLICATION_TOKEN" \
--header "Content-Type: application/json" \
--data '{
  "name": "ROLE_NAME",
  "policy": {
    "description": "ROLE_NAME",
    "resources": [
      "RESOURCE_ID",
      "RESOURCE_ID",
      "RESOURCE_ID"
    ],
    "actions": [
      "PERMISSION_NAME",
      "PERMISSION_NAME"
    ],
    "effect": "allow"
  }
}'
```
The application token determines where the role is created. To create a custom role in an organization, provide an application token scoped to that organization. To create a custom role in an enterprise, provide an application token scoped to that enterprise. Enterprise application tokens cannot create custom roles in organizations, even if the organization belongs to the enterprise.

Use the information that you copied from the GET /v2/organizations/roles response as the basis of the POST request body:
- name: The role name.
- policy.description: The role name.
- policy.resources: An array of resource IDs that define the role’s access to Astra resources.
  
  If you copied a built-in role from the GET /v2/organizations/roles response, replace __ORG_ID__ in each resource ID with your organization ID.
  
  For more information and policy examples, see Resource scopes.
- policy.actions: Provide an array of permissions to grant to the role. Use the DevOps API value for each permission, not the Astra Portal display name.
- policy.effect: Must be allow.
A successful response includes the new role’s id as well as the name and policy you specified.

If you try to create a role that already exists, the server returns 409 Conflict and the message unable to update custom role data.

Resource scopes

Built-in organization roles can access all databases, keyspaces, tables, and collections (Astra DB Serverless only) in an Astra organization. This includes all existing resources and any resources created in the future by you or another user in your Astra organization.

For custom roles, you can define resource scopes that limit access to resources like databases, keyspaces, and tables. Resource scopes apply an additional layer of restriction on top of the permissions granted to the role. For example, if you have a role with the Create Keyspace permission, and you limit that role to a specific database, then that role can only create keyspaces within that specific database.

In resource scopes, tables applies to all of the following:

Collections in Astra DB Serverless databases
Tables in Astra DB Serverless databases
Tables in Astra Managed Clusters databases

Scopes restrict all permissions for the role, wherever applicable. For example, if you limit the scope for a role with the View DB and Create Keyspace permissions, the scope applies to both of those permissions.

If you need to mix scopes and permissions, you must create multiple custom roles with the required scopes. For example, you could create a custom View Production DBs role with the View DB permission scoped to your production databases only and a custom Manage Dev DBs role that has permission to view and edit development databases.

Define resource scopes in the Astra Portal

The Astra Portal provides limited control over resource scopes when you create or edit custom roles:

All databases: Grant access to all databases in the organization, including those currently existing and future databases. This includes all existing and future keyspaces and tables in all databases.
Specific databases and keyspaces: Grant access to specific existing databases and existing keyspaces in those databases. You can choose either all existing keyspaces or specific existing keyspaces. Future keyspaces are not included, but all existing and future tables in the selected keyspaces are included.

If you limit a role’s scope to specific databases and keyspaces, you must manually update the role to include new databases and keyspaces that you create in the future.

If you need more control over resource scopes, use the DevOps API.

Define resource scopes with the DevOps API

With the DevOps API, you can define highly granular and variable resource scopes when you create or edit custom roles.

A role’s resource scopes are defined in resources as an array of resource IDs. For example:

"resources":[
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e",
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:b7aafc99-b1fe-492c-b130-73cad3c008cc",
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:b7aafc99-b1fe-492c-b130-73cad3c008cc:keyspace:system_schema:table:*",
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:b7aafc99-b1fe-492c-b130-73cad3c008cc:keyspace:system:table:*",
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:b7aafc99-b1fe-492c-b130-73cad3c008cc:keyspace:system_virtual_schema:table:*",
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:b7aafc99-b1fe-492c-b130-73cad3c008cc:keyspace:default_keyspace",
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:b7aafc99-b1fe-492c-b130-73cad3c008cc:keyspace:default_keyspace:table:*",
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:b7aafc99-b1fe-492c-b130-73cad3c008cc:keyspace:other_keyspace",
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:b7aafc99-b1fe-492c-b130-73cad3c008cc:keyspace:other_keyspace:table:*"
  ],

The broadest resource ID is drn:astra:org:ORGANIZATION_ID, which grants access to your Astra organization within the bounds of the role’s permissions.

Narrower resource IDs append multiple suffixes to reduce the scope to resources within the organization. For example, the following resource IDs grant access to specific resources, identified by name or ID:

Examples: Narrow resource scopes

# Access to the organization
"drn:astra:org:ORGANIZATION_ID"

# Access to a specific database
"drn:astra:org:ORGANIZATION_ID:db:DATABASE_ID"

# Access to a specific keyspace in a database
"drn:astra:org:ORGANIZATION_ID:db:DATABASE_ID:keyspace:KEYSPACE_NAME"

# Access to a specific table in a keyspace
"drn:astra:org:ORGANIZATION_ID:db:DATABASE_ID:keyspace:KEYSPACE_NAME:table:TABLE_NAME"

You can use an asterisk (*) as a wildcard to grant access to all instances of a resource type, including existing and future instances of that type:

Examples: Wildcard resource scopes

# Access to all databases in an organization
"drn:astra:org:ORGANIZATION_ID:db:*"

# Access to all keyspaces in a specific database
"drn:astra:org:ORGANIZATION_ID:db:DATABASE_ID:keyspace:*"

# Access to all tables in a specific keyspace
"drn:astra:org:ORGANIZATION_ID:db:DATABASE_ID:keyspace:KEYSPACE_NAME:table:*"

# Access to all streaming tenants in an organization
"drn:astra:org:ORGANIZATION_ID:stream:*"

Access to a higher-level resource inherently grants access to associated lower-level resources, unless you explicitly define a narrower resource ID.

For example, the resource ID drn:astra:org:ORGANIZATION_ID:db:DATABASE_ID grants access to all keyspaces and tables within the specified database. If the policy also includes drn:astra:org:ORGANIZATION_ID:db:DATABASE_ID:keyspace:KEYSPACE_NAME, then the role is limited to the specified keyspace and its tables, rather than the entire database.

If you use a wildcard, place it at the lowest possible level to avoid granting excessive access. For example, the resource ID drn:astra:org:ORGANIZATION_ID:db:* grants access to all current and future databases, keyspaces, and tables in the organization. In contrast, drn:astra:org:ORGANIZATION_ID:db:DATABASE_ID:keyspace:* grants access to all current and future keyspaces and tables within a single database.
Custom role scopes are limited to the resources named in the policy, unless you use a wildcard. When you create new databases, keyspaces, or tables, you might need to edit narrowly-scoped custom roles to include the new resources, if necessary.

Unresolved organization ID or enterprise ID in resource scopes

For built-in roles, resource IDs include literally __ORG_ID__ instead of a resolved organization ID. Custom roles include the fully resolved organization ID in each resource ID.

Built-in enterprise roles have literally __ENT_ID__ in their resource IDs, while custom enterprise roles have the fully resolved enterprise ID. Additionally, built-in enterprise administration roles have the drn:astra:org:__ORG_ID__ resource scope because these roles need to view and interact with organizations in the enterprise.

If you copy a built-in role’s policy object as a template for a custom role, replace __ORG_ID__ or __ENT_ID__ with your actual organization or enterprise ID.

Resource scope examples

To get examples of resource scopes, use GET /v2/organizations/roles:

curl -sS -L -X GET "https://api.astra.datastax.com/v2/organizations/roles" \
--header "Authorization: Bearer APPLICATION_TOKEN" \
--header "Content-Type: application/json"

For each role, the response includes the id, name, policy, and last_update metadata. The resources array is in the policy object. For example:

  {
    "id": "b73e44b2-b9e9-43b8-a7c1-c6a2fe2dab50",
    "name": "R/W User",
    "policy": {
      "description": "R/W User",
      "resources": [
        "drn:astra:org:__ORG_ID__",
        "drn:astra:org:__ORG_ID__:db:*",
        "drn:astra:org:__ORG_ID__:db:*:keyspace:*",
        "drn:astra:org:__ORG_ID__:db:*:keyspace:*:table:*"
      ],
      "actions": [
        "accesslist-read",
        "org-db-view",
        "org-user-read",
        "db-all-keyspace-describe",
        "db-keyspace-describe",
        "db-table-select",
        "db-table-modify",
        "db-table-describe",
        "db-graphql",
        "db-rest",
        "db-cql"
       ],
      "effect": "allow"
    },
    "last_update_date_time": "0001-01-01T00:00:00Z",
    "last_update_user_id": ""
  },

Additional custom role policy examples

These examples describe custom API roles that you could assign to an application token. They are considered API roles because they don’t have the View DB (org-db-view) permission that is required to access the Astra Portal.

Edit one table within a specific keyspace

"name": "API_MODIFY_ONLY_TABLE1",
"policy": {
  "description": "API_MODIFY_ONLY_TABLE1",
  "resources": [
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:b7aafc99-b1fe-492c-b130-73cad3c008cc:keyspace:default_keyspace:table:table1"
  ],
  "actions": [
    "db-table-select",
    "db-table-describe",
    "db-table-grant",
    "db-table-alter",
    "db-table-authorize",
    "db-table-modify"
  ],
  "effect": "allow"
}

Edit all tables within three specific keyspaces

"name": "API_MODIFY_ALL_TABLES",
"policy": {
  "description": "API_MODIFY_ALL_TABLES",
  "resources": [
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:b7aafc99-b1fe-492c-b130-73cad3c008cc:keyspace:default_keyspace:table:*"
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:b7aafc99-b1fe-492c-b130-73cad3c008cc:keyspace:second_keyspace:table:*"
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:b7aafc99-b1fe-492c-b130-73cad3c008cc:keyspace:third_keyspace:table:*"
  ],
  "actions": [
    "db-table-select",
    "db-table-describe",
    "db-table-grant",
    "db-table-alter",
    "db-table-authorize",
    "db-table-modify"
  ],
  "effect": "allow"
}

Read-only access to all tables in all keyspaces in one database

"name": "API_READ_ONLY",
"policy": {
  "description": "API_READ_ONLY",
  "resources": [
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:b7aafc99-b1fe-492c-b130-73cad3c008cc:keyspace:*"
  ],
  "actions": [
    "db-table-select",
    "db-table-describe"
  ],
  "effect": "allow"
}

Troubleshoot custom role resource scopes

If you encounter issues with a custom role, try the following:

Use GET /v2/organizations/roles to retrieve role policies for other roles in your organization.
Compare your role’s policy with other polices to ensure the role has the necessary permissions and resource scopes.

If the role requires access to the Astra Portal, the policy must include the View DB (org-db-view) permission and access to the drn:astra:org:ORGANIZATION_ID resource.
Make sure resources contains the correct IDs and names for each resource.
If you encounter issues with a custom role that aren’t resolved by other policy modifications, the policy might require certain resource IDs for minimal functionality. In addition to drn:astra:org:ORGANIZATION_ID, which grants access to the organization itself, policies that reach the keyspace level might require access to the following system keyspaces and tables. These resources aren’t directly manipulated by the user.
```
"drn:astra:org:ORGANIZATION_ID:db:DATABASE_ID:keyspace:system_schema:table:*"
"drn:astra:org:ORGANIZATION_ID:db:DATABASE_ID:keyspace:system:table:*"
"drn:astra:org:ORGANIZATION_ID:db:DATABASE_ID:keyspace:system_virtual_schema:table:*"
```

Edit a custom role

You can edit any custom roles in your enterprise or organization, including custom DATABASE_NAME Database Administrator roles that Astra creates when you generate an application token scoped to a database.

After you edit a custom role, it can take several minutes for the changes to propagate to all tokens and users that are assigned to that role.

When you edit a custom role, consider the effects that your changes can have on existing tokens and users assigned to that role. For example, revoking necessary permissions from a production token can cause an application to fail. Administrators can mitigate this risk by observing industry best practices for RBAC, such as the principle of least privilege, regular permissions auditing, and using meaningful names to clearly describe a custom role’s purpose or permissions.

Edit a custom role in the Astra Portal

In the Astra Portal header, click Settings.
In the Settings navigation menu, make sure the enterprise/organization filter is set to the enterprise or organization that you want to manage.

To view an organization that belongs to an enterprise, you must filter on the enterprise, and then click the organization name in the Organizations list.
In the Settings navigation menu, click Roles.
Find the role you want to edit, click More, and then select Edit Role.
Modify the role’s name and permissions as necessary, and then click Edit Role to save your changes.

Edit a custom role with the DevOps API

A role’s policy object is a desired state list. When you use the DevOps API to edit a role, use the existing policy object as a template to ensure that you don’t unintentionally remove any permissions.

Use GET /v2/organizations/roles to get the role’s current configuration:
curl -sS -L -X GET "https://api.astra.datastax.com/v2/organizations/roles" \ --header "Authorization: Bearer APPLICATION_TOKEN" \ --header "Content-Type: application/json"
The response includes information about all built-in and custom roles in the organization or enterprise associated with the provided application token.

From the response, find the custom role you want to edit, and then copy the id, name, and the entire policy object, including all policy subfields (description,resources, actions, and effect). For example:

"id": "b73e44b2-b9e9-43b8-a7c1-c6a2fe2dab50",
"name": "Demo Custom Role",
"policy": {
  "description": "Demo Custom Role",
  "resources": [
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e",
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:*",
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:*:keyspace:*",
    "drn:astra:org:b6bbc50b-8164-5f59-a3b1-55a8196b352e:db:*:keyspace:*:table:*"
  ],
  "actions": [
    "accesslist-read",
    "org-db-view",
    "db-cql"
   ],
  "effect": "allow"
}

Use PUT /v2/organizations/roles/ROLE_ID to edit the role.
```
curl -sS -L -X PUT "https://api.astra.datastax.com/v2/organizations/roles/ROLE_ID" \
--header "Authorization: Bearer APPLICATION_TOKEN" \
--header "Content-Type: application/json" \
--data '{
  "name": "ROLE_NAME",
  "policy": {
    "description": "ROLE_NAME",
    "resources": [
      "RESOURCE_ID",
      "RESOURCE_ID",
      "RESOURCE_ID"
    ],
    "actions": [
      "PERMISSION_NAME",
      "PERMISSION_NAME"
    ],
    "effect": "allow"
  }
}'
```
Use the same application token that you used with GET /v2/organizations/roles.

Use the information that you copied from the GET /v2/organizations/roles response as the basis of the PUT request body:
- name: Edit this field if you want to change the role name.
- policy.description: Edit this field if you want to change the role name.
- policy.resources: An array of resource IDs that define the role’s access to Astra resources. For more information and policy examples, see Resource scopes.
- policy.actions: Provide an array of permissions to grant to the role. Use the DevOps API value for each permission, not the Astra Portal display name.
- policy.effect: Must be allow.
Optional: To review the applied policy, use GET /v2/organizations/roles/ROLE_ID.

Delete a custom role

Deleting a custom role removes it from all users and application tokens that it is assigned to. To ensure continuity of access, do the following before deleting a custom role, if needed:

Reassign any users with the role to other roles.
Generate new application tokens with different roles.

Using the Astra Portal and the DevOps API, you can delete custom roles for your Astra organizations and enterprise.

You cannot delete built-in roles.

Delete a custom role in the Astra Portal

In the Astra Portal header, click Settings.
In the Settings navigation menu, make sure the enterprise/organization filter is set to the enterprise or organization that you want to manage.

To view an organization that belongs to an enterprise, you must filter on the enterprise, and then click the organization name in the Organizations list.
In the Settings navigation menu, click Roles.
Find the role you want to delete, click More, and then select Delete Role.
In the confirmation dialog, click Delete Role.

Delete a custom role with the DevOps API

Use GET /v2/organizations/roles to get the IDs of the roles that you want to delete:
curl -sS -L -X GET "https://api.astra.datastax.com/v2/organizations/roles" \ --header "Authorization: Bearer APPLICATION_TOKEN" \ --header "Content-Type: application/json"
The response includes information about all built-in and custom roles in the organization or enterprise associated with the provided application token.
From the response, copy the id for each custom role that you want to delete.
Use DELETE /v2/organizations/roles/ROLE_ID to delete a role, specified by its ID:
curl -sS -L -X DELETE "https://api.astra.datastax.com/v2/organizations/roles/ROLE_ID" \ --header "Authorization: Bearer APPLICATION_TOKEN" \ --header "Content-Type: application/json"
Use the same application token that you used with GET /v2/organizations/roles.

A successful request returns 204 No Content.
Optional: To verify that the role was deleted, use GET /v2/organizations/roles/ROLE_ID.

Manage custom roles

Prerequisites

Inspect roles

Inspect roles in the Astra Portal

Inspect roles with the DevOps API

Create a custom role

Create a custom role in the Astra Portal

Create a custom role with the DevOps API

Resource scopes

Define resource scopes in the Astra Portal

Define resource scopes with the DevOps API

Unresolved organization ID or enterprise ID in resource scopes

Resource scope examples

Additional custom role policy examples

Troubleshoot custom role resource scopes

Edit a custom role

Delete a custom role

See also

Was this helpful?

Give Feedback