Skip to content

Lack of Certificate Renewal Mechanism in Addon Framework #304

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

Open
yanmxa opened this issue Mar 5, 2025 · 4 comments
Open

Lack of Certificate Renewal Mechanism in Addon Framework #304

yanmxa opened this issue Mar 5, 2025 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@yanmxa
Copy link
Member

yanmxa commented Mar 5, 2025

Currently, the addon-framework supports signing certificate requests on the spoke cluster. However, it appears to lack a renewal mechanism for signed certificates.

For example, when a certificate is signed using a CA via the registration process, it remains valid only as long as the CA is. If the CA expires or becomes invalid, and a new CA is issued, the signed certificate on the spoke cluster will no longer work.

The challenge is that there is no automated way to trigger the registration workflow to re-sign or update the certificate in the spoke cluster. Currently, the only available solution is to manually delete the certificate in the spoke cluster.

Open Question:

How can we automate the certificate renewal process in the spoke cluster when the CA changes?

@qiujian16
Copy link
Member

/assign @elgnay

@elgnay
Copy link
Contributor

elgnay commented Mar 13, 2025

One option is to add an optional filed authorityKeyIdentifier to registration config in the spec of ManagedClusterAddOn. If specified, the registration agent will compare the authorityKeyIdentifier in the ManagedClusterAddOn resource and the one extracted from the existing client certificate. If they are mismatch, a CSR will be sent to create a new client certificate.

  registrations:
  - signerName: kubernetes.io/kube-apiserver-client
    subject:
      groups:
      - open-cluster-management:cluster-proxy
      user: open-cluster-management:cluster-proxy:addon-agent
  - signerName: open-cluster-management.io/proxy-agent-signer
    subject:
      groups:
      - open-cluster-management:cluster-proxy
      user: open-cluster-management:cluster-proxy:proxy-agent
    authorityKeyIdentifier: F2:29:BA:B9:78:A5:9E:90:7D:96:7E:88:CE:DE:54:D4:1B:55:CF:64

@ldpliu
Copy link
Contributor

ldpliu commented Mar 13, 2025

@elgnay I did not see the field like authorityKeyIdentifier in https://github.com/stolostron/api/blob/main/addon/v1alpha1/types_managedclusteraddon.go#L45 .
Do you mean we could set OrganizationUnits in RegistrationConfig.Subject.OrganizationUnits like that ?

I tries this way, but kafka can not recognition the customized OU in server part by default. So it not works now.

@elgnay
Copy link
Contributor

elgnay commented Mar 13, 2025

@ldpliu The solution I described is a proposal rather than an existing feature. It has not been implemented yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants