Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Own certificate should be taken as a primary certificate instead of the newly created one #1613

Open
sybernatus opened this issue Oct 16, 2024 Discussed in #1576 · 3 comments
Assignees
Labels
triage Issues/PRs that need to be reviewed

Comments

@sybernatus
Copy link

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:

  • 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.

What do you thing?

Here is the flow impacted by this idea:

func initKeyRegistry(ctx context.Context, client kubernetes.Interface, r io.Reader, namespace, prefix, label string, keysize int) (*KeyRegistry, error) {

Copy link
Contributor

github-actions bot commented Nov 1, 2024

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.

@github-actions github-actions bot added the Stale label Nov 1, 2024
@hadrien-toma
Copy link

I would be interested too 😊

Copy link
Contributor

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.

@github-actions github-actions bot added the Stale label Nov 23, 2024
@alvneiayu alvneiayu added triage Issues/PRs that need to be reviewed and removed Stale labels Nov 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage Issues/PRs that need to be reviewed
Projects
None yet
Development

No branches or pull requests

3 participants