importCredentialsSecret not properly working with Topology Operator

[headyj]

Hi there,

I'm trying to create a user using the Topology Operator:

apiVersion: rabbitmq.com/v1beta1
kind: User
metadata:
  name: {{ .Release.Namespace }}
  namespace: rabbitmq
spec:
  importCredentialsSecret:
    name: rabbitmq-credentials
  rabbitmqClusterReference:
    name: rabbitmq

The provided importCredentialsSecret is created in the same Chart by External Secrets and is applied through ArgoCD.

Even though the secret is present (it's created before the User thanks to argo sync-wave feature), it seems that the operator doesn't respect the importCredentials secret, because I can see that it's creating it's own secret beside mine:

kubectl get secret -n rabbitmq
NAME                                                  TYPE                                  DATA   AGE
rabbitmq-credentials                      Opaque                                2      17h
user-credentials                          Opaque                                2      17h

The correct authentication is then the generated user-credentials instead of the provided ones. If I remove the user, it is then created again but this time with my provided credentials.

Is there anything I'm doing wrong in this process?

[headyj]

I can confirm that even a simple example like that is still creating 2 secrets:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: test-user-1
  namespace: rabbitmq
stringData:
  username: test-user-1
  password: password-user-1
---
apiVersion: rabbitmq.com/v1beta1
kind: User
metadata:
  name: test-user-1
  namespace: rabbitmq
spec:
  rabbitmqClusterReference:
    name: rabbitmq
  importCredentialsSecret:
    name: test-user-1
EOF

$ kubectl get secret -n rabbitmq
NAME                                            TYPE                                  DATA   AGE
test-user-1                                     Opaque                                2      3m22s
test-user-1-user-credentials                    Opaque                                2      3m22s

[GorginZ]

Hi I am hitting this same issue. I want to manage my rabbit users' usernames and passwords using CSI secret driver as per SecOps teams preferences, however my heart sank when I saw the secret is duplicated... I haven't tried playing around with removing the duplicate secret to see if it upsets anything but I'd be pretty hesitant to do so.

Did you make any progress?

In my case I am providing the secret like so as per documentation:
(In this instance I just do a straight k apply as I was trying out the import secret functionality, obviously that's not my actual base64 value)

apiVersion: v1
kind: Secret
metadata:
  name: myapp-rabbitmq-app-user-secret
  labels:
    app: myapp-rabbitmq
data:
  username: Y2l0YWRlbHVzZXIK
  passwordHash: MYCOOLSECRET

And my user references the secret (deployed via extraDeploys in the chart)

  - apiVersion: rabbitmq.com/v1beta1
    kind: User
    metadata:
      name: myapp-rabbitmq
      labels:
        app: myapp-rabbitmq
    spec:
      rabbitmqClusterReference: 
        name: myapp-rabbitmq
      importCredentialsSecret:
        name: myapp-rabbitmq-app-user-secret

and I end up with a duplicate also:
The top myapp-rabbitmq-app-user-secret result being my secret created by me, and the myapp-rabbitmq-user-credentials is generated upon the creation of the user object

➜  cts k get secret
NAME                                                   TYPE                             DATA   AGE
myapp-rabbitmq-app-user-secret                       Opaque                           2      4d21h
myapp-rabbitmq-default-user                          Opaque                           8      4d22h
myapp-rabbitmq-erlang-cookie                         Opaque                           1      4d22h
myapp-rabbitmq-user-credentials                      Opaque                           2      4d21h

When I view the contents of the generated myapp-rabbitmq-user-credentials it is identical to my myapp-rabbitmq-app-user-secret secret.

Furthermore I have noticed that I can not get a permission working for any user I create using the importCredentialsSecret method. I have no problems assigning permissions to a user created where I allow the topology operator to generate a username and password for me, however. I may raise an issue regarding this separate issue, but will raise it here in case you also encountered this.

[Danh4]

I came across this issue as whilst working on a deployment my external-secrets operator was only refreshing every hour, so to speed things up I removed the secrets. The "imported" version of the secret is not recreated once the external-secrets version of the secret is recreated.