Synator didn't recreate secrets after etcd re-init

[Philippians413]

We use a combination of sealed-secrets and synator.
After network downtime etcd cluster restarted.
Secrets were created in source namespace, but synator weren't create them in namespaces that on include-namespaces block.

Also, is it possible for synator: if we delete secret in source namespace to keep secrets in namespaces that specified on include-namespaces block?

[TheYkk]

Thanks for using synator,

How can I reproduce this situation?
Did synator delete copied secrets? because you said synator wasn't created secrets.

[Philippians413]

It's very specific case, I'm not sure that it's possible to reproduce.

I just want to clarify some points:

• is it possible that during upgrade_secret synator can delete secret? If yes, could you please add it in logs, because it's not obvious;
• is it possible for synator: if we delete secret in source namespace to keep secrets in namespaces that specified on include-namespaces block?

Did synator delete copied secrets?

Yes

[Philippians413]

Hey @TheYkk
We found that problem was not on synator side, but for our case it would be good to add this functionality:

if we delete secret in source namespace to keep secrets in namespaces that specified on include-namespaces block?

For example, we create secret in development namespace and add annotation for it

synator/include-namespaces: foo, bar, xyz

but if we delete this secret in development namespace, keep it in foo, bar, xyz namespaces.
Is it possible? We would be grateful from our side

Regards,
Bohdan

[TheYkk]

I think it's possible to do that. In the update part, we can ignore deletion requests.

[fenfir]

I ran into a similar issue with sealed secrets. I think the owner reference block on secrets created by sealed secrets is preventing them from being created in other namespaces.

  ownerReferences:
  - apiVersion: bitnami.com/v1alpha1
    controller: true
    kind: SealedSecret
    name: star-example-com-cert
    uid: 3c5845af-018f-4577-bbdd-023f0e7cbe9f
  resourceVersion: "199651653"
  uid: 57a4d0c7-7bbe-436c-a67a-67a5a1077de6

[zackb]

@fenfir did you ever come up with a solution to this? I think the same thing is happening with Secrets created with SopsSecrets

[slax81]

@fenfir @zackb
You can check my fork until the pull request here is accepted. It removes ownerRef from metadata and secrets are not deleted by the Kubernetes garbage collector.