You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are trying to use our own certificate to encrypt secrets.
The issue we encounter actually is that for a controller installation, this certificate is not used as primary certificate.
Here is the flow:
we deploy our own certificate as a secret
afterward we deploy sealed-secret controller
In this case, our certificate is taken into account by the controller as we can see it in the log but also as it is a new instance of sealed secret, the controller will create its own certificate.
As its own certificate is newer, it will take it as a primary certificate and kubeseal will use this one to encrypt secrets.
Our workaround today is to redeploy again our own certificate but I think it's an issue from the controller.
I think, that if the controller see that there is an existing certificate created, it should avoid creating its own certificate and just use the created one. This might be tackled for example, using a new arguments to the controller (--cert-creation=false).
The idea is to let the control to the project if it wants the control over the certificates used by the controller.
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.
Discussed in #1576
Hello,
We are trying to use our own certificate to encrypt secrets.
The issue we encounter actually is that for a controller installation, this certificate is not used as primary certificate.
Here is the flow:
In this case, our certificate is taken into account by the controller as we can see it in the log but also as it is a new instance of sealed secret, the controller will create its own certificate.
As its own certificate is newer, it will take it as a primary certificate and kubeseal will use this one to encrypt secrets.
Our workaround today is to redeploy again our own certificate but I think it's an issue from the controller.
I think, that if the controller see that there is an existing certificate created, it should avoid creating its own certificate and just use the created one. This might be tackled for example, using a new arguments to the controller (
--cert-creation=false
).The idea is to let the control to the project if it wants the control over the certificates used by the controller.
What do you thing?
Here is the flow impacted by this idea:
sealed-secrets/pkg/controller/main.go
Line 64 in 15df23b
The text was updated successfully, but these errors were encountered: