Configure OpsCenter role-based security

In OpsCenter you can enable user authentication, define custom roles, manage users, and designate permissions.

By default, access control is disabled. Any user that knows the OpsCenter URL can view all objects and perform all tasks.

In DataStax Enterprise (DSE), you can define custom, fine-grained roles for database access with various authentication methods. Similarly, OpsCenter supports multiple authentication methods and role-based access control (RBAC). Permissions are granted to roles, and then roles are assigned to users.

For most authentication methods, a user can only be assigned one role, and each role applies to all clusters. For LDAP authentication, users can have multiple roles with cumulative permissions.

To use single-sign on (SSO) with OpsCenter, you must use OIDC/OAuth 2.0 for authentication.

Admin role privileges

The admin role is built-in to OpsCenter and cannot be edited or removed. By default, the admin role is the only role created automatically when authentication is enabled. Only users with the admin role can manage users and roles, add new clusters, or manually update definition files.

Changing the default admin password is strongly recommended the first time you log in.

Custom user role privileges

Only those assigned an admin role can manage roles. Each role represents permissions for all clusters managed by OpsCenter. Any functionality in OpsCenter that a user does not have permission for appears as gray and unavailable to that logged in user.

If using the OpsCenter API, users without sufficient permissions will receive an HTTP 401, Unauthorized response from the API.

Adding a cluster does not automatically add permissions for any existing roles. After adding a cluster, apply the permissions to the cluster for each role as appropriate for your organization.

In OpsCenter 6.5.3 and later, you must update custom scripts and applications that use the OpsCenter API if you want to use multiple user roles with LDAP authentication. If a custom script or application that uses the OpsCenter API did not account for multiple user roles, and a user has multiple roles, the script or application will fail because the role attribute cannot be found. The single role attribute will be provided for users that have only one role. If your application or script has users with only one role, then updates are not required for continued use.

Role permissions

Permissions grant access to specific functionality in OpsCenter. When you create or edit a role, you select the permissions that are granted to the role.

Use the Cluster menu to view permissions for each cluster for a selected role. To hide a cluster for users within a selected role, clear the checkboxes for all permissions.

opscAddRole

Core functionality permissions
  • View Cluster: Allows users to view a cluster in the Clusters area of the OpsCenter Monitoring UI.

  • Install Agents: Allows users to install or upgrade agents automatically or manually.

  • Edit Connection Settings: Allows users to edit the cluster connection settings for a DSE cluster monitored in OpsCenter.

  • Manage Alerts: Allows users to add alerts for monitoring conditions in DSE clusters.

  • Cluster Configuration: Allows users to configure the Performance Service.

Services permissions
  • Backup Service: Allows users to perform backups and restores.

  • Best Practice Service: Allows users to configure and schedule Best Practice Service rules for managing DSE clusters.

  • Repair Service: Allows users to start, stop, and configure the Repair Service for running repairs on DSE clusters.

  • NodeSync Service: Allows authorized users to access status and configure settings for the NodeSync Service.

  • Performance Service: Allows users to configure the Performance Service.

  • Performance Service CQL Tracing: Allows users to trace slow CQL queries when troubleshooting query issues.

Node operations permissions
  • Start and Stop: Allows users to start and stop DSE nodes. Start and stop nodes from the Other Actions menu options available in the List view, or from the Actions menu in the Node Details view.

  • Cleanup: Allows users to run a cleanup on one or more keyspaces.

  • Compact: Allows users to run compaction on a keyspaces and their tables. Major compactions are not recommended unless there is a compelling reason to do so.

  • Drain: Allows users to drain a node. The Drain option is available from the Actions menu in the Node Details dialog view, and also available when restarting DSE on a node.

  • Flush: Allows users to flush a keyspace and its tables. Flushing a keyspace might affect system performance when there are many live, large memtables.

  • Garbage Collection: Allows users to perform garbage collection on nodes. Running GC causes a spike in latency.

  • Repair: Allows users to manually run an ad hoc repair operation on selected nodes in the List view.

Data permissions
  • View Schema: Allows users to view the CQL statements for the schema in the Data workspace of OpsCenter Monitoring. Users must have the View Schema permission to view Tables, View UDT, View UDF, and View UDA. Those users without view schema permission are shown a message explaining they must have the role permission for viewing anything in the Data workspace, and to contact their OpsCenter administrator to obtain access privileges.

  • Modify Schema: Allows users to edit keyspace settings, delete keyspaces, or delete tables in the Data workspace of OpsCenter.

  • Truncate Data: Allows users to truncate data from a table. The Truncate link appears as gray and unavailable for users who do not have this permission granted for their role.

Cluster topology permissions
  • Add Nodes: Deprecated. Instead, add nodes to an existing DSE cluster using Lifecycle Manager (LCM). Anyone assigned an admin role can use any feature of LCM.

  • Rebalance Cluster (non-vnode): Allows users to rebalance a non-vnode cluster. Not applicable to vnodes.

  • Move: Allows users to move a node, enter a new token, and assign the new token to the node. During a move node operation, the node is unavailable and cluster performance might be affected. Not applicable to vnodes. Access the Move option from the Other Actions menu available in the List view, or from the Actions menu in the Node Details dialog view.

  • Decommission: Allows users to decommission a node from the Actions menu in the Node Details dialog view.

  • Remove Tokens: Allows removing tokens using the APIs.

Enable authentication in OpsCenter

OpsCenter offers granular, role-based permission control for user and role management. By default, authentication is disabled. The first time authentication is enabled, a default admin account is created with username admin and password admin.

If you enable OpsCenter authentication, DataStax strongly recommends enabling SSL communication between OpsCenter and the agents.

OpsCenter allows you to build your own authentication connectors to third-party authentication systems. Use the resources in your OpsCenter auth directory, which is at /usr/share/opscenter/auth for package installations, or at INSTALL_DIRECTORY/opscenter/auth for tarball installations. The API documentation is located at auth/opscenter-auth-docs-opscenter_version.tgz, and the Framework SDK JAR file is located at auth/opscenter-auth-api-opscenter_version.jar.

  1. Edit the opscenterd.conf file. The location of this file depends on the type of installation:

    • Package installations: /etc/opscenter/opscenterd.conf

    • Tarball installations: INSTALL_DIRECTORY/conf/opscenterd.conf

  2. Enable authentication by setting enabled=True in the [authentication] section:

    [authentication]
    enabled=True
  3. Before you restart OpsCenter, delete the old database file, and then set the path to its location in the opscenterd.conf file. OpsCenter creates a new database file when it restarts.

  4. Log in with the admin role.

  5. Restart OpsCenter.

  6. Open the OpsCenter user interface in a browser by navigating to http://localhost:8888.

  7. Enter the default username of admin and the password admin.

    If you enable authentication together with pluggable authentication, the default username and password depends on the pluggable authentication configuration.

    If the admin role uses the default credentials, change the password immediately after logging in.

Set up pluggable authentication for OpsCenter

Configure pluggable authentication in the opscenterd.conf file. The location of this file depends on the type of installation:

  • Package installations: /etc/opscenter/opscenterd.conf

  • Tarball installations: INSTALL_DIRECTORY/conf/opscenterd.conf

The required configuration depends on your preferred authentication strategy:

File authentication strategy
  1. Create the auth_file with user:password:role and one user per line:

    user:$2a$1...wrzmYhmO:superuser

    The password must use a bcrypt 2a variation hash.

    For successful authentication, you must create all roles specified in the auth_file in DSE OpsCenter. The DSE OpsCenter role names must match the role names specified in the auth_file. To avoid authentication issues, it is recommended that you enable default authentication, create the roles, and then enable pluggable authentication with an auth_file.

  2. Set the path to your authentication file in the opscenterd.conf file:

    password_db = ./passwd.db
    enabled = True
    authentication_method = com.datastax.opscenter.auth.http.impl.FileAuthenticationStrategyProvider
    
    [authentication_provider]
    # auth file configuration
    auth_file = /apps/test/auth.txt
  3. Restart OpsCenter.

  4. To test your configuration, navigate to the OpsCenter UI at http://localhost:8888, and then log in with the appropriate credentials.

LDAP authentication strategy

This strategy requires preparing an LDAP server, creating roles in DSE OpsCenter, and configuring the opscenterd.conf file accordingly. For more information and examples, see Authenticate OpsCenter users with LDAP.

password_db = ./passwd.db
enabled = True
authentication_method = com.datastax.opscenter.auth.http.impl.LDAPAuthenticationStrategyProvider

[authentication_provider]
# ldap configuration
server_host = dev-ldap.datastax.lan
# use 389 if you set ldap_security = None
server_port = 636
search_dn = cn=admin,dc=devldap,dc=datastax,dc=lan
search_password = dseng
user_search_base = ou=users,dc=devldap,dc=datastax,dc=lan
user_search_filter = (uid={0})
group_search_base = ou=groups,dc=devldap,dc=datastax,dc=lan
group_search_filter = (member=cn={0},ou=users,dc=devldap,dc=datastax,dc=lan)
group_name_attribute = cn
admin_group_name = superusers, superusers2
truststore = ./tests/resources/truststore.ts
truststore_pass = secret
ldap_security = SSL_TLS
truststore_type = jks
OIDC/OAuth 2.0 authentication strategy

