Closed omerlh closed 3 years ago
We do not see this as a bug.
If recreating the same Service Accounts, generates new secrets, this will cause interactions to fail.
You might ask why we are recreating service accounts if we don't want new secrets? We might need to recreates the service account for other reasons: we can't alter something else without first deleting the service account, or something like Terraform wants to do it for us.
If this issue cause the behaviour to change. We would like an option to keep the existing secrets/keys.
So we can make this an opt-out feature - by default, Kamus will delete the relevant encryption keys and users can disable this behavior is it does not fit to their flow. What do you think about this solution?
As long as our user-case is available (the old keys are still recognised) is catered for, then we would be happy. I don't think we have much of a preference as to which is the default, although I might suggest keeping existing behaviour as the default to avoid surprises. But we could work with an opt-out.
I just think it's a security issue, this is why I think it should be the default. Anyhow, this is not we'll have time to do soon. Looking for help here :)
Over the time Kamus been proven to be helpful in multi-cluster cases, that should share the same encryption keys. I don't see how such a feature could be implemented without eliminating the ability to use Kamus on a multi-cluster environment.
I'll close that now, feel free to re-open.
Just to make sure: I can use the same encrypted secret in git for a multicluster environment as along as the serviceaccount name and namespace name is the same for all clusters?
This means that when a service account with the same name is created, the same key will be used.