Changing scramCredentialsSecretName causes resource leak

[hoyhbx]

What did you do to encounter the bug?
I changed the scramCredentialsSecretName for the same user which created a new scramCredentialsSecret for the same password. The old scramCredentialsSecret is not deleted.

Steps to reproduce the behavior:

1. Apply the following configuration to create a user with scramCredentialSecret named my-scram:

spec:
  members: 3
  type: ReplicaSet
  users:
  - db: admin
    name: my-user
    passwordSecretRef:
      name: my-user-password
    roles:
    - db: admin
      name: clusterAdmin
    - db: admin
      name: userAdminAnyDatabase
    scramCredentialsSecretName: my-scram
  version: 4.4.0

2. Change the scramCredentialsSecretName to anything else:

scramCredentialsSecretName: xyzabc

What did you expect?
The operator should delete the old scramCredentialsSecret for the user if a new secret is created.

What happened instead?
The operator creates a new secret with a new name but the old secret is not deleted.

Operator Information

• Operator Version - 0.7.3
• MongoDB Image used - 4.4.0

Kubernetes Cluster Information

kubectl version --short --output=yaml

$ kubectl version --short --output=yaml
clientVersion:
  buildDate: "2022-05-24T12:26:19Z"
  compiler: gc
  gitCommit: 3ddd0f45aa91e2f30c70734b175631bec5b5825a
  gitTreeState: clean
  gitVersion: v1.24.1
  goVersion: go1.18.2
  major: "1"
  minor: "24"
  platform: linux/amd64
kustomizeVersion: v4.5.4
serverVersion:
  buildDate: "2021-05-21T23:01:33Z"
  compiler: gc
  gitCommit: 5e58841cce77d4bc13713ad2b91fa0d961e69192
  gitTreeState: clean
  gitVersion: v1.21.1
  goVersion: go1.16.4
  major: "1"
  minor: "21"
  platform: linux/amd64

Additional context

• secrets

It can be observed below that xyzabc-scram-credentials has been created in addition to my-scram-scram-credentials.

NAME                                           TYPE                                  DATA   AGE
default-token-mmlhr                            kubernetes.io/service-account-token   3      9h
mongodb-database-token-ll4pw                   kubernetes.io/service-account-token   3      9h
mongodb-kubernetes-operator-token-pn5cz        kubernetes.io/service-account-token   3      9h
mongodb-test-cluster-admin-my-user             Opaque                                4      9h
mongodb-test-cluster-agent-password            Opaque                                1      9h
mongodb-test-cluster-config                    Opaque                                1      9h
mongodb-test-cluster-keyfile                   Opaque                                1      9h
my-scram-scram-credentials                     Opaque                                6      9h
my-user-password                               Opaque                                1      9h
xyzabc-scram-credentials                       Opaque                                6      3s

Possible root cause and fix

We need some way of identifying a scram credentials secret by the user it was created for.

A naive solution would be to include some information about the user in the secret metadata so that the operator can delete the old secret if it already exists for a user before creating a new one.

[github-actions]

This issue is being marked stale because it has been open for 60 days with no activity. Please comment if this issue is still affecting you. If there is no change, this issue will be closed in 30 days.

[hoyhbx]

Remove stale

[github-actions]

This issue is being marked stale because it has been open for 60 days with no activity. Please comment if this issue is still affecting you. If there is no change, this issue will be closed in 30 days.

[dan-mckean]

Hi, I'm Dan and I'm the Product Manager for MongoDB's support of Kubernetes.

I'm doing some work right now to try and identify how the Community Operator is being used. The Community Operator is something I inherited when I started at MongoDB, but it doesn't get as much attention from us as we'd like and we're trying to understand how it's used in order to establish its future. It will help us prioritize future issues and PRs raised by the community 🙂

Here's a super short survey (it's much easier for us to review all the feedback that way!): https://docs.google.com/forms/d/e/1FAIpQLSfwrwyxBSlUyJ6AmC-eYlgW_3JEdfA48SB2i5--_WpiynMW2w/viewform?usp=sf_link

If you'd rather email me instead: [email protected]

Thank you in advance!
Dan