Use this strategy to delegate authentication to an OpenID Connect (OIDC) or OAuth 2.0 provider such as Keycloak, Okta, or Microsoft Entra ID (Azure AD). For more information, see Configure OpenID Connect (OIDC)/OAuth 2.0 authentication in OpsCenter.

Bring your own class

To use your own pluggable authentication class, define it in the authentication_method in opscenterd.conf, and then restart OpsCenter.

To test your configuration, navigate to the OpsCenter UI at http://localhost:8888, and then log in with the appropriate credentials.

Multiple authentication strategy

You can implement multiple authentication strategies on one cluster:

password_db = ./passwd.db
enabled = True
authentication_method = com.datastax.opscenter.auth.http.impl.MultipleAuthenticationStrategyProvider

[authentication_provider]
# List of authentication strategies in the order each strategy will be used
strategy_chain = com.datastax.opscenter.auth.http.impl.FileAuthenticationStrategyProvider, com.datastax.opscenter.auth.http.impl.LDAPAuthenticationStrategyProvider

# auth file configuration
auth_file = /apps/test/auth.txt

# ldap configuration, formerly in [ldap_section]
server_host = dev-ldap.datastax.lan
# use 389 if you set ldap_security = None
server_port = 636
search_dn = cn=admin,dc=devldap,dc=datastax,dc=lan
search_password = dseng
user_search_base = ou=users,dc=devldap,dc=datastax,dc=lan
user_search_filter = (uid={0})
group_search_base = ou=groups,dc=devldap,dc=datastax,dc=lan
group_search_filter = (member=cn={0},ou=users,dc=devldap,dc=datastax,dc=lan)
group_name_attribute = cn
admin_group_name = superusers, superusers2
truststore = ./tests/resources/truststore.ts
truststore_pass = secret
ldap_security = SSL_TLS
truststore_type = jks

Grant permission when role-based access control is enabled

When Cassandra role-based access control (RBAC) is enabled, a default account is created with username cassandra and password cassandra. Create additional roles with permissions for the OpsCenter cluster and the monitored DataStax Enterprise (DSE) cluster. The Cassandra role used for the agent should have ALL permissions for the OpsCenter keyspace, as well as DESCRIBE and SELECT for the monitored DSE cluster.

Use the following examples to create any roles necessary for your clusters:

  • Create opscenter role with SELECT permissions for the monitored DSE cluster:

    CREATE ROLE opscenter WITH PASSWORD = 'opscenter' AND SUPERUSER = false AND LOGIN = true;
    GRANT SELECT ON TABLE system.local TO opscenter;
    GRANT SELECT ON TABLE system.peers TO opscenter;
  • Create agent role with SELECT permissions for the monitored DSE cluster:

    CREATE ROLE agent WITH PASSWORD = agent AND SUPERUSER = false AND LOGIN = true;
    GRANT SELECT ON TABLE system.local TO agent;
    GRANT SELECT ON TABLE system.peers TO agent;
    GRANT SELECT ON TABLE dse_perf.node_slow_log TO agent;
  • Create opscenter role with ALL permissions for an OpsCenter keyspace in the monitored DSE cluster:

    CREATE ROLE opscenter WITH PASSWORD = 'opscenter' AND SUPERUSER = false AND LOGIN = true;
    GRANT ALL ON KEYSPACE opscenter_keyspace TO opscenter;
  • Create opscenter role with ALL permissions for a separate OpsCenter storage cluster:

    CREATE ROLE agent WITH PASSWORD = agent AND SUPERUSER = false AND LOGIN = true;
    GRANT ALL ON KEYSPACE opscenter_keyspace TO agent;
  • If you plan to enable or disable NodeSync for specific tables using DSE OpsCenter NodeSync Service, grant the opscenter role with ALTER permissions for those tables:

    GRANT ALTER ON TABLE keyspace_name.table_name TO opscenter;
  • Custom roles for DSE 6.8:

    • To allow OpsCenter to restore DSE Graphs for DSE 6.8, grant the opscenter role with UPDATE, SELECT, and ALTER permissions for dse_system.shared_data:

      GRANT UPDATE, SELECT, ALTER ON TABLE dse_system.shared_data TO opscenter;
    • For DSE 6.8 Search clusters, grant the agent role with SELECT and UPDATE permissions for solr_admin.solr_resources:

      GRANT SELECT, UPDATE ON TABLE solr_admin.solr_resources TO agent;
  • Custom roles for DSE 6.7 and earlier:

    • To allow OpsCenter to restore DSE Graphs for DSE 6.7 and earlier, grant the opscenter role with MODIFY, SELECT, and ALTER permissions for dse_system.shared_data:

      GRANT MODIFY, SELECT, ALTER ON TABLE dse_system.shared_data TO opscenter;
    • For DSE 6.7 and earlier Search clusters, grant the agent role with SELECT and MODIFY permissions for solr_admin.solr_resources:

      GRANT SELECT, MODIFY ON TABLE solr_admin.solr_resources TO agent;

