KafkaUser secrets magically disappear
Closed this issue · 5 comments
KafkaUser secrets magically disappear after some time. For some time I'm facing problem with disappearing KafkaUser secret object of KafkaUser dedicated for MirrorMaker2. As I have Kafkas in more namespaces, I'm copying secrets between this namespaces for mm2 usage, so these secrets don't have KafkaUser object, they are just copies from other namespace.
Today I noticed that source secrets (created by KafkaUser) are somehow recreated after some time and its copies in other namespaces disappeared. Is it possible that Stimzi Operator is cleaning "orphaned" secrets without KafkaUser objects? Because I'm creating these copies with all Strimzi labels from source secret.
I was thinking if there is some refresh mechanism for KafkaUser secret, but I din't find anyhting in documentation. Strange thing is, that this behaviour is happening noly for KafkaUser secrets used by MirrorMaker2, other secrets were never "recreated".
I'm using spec.authentication.type: scram-sha-512.
When you copy the secrets ... do you remove the ownership reference from the Secret metadata? That is known to cause similar issues.
When you copy the secrets ... do you remove the ownership reference from the Secret metadata? That is known to cause similar issues.
nope, I'm still using deprecated kubectl --export flag for this usecase. So I'm going to create some copy-paster with custom metadata cleaner. Hope this will help. Thanks
Anyway, what about that "secret refresh" under source KafkaUser? Is this caused by some security mechanism that detects duplication, deletes it, and recreates the original secret?
For KafkaUsers with TLS authentication, the refresh of the secret sometimes also happens when it needs renewal etc. For SCRAM-SHA-512 it should IMHO not happen. But somehow (I do not really understand the details of the Kube internals for this), copying the secret including the owner reference caused not just the copied secret to be deleted. But also the original one. In which case the User Operator would just create the new one.
TBH, you are the first one reporting this with User secrets - in the past it was mostly with the CA secrets.
For KafkaUsers with TLS authentication, the refresh of the secret sometimes also happens when it needs renewal etc. For SCRAM-SHA-512 it should IMHO not happen. But somehow (I do not really understand the details of the Kube internals for this), copying the secret including the owner reference caused not just the copied secret to be deleted. But also the original one. In which case the User Operator would just create the new one.
TBH, you are the first one reporting this with User secrets - in the past it was mostly with the CA secrets.
Ok, thanks for information. I redesigned the script for copying secrets according to your advice and recreated it and we'll see.
Thanks a lot. I'm closing this
not to produce new messages. I think many will be interested to know how to disable the removal of the secret from other namespaces on the operator's side, and not in the secret. because there are quite a few programs that successfully copy secrets, but without removing "ownerReferences"
This is also true for cluster-ca-cert, because When connecting via TLS, this certificate is also needed. Because it is updated once a year, it would be convenient to automate the delivery of the CA secret