Cass-operator is unable to delete Users in Cassandra

[kos-team]

What happened?

We want to delete a user that we previously created through the spec.users property in the CRD. However, by removing the user entry from the spec.users list, we found that the user still exist in the Cassandra system.

What did you expect to happen?

There are two right behaviors in this case, depending how much feature this operator wants to support:

1. Make the operator to manage the list of users that it creates. When a user is removed from the CR, it should be deleted from the Cassandra cluster.
2. Make the spec.users an immutable field. This can be done easily with the x-kubernetes-validation CRD feature.

How can we reproduce it (as minimally and precisely as possible)?

1. Deploy the cass-operator
2. Create two secrets for the Cassandra users:

apiVersion: v1
kind: Secret
metadata:
  name: demo-secret
type: Opaque
data:
  username: YWRtaW4=
  password: cGFzc3dvcmQ=
---
apiVersion: v1
kind: Secret
metadata:
  name: demo-secret-2
type: Opaque
data:
  username: YWRtaW4y
  password: cGFzc3dvcmQ=

1. Deploy CassandraDB with the following CR yaml

apiVersion: cassandra.datastax.com/v1beta1
kind: CassandraDatacenter
metadata:
  name: test-cluster
spec:
  clusterName: development
  serverType: cassandra
  serverVersion: "4.1.2"
  managementApiAuth:
    insecure: {}
  size: 3
  storageConfig:
    cassandraDataVolumeClaimSpec:
      storageClassName: standard
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 10Gi
  racks:
    - name: rack1
  config:
    jvm-server-options:
      initial_heap_size: "1G"
      max_heap_size: "1G"
    cassandra-yaml:
      num_tokens: 16
      authenticator: PasswordAuthenticator
      authorizer: CassandraAuthorizer
      role_manager: CassandraRoleManager
  users:
  - secretName: demo-secret
    superuser: true
  - secretName: demo-secret-2
    superuser: false

1. Delete the demo-secret-2 user from the spec.users:

apiVersion: cassandra.datastax.com/v1beta1
kind: CassandraDatacenter
metadata:
  name: test-cluster
spec:
  clusterName: development
  serverType: cassandra
  serverVersion: "4.1.2"
  managementApiAuth:
    insecure: {}
  size: 3
  storageConfig:
    cassandraDataVolumeClaimSpec:
      storageClassName: standard
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 10Gi
  racks:
    - name: rack1
  config:
    jvm-server-options:
      initial_heap_size: "1G"
      max_heap_size: "1G"
    cassandra-yaml:
      num_tokens: 16
      authenticator: PasswordAuthenticator
      authorizer: CassandraAuthorizer
      role_manager: CassandraRoleManager
  users:
  - secretName: demo-secret
    superuser: true

1. Observe the list of users by running LIST USERS in cqlsh:

 name                  | super  | datacenters
-----------------------+--------+-------------
 development-superuser |  True  |         ALL
 admin                 |  True  |         ALL
 admin-2               |  False |        ALL

cass-operator version

1.22.0

Kubernetes version

1.28.0

Method of installation

Helm

Anything else we need to know?

No response

┆Issue is synchronized with this Jira Story by Unito ┆Issue Number: CASS-3

[burmanm]

Right now the functionality is as intended. The users / superusers feature is intended to only enforce that those users set there are existing in the cluster (or if using an annotation, this feature can be disabled for the Datacenter), but not that they're the only users in the cluster.

Since users can add new users by using other means in Cassandra, we can't delete them even if they're removed from this list as this isn't intended to be the user management alone.

This could be viewed as enhancement for future behavior however. There's a different PR (albeit slightly delayed one) that would modify the user creation process to make it better.

[kos-team]

Got it, thanks for the explanation! Perhaps making the property immutable would avoid the confusion?

[burmanm]

Sadly making it immutable could prevent adding another dc which controls the username creation. And it wouldn't solve the issue really, you could still modify the Secret itself (which is user controller so we can't make it immutable) to change the username.