`failed setting controller reference` error when using a Secret generated by SealedSecret to create a RabbitMQ User

[AlbertoArconada]

Describe the bug

To avoid having base64 encoded credentials in my repos, I'm trying to use SealedSecrets to have encrypted credentials.
When a sealedsecret is applied, in the background this operator creates a secret in the same K8s namespace with the same name that contains Base64 encoded. Just for context, when generated, this secret contains some ownerReferences values.

Then, when I try to apply the template of a user that refers to that generated secret, I receive this error:
failed setting controller reference: Object namespace/name-of-the-secret is already owned by another SealedSecret controller name-of-the-sealed-secret

To Reproduce

Steps to reproduce the behavior:

1. Create a Secret template
2. Generate the sealed secret using kubeseal command
3. Apply the generated sealed secret
4. Create a User template whose importCredentialsSecret->name field points to the secret created in step 1
5. Apply the User template

Include any YAML or manifest necessary to reproduce the problem.

Cluster template

apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: my-rabbitmq-cluster
  namespace: my-rabbitmq-cluster-namespace
spec:
  replicas: 1

Secret template

apiVersion: v1
data:
  password: dGVzdHVzZXI=
  username: dGVzdHBhc3N3b3Jk
kind: Secret
metadata:
  name: test-user-credentials-secret
  namespace: my-rabbitmq-cluster-namespace
type: Opaque

User template

apiVersion: rabbitmq.com/v1beta1
kind: User
metadata:
  name: test-user
  namespace: my-rabbitmq-cluster-namespace
spec:
  tags:
    - management
  importCredentialsSecret:
    name: test-user-credentials-secret
  rabbitmqClusterReference:
    name: my-rabbitmq-cluster

Expected behavior

The User should be created without any problem using the Secret generated by SealedSecret Operator.

Screenshots

Version and environment information

• Messaging Topology Operator: bitnami/rmq-messaging-topology-operator:1.12.0-scratch-r0
• RabbitMQ: 3.12.4-management
• RabbitMQ Cluster Operator: bitnami/rabbitmq-cluster-operator:2.3.0-scratch-r1
• Kubernetes: v1.24.14
• Cloud provider or hardware configuration: Google Cloud

Additional context

[github-actions]

This issue has been marked as stale due to 60 days of inactivity. Stale issues will be closed after a further 30 days of inactivity; please remove the stale label in order to prevent this occurring.

[Zerpet]

hey, thank you for reporting this issue. I believe there's value in providing compatibility with sealed secrets. I've marked this issue as never-stale. However, I don't have time to get to this issue any time soon. A contribution would be very welcome 🙂

[MonicaMagoniCom]

I'm experiencing the same issue..

[VincBar]

I am having the same issue.

Is there any workaround, specifying a different sealed secret controller or something in that direction ?

Anything you tried and can recommend ?

[AlbertoArconada]

Hi @VincBar,
yes, we found a workaround to move forward. In our case, what we did was create our Sealed Secrets skipping set owner references using sealedsecrets.bitnami.com/skip-set-owner-references: "true" annotation (More info here).

Hope it can help...
Regards!

[VincBar]

HI @AlbertoArconada , thanks a lot for responding so quickly. The issue seems to still persist for us.

Rabbitmq application is already running and deployed including the user with argocd.

What I have done:

1. recreate the Secret, including the suggested annotation

   apiVersion: v1
   data:
     password: XXXX
     username: XXXX
   kind: Secret
   metadata:
     creationTimestamp: null
     name: XXX-user-user-credentials
     namespace: rabbitmq-cluster-dev
     annotations:
       sealedsecrets.bitnami.com/skip-set-owner-references: "true"
   type: Opaque
   

2. Selead it with our kubeseal controller, this results in:

   apiVersion: bitnami.com/v1alpha1
   kind: SealedSecret
   metadata:
     creationTimestamp: null
     name: XXX-user-user-credentials
     namespace: rabbitmq-cluster-dev
     annotations:
       sealedsecrets.bitnami.com/skip-set-owner-references: "true" 
   spec:
     encryptedData:
       password: XXX
       username: XXX
     template:
       metadata:
         annotations:
           sealedsecrets.bitnami.com/skip-set-owner-references: "true"
         creationTimestamp: null
         name: XXX-user-user-credentials
         namespace: rabbitmq-cluster-dev
       type: Opaque
   

3. Deployed on the cluster through argocd.

4. Deleted (with kubectl) the user that showed the issue

5. It was recreated by argocd with the same issue showing still

I can take a look at what versions we are using and look further into debugging, just wanted to check with you that this is the approach, that worked for you, or if I did misunderstand something.

[AlbertoArconada]

Hi @VincBar,
at the beginning it didn't work for us too and, it was because we were using a version of Sealed Secrets that didn't had this feature implemented. It was added on v0.22.0 (Release notes here) so, if your installed version is lower to that then it won't work.

Regards!

[Zerpet]

I just tested this use case, and it is perfectly possible and supported. There is one caveat: the secret must not be named as XXX-default-user, where XXX is the name of rabbitmqCluster resource. Cluster Operator names the default user secret following that pattern, and attempting to use kubeseal to create a secret with the same name is very likely to result in a similar error as described in the title.

I used the following YAML manifests:

secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: myuser-creds
  namespace: ns1
  labels:
    rabbitmq.com/topology-operator: "true"
data:
  username: dGVzdHVzZXI=
  password: dGVzdHBhc3N3b3Jk
type: Opaque

rmq.yaml

---
apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: my-rabbitmq-cluster
  namespace: ns1
spec:
  replicas: 1

user.yaml

---
apiVersion: rabbitmq.com/v1beta1
kind: User
metadata:
  name: test-user
  namespace: ns1
spec:
  tags:
    - management
  importCredentialsSecret:
    name: myuser-creds
  rabbitmqClusterReference:
    name: my-rabbitmq-cluster

And the following command: kubeseal -f secret.yaml -w sealedsecret.json

After creating the sealed secret using sealedsecret.json, I was able to create the RabbitMQ instance and the user. I think we may have fixed this unintentionally as part of a change to stop owning and watching all Secrets. At any rate, this use case is now fully supported.