[feat]: Right Click - Create Super User

[millerjp]

We want to make it easy to create a Cassandra DB super user (should be done after #681

1 - Right Click on:

Permissions
Permissions > Users
Permissions > Users > Super Users

2 - Dialog pops up with a information message and prompt for username, password or hashed password

3 - Info message in Dialog should say

⚠️ Important Notice
A Cassandra superuser requires QUORUM consistency level for authentication and authorization, which can cause significant performance degradation, especially in multi-datacenter environments. This superuser should only be used once to bootstrap your initial security configuration. It is reccomended to create DBA users and regular users for typical usage and not use superusers.

5 - CQL Syntax to create a super user

-- Standard Password
CREATE ROLE admin_user WITH SUPERUSER = true AND LOGIN = true 
AND PASSWORD = 'strong_password';

-- Hashed Password
CREATE ROLE admin_user WITH SUPERUSER = true AND LOGIN = true 
AND HASHED PASSWORD = '$2a$10$F5pRau9mKg5abP.DsuPQl.8rQpEoNm3OV91mKjb9vdKPUPejIPq/u';

6 - If the user wants to use a hashed password, we need to give them the ability to enter the hash if they have it already OR generate the hashed password.

This is a bcrypt hash and can be generated by workbench locally. Cassandra bundles a hash password tool when you install it (https://github.com/apache/cassandra/blob/57e5cdfb59485d70f6b340987957fa4301233e8c/tools/bin/hash_password), however this is a Java app (https://github.com/apache/cassandra/blob/57e5cdfb59485d70f6b340987957fa4301233e8c/src/java/org/apache/cassandra/tools/HashPassword.java#L39) so is not compatible with Workbench. We will need to replicate this in our CQLSH bundled and implement in Python.
For example, but double check the Java implementation as there may be other things in there. We will have to test this carefully, but I think it should be fine as its just bcrypt with a number of rounds.

import sys
import bcrypt

def hash_password(password: str, rounds: int = 10) -> str:
    """
    Given a plain-text password, returns a bcrypt hash with the specified cost factor.
    """
    salt = bcrypt.gensalt(rounds=rounds)
    hashed = bcrypt.hashpw(password.encode('utf-8'), salt)
    return hashed.decode('utf-8')

if __name__ == "__main__":
    if len(sys.argv) < 2:
        print("Usage: python hash_password.py <plaintext_password> [rounds]")
        sys.exit(1)

    password_arg = sys.argv[1]
    rounds_arg = int(sys.argv[2]) if len(sys.argv) > 2 else 10

    hashed_pw = hash_password(password_arg, rounds_arg)
    print(f"Hashed password: {hashed_pw}")

Allow users to click a "Generate Hashed Password" which converts the password they have entered in the password field, hashes it and them make it visible so they can see it.

7 - Add a copy User Credentials to clipboard button

When the users have entered the user/password (or generated the hashed password) have a copy button that copies the credentials to their clipboard in the format

user: <username>
password: <password entered or hashed password>

Additional Security Options for users

Data Center Access Control

In Cassandra 4.0+ you can restrict users access to only be via certain data centers. We need to support this optional restriction in the UX with an info message saying

DC-level access control requires cluster configuration. Verify network_authorizer is properly configured in cassandra.yaml before proceeding otherwise this may have no effect.

-- All DCs
CREATE ROLE dba_user WITH LOGIN = true AND SUPERUSER = false
AND PASSWORD = 'strong_password' AND ACCESS TO ALL DATACENTERS; 

-- Specific DCs
CREATE ROLE dba_user WITH LOGIN = true AND SUPERUSER = false
AND PASSWORD = 'strong_password' AND ACCESS TO DATACENTERS {'DC1', 'DC3'};

We should allow users to select all the DCs or just specific DCs in the cluster and populate the generated CQL with the DC names.

CIDR Access Control in Cassandra 5.0+ only

In Cassandra 5.0+ you can restrict users access to only be via CIDR ranges. See: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-33%3A+CIDR+filtering+authorizer

We need to support this optional restriction in the UX with an info message saying

CIDR access control requires cluster configuration to be enabled and cidr groups to be created before assigning to users. 

-- All CIDR Groups
CREATE ROLE dba_user WITH LOGIN = true AND SUPERUSER = false
AND PASSWORD = 'strong_password' AND ACCESS FROM ALL CIDRS

-- Specific CIDR Groups
CREATE ROLE dba_user WITH LOGIN = true AND SUPERUSER = false
AND PASSWORD = 'strong_password' AND ACCESS FROM CIDRS { 'region1', 'region2' };

We should allow users to select all the CIDRS or just specific groups that exist in the cluster and populate the generated CQL with the DC names.

In terms of getting the existing CIDR groups, I am not sure - we just have to let them enter the text rather than select the groups.

[digiserg]

I'm not sure I see the point of using hash passwords. When would you use it?

[millerjp]

@digiserg Pretty good feature https://cassandra.apache.org/_/blog/Apache-Cassandra-4.1-Features-Client-side-Password-Hashing.html. There a bunch of security benefits to doing this

Prevention of Plain Text Exposure

Prior to version 4.1, passwords were provided in plain text, which created potential security risks when audit logging stored credentials without encryption

Protection Against Logging Vulnerabilities

While Cassandra implemented logging sanitization for sensitive information, some corner cases could still potentially expose credentials. The new hashing feature ensures that even if logging sanitization fails, only password hashes are exposed rather than plain text passwords

Enhanced Application Security

Services and applications that need to store user credentials can now store password hashes instead of plain text, significantly reducing security risks