Configuring OpsCenter role-based security

OpsCenter allows enabling user authentication, defining custom roles, managing users, and designating permissions.

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

OpsCenter access roles overview

DataStax Enterprise (DSE) customers have the ability to define custom, fine-grained access roles for their users. OpsCenter can be configured to require users to log in using OpsCenter authentication. Permissions to perform certain operations can be granted to each role, and a role can be assigned to users. A user can only be assigned one role, and each role applies to all clusters.

Authenticating with LDAP in OpsCenter requires defining roles for LDAP users. If using LDAP authentication, users can have multiple roles. Upon logging in, all permissions for each role a user is assigned to are merged.

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

When defining custom roles, each role can have specific permissions enabled for that role. Each user can only be assigned a single role, which contains permissions for all clusters managed by OpsCenter. If using LDAP authentication, users can have multiple roles. Use the Cluster menu to view permissions for each cluster for a selected role. To hide a cluster for users within a selected role, uncheck all permissions.

opscAddRole

Permission Description

Core functionality

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

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 Configuration

Allows users to configure the Performance Service.

Performance Service CQL Tracing

Allows users to trace slow CQL queries when troubleshooting query issues.

Node Operations

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

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

Add Nodes

Deprecated. Now users add nodes to an existing DSE cluster using Lifecycle Manager. 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.

Enabling authentication in OpsCenter

About this task

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.

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

OpsCenter allows you to build your own authentication connectors to third-party authentication systems. Use the resources in the auth directory of your OpsCenter server installation:

  • API documentation: opscenter-auth-docs-opscenter_version.tgz

  • Framework SDK JAR file: opscenter-auth-api-opscenter_version.jar

The location of the auth directory depends on the type of installation:

  • Package installations: /usr/share/opscenter/auth

  • Tarball installations: installation_location/opscenter/auth

Procedure

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

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

    • Tarball installations: install_location/conf/opscenterd.conf

  2. Edit the opscenterd.conf file and enable authentication.

    Set enabled=True in the [authentication] section.

    [authentication]
enabled=True

  3. Restart OpsCenter.

  4. Open the OpsCenter user interface in a browser.

    http://localhost:8888

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

    If pluggable authentication is enabled, the default username and password will vary based on the information used when pluggable authentication was enabled.

Setting up pluggable authentication for OpsCenter

Procedure

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

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

    • Tarball installations: install_location/conf/opscenterd.conf

  2. Edit the opscenterd.conf file and enable authentication.

    You can also bring your own pluggable authentication class and define it in the authentication_method.

    File authentication strategy

    Create the auth_file with user:password:role:

    user:$2a$10$LvCn7Qm8SjkIUfRN3ZBWSuhH6KqmQPomnjcSkh2imkPVvwrzmYhmO:superuser

    The password must use a bcrypt 2a variation hash.

    You must first create the superuser role before creating the auth_file.

    The authentication file should contain one user per line in this format.

    		 
    passwd_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

    LDAP authentication strategy

    passwd_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

    Multiple authentication strategy

    passwd_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

  3. Restart OpsCenter.

  4. Open the OpsCenter user interface in a browser.

    http://localhost:8888

Granting permission when role-based access control is enabled

About this task

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 and DESCRIBE and SELECT for the monitored DSE cluster.

Procedure

  • 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;

    • 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 OpsCenter NodeSync Service, grant the opscenter role with ALTER permissions for those tables:

    GRANT ALTER ON TABLE keyspace_name.table_name TO opscenter;

  • To allow OpsCenter to restore DataStax 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;

  • To allow OpsCenter to restore DataStax 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.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;

  • 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;

Logging in and out using OpsCenter authentication

About this task

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

After changing the hash algorithm for the password_hash_type, instruct users to log in again so that OpsCenter can rehash and restore the user passwords. Because password hash algorithms are one-way functions that cannot be reversed, logging in again is necessary to update previously hashed user passwords.

Procedure

  1. Go to the main OpsCenter URL in a web browser.

    http://localhost:8888

  2. A login dialog appears. 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:

    1. Click the admin username on the upper right and select Change Password.

      opscAuthChangePW

    2. Enter the current password, enter the new password, confirm the new password, and click Save.

    3. The Password Updated dialog indicates the password has been updated. Click Close.

  4. Log out by clicking your username in the top navigation bar and clicking Log Out.

Managing users and roles

About this task

Follow these steps to manage users and roles permissions in OpsCenter.

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

  1. Log in to OpsCenter as an admin.

  2. Click Settings > Users & Roles. The Users and Roles dialog appears.

    opscAuthUsersRoles

    Add a user

    1. Click Add User. The Add User dialog appears.

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

    3. Click Save. Edit a user

    4. Click the Edit icon for the user you want to edit.

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

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

    7. Click the Delete icon for the user you want to delete and click Delete to confirm. Edit a role

    8. Click Manage Roles. The Manage Roles dialog appears.

    9. To edit an existing role, click the Edit icon. The Edit Role dialog appears.

    10. Select the cluster to apply role permissions to. The first cluster that a role has permissions for is automatically selected in the Cluster list of the Edit Role dialog.

    11. Select the options the user role has permissions for. To hide a cluster for users within a selected role, uncheck all permissions.

      Click Select All or Unselect All to quickly enable all or no permissions.

    12. Click Save.

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

    13. To apply role permissions for each cluster, repeat 2.a through 2.e. Add a role and assign it to users

    14. Click Add Role. The Add Role dialog appears.

    15. Enter the name of the role in Role Name, select the permissions from the appropriate feature check boxes, and click Save.

      By default, new roles do not have any permissions.

      Click Select All or Unselect All to quickly enable all or no permissions.

    16. Repeat as appropriate for each cluster.

    17. In the Users dialog, click the Edit icon for the user you want to add to the role.

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

    19. Edit the role to apply its permissions to each cluster as appropriate. Delete a role

    20. Select the role you want to delete in the Manage Roles dialog.

    21. Click the Delete icon.

Changing the location of the password database

About this task

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.

Change the location of the password database in the opscenterd.conf file.

The default location of passwd.db depends on the type of installation:

  • Package installations: /etc/opscenter/passwd.db

  • Tarball installations: install_location/passwd.db

Procedure

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

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

    • Tarball installations: install_location/conf/opscenterd.conf

  2. Edit the opscenterd.conf file and change the location of the password database.

    Set passwd_db to the new location in the [authentication] section.

    [authentication]
passwd_db = path to new password database

    • 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.

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

  3. Restart OpsCenter.

Configuring the user password hash algorithm

About this task

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

Available password_hash_type options include:

  • bcrypt+blake2b-512

  • pbkdf2+blake2b-512

  • pbkdf2+sha512

  • pbkdf2+sha3-256

  • bcrypt+sha512

Procedure

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

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

    • Tarball installations: install_location/conf/opscenterd.conf

  2. Open the opscenterd.conf file for editing.

    Set password_hash_type to the desired hashing option in the [authentication] section.

    [authentication]
password_hash_type = pbkdf2+sha3-256

  3. Restart OpsCenter.

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

Was this helpful?

Give Feedback

How can we improve the documentation?

© 2024 DataStax | Privacy policy | Terms of use

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: +1 (650) 389-6000, info@datastax.com