Sign in and out using OpsCenter authentication

If OpsCenter authentication is enabled, follow these instructions to log in and out of OpsCenter. These steps also explain how to change the default admin password.

  1. Go to the main OpsCenter URL in a web browser: http://localhost:8888.

  2. On the sign in page, enter your username and password.

    The default admin username is admin and the default admin password is admin.

  3. To change the default admin password, do the following:

    1. Click the admin username in the header, and then select Change Password.

    2. Enter the current password (admin), and then enter the new password twice.

    3. Click Save.

  4. Click Close.

  5. To sign out, click your username in the header, and then select Log Out.

Manage users and roles

When LDAP authentication is enabled, adding and editing users is disabled. Only role editing is available when LDAP is enabled.

To manage users and roles permissions in OpsCenter, sign in to OpsCenter as an admin, click Settings, and then select Users & Roles. Then edit users and roles as needed.

All changes to roles and permissions are logged for security auditing purposes.

Add a user
  1. Click Add User.

  2. Enter the username and password, and select a role for the user.

  3. Click Save.

Edit a user
  1. Click the Edit icon for the user you want to edit.

  2. To change the user’s password, enter and confirm the new password, then click Save.

  3. To change the user’s role, select the new role from the Roles list and click Save.

Delete a user

Click the Delete icon for the user you want to delete, and then click Delete to confirm.

Edit a role
  1. Click Manage Roles.

  2. Click the Edit icon for the role you want to edit.

  3. Select the cluster to apply role permissions to. The first cluster that a role has permissions for is automatically selected in the Cluster list.

  4. Select the options the user role has permissions for. To hide a cluster for users within a selected role, clear the checkboxes for all permissions. Click Select All or Unselect All to quickly enable all or no permissions.

  5. Click Save.

  6. To apply role permissions for each cluster, repeat the preceding steps for each applicable cluster.

Add a role and assign it to users
  1. Click Manage Roles.

  2. Click Add Role.

  3. Enter the name of the role in Role Name, select the permissions from the appropriate feature check boxes, and then click Save. By default, new roles do not have any permissions.

  4. Edit the role to apply permissions for each cluster.

  5. In the Users dialog, click the Edit icon for the user that you want to grant the role to.

  6. In the Role list, select the role, and click Save.

Delete a role

Click Manage Roles, select the role you want to delete, and then click the Delete icon.

Change the location of the password database

Change the default location of the password database passwd.db used for OpsCenter authentication if you prefer another location. The password database is created when authentication is enabled.

If you have already enabled authentication, copy the existing passwd.db file to the new location. If you do not copy the password database to the new location, OpsCenter creates a new password database in the specified location when it is started. Existing users and roles are lost.

The default location of passwd.db depends on the type of installation. For package installations, it is located in /etc/opscenter/passwd.db, and for tarball installations, it is located in INSTALL_DIRECTORY/passwd.db.

Your organization is responsible for backing up the password_db database. You must also configure failover to mirror the password_db if your organization has failover enabled.

  1. Edit the opscenterd.conf file, which is located at /etc/opscenter/opscenterd.conf for package installations and at INSTALL_DIRECTORY/conf/opscenterd.conf for tarball installations.

  2. In the [authentication] section, set password_db to the new location of the password database:

    [authentication]
    password_db = path/to/new/password/database
  3. Restart OpsCenter.

Configure the user password hash algorithm

Configure the algorithm to hash user passwords OpsCenter authentication. The default algorithm is bcrypt+blake2b-512.

  1. Edit the opscenterd.conf file, which is located at /etc/opscenter/opscenterd.conf for package installations and at INSTALL_DIRECTORY/conf/opscenterd.conf for tarball installations.

  2. In the [authentication] section, set password_hash_type to the desired hashing option:

    [authentication]
    password_hash_type = pbkdf2+sha3-256

    Available password_hash_type options include the following:

    • bcrypt+blake2b-512

    • pbkdf2+blake2b-512

    • pbkdf2+sha512

    • pbkdf2+sha3-256

    • bcrypt+sha512

  3. Restart OpsCenter.

  4. Instruct users to sign in again so that OpsCenter can rehash and restore the user passwords. Because password hash algorithms are one-way functions that cannot be reversed, signing in again is necessary to update previously hashed user passwords.

Was this helpful?

Give Feedback

How can we improve the documentation?

© Copyright IBM Corporation 2026 | Privacy policy | Terms of use |  Manage Privacy Choices

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: Contact IBM