🤖 Created branch: z_pr102/maryamtahhan/feat_central_cert_manager

For extra bonus points, it would be great if this could be replaced with ACM’s certificate signing setup when running on ACM. (I’ve been meaning to look into how that’s used...)

So the OCM CSR issuing process is described here and implementation (from managed cluster POV) is here and the controller on the hub is here

My over simplified understanding there's a certificate controller on the hub managing certificate approvals/issuing/renewals and verifying the CSR requestor. At managed cluster registration time, the agent on the managed cluster generates a CSR on behalf of the cluster towards the controller in the hub. The controller in the Hub approves the managed cluster and issues the relevant secret which is then propagated to the managed cluster as a secret.
For renewing the cert - the agent on the managed cluster initiates the renewal request on behalf of the managed cluster...

It also looks like cert manager can be used alongside K8s certificates API as a signer however it is experimental https://cert-manager.io/docs/usage/kube-csr/... so probably best to avoid...

If we are using the K8s certificates API directly with the K8s signer - we would still need a controller on the Broker node that validates/signs the certs... and still need an agent on the clusters to sync the requests to the broker and the results to the GW...

All that being said, the discussion comment above and the design in OCM reusing the K8s Certificates API should be possible:

This means that on the broker node, submariner needs to:

• Create a controller that will manage certificate requests and validation of csr issuers.
• Create the central CA cert and propagate to all cluster gateways as a mounted secret similar to the Broker CA.crt

On the clusters nodes:

• At GW startup, the GW will need to install the central CA cert, and it will still need to generate a private key and a CSR.
• The GW will need to periodically check if the cert is due to expire soon and issue a renewal...
• Using the existing mechanisms in Submariner today, a syncer will still be required from what I can see to sync the CSRs at Gateway startup time to the Broker API and sync back the result (signed cert chain)... Unless we have some agent on the GW node that directly interacts with the broker API on our behalf... This of course introduces the issue of having CSRs synced to all clusters in the clusterset and introduces the need on the broker to redirect the response to a particular cluster via selected imports?
  If not a syncer - then modify admiral to introduce some API to allow us to submit CSRs to the Broker API and retrieve the results directly...

Thoughts?

• This of course introduces the issue of having CSRs synced to all clusters in the clusterset and introduces the need on the broker to redirect the response to a particular cluster via selected imports?

SourceLabelSelector and SourceFieldSelector on the Syncer with labels and annoations could resolve this issue... Thanks @donaldh for the suggestion.

I was thinking of the CSR approval mechanism used in the OCM Submariner addon; this relies on the OCM addon framework, see https://github.com/open-cluster-management-io/addon-framework/blob/main/pkg/addonmanager/controllers/certificate/csrapprove.go

So obviously this can’t be used as-is in Submariner, but I was wondering if there was anything useful to learn from that.

Ultimately I don’t think I have anything to add to #102 (comment). Given that Submariner already has syncing mechanisms in place, we might as well use those instead of exposing a new signing service.

I was thinking of the CSR approval mechanism used in the OCM Submariner addon; this relies on the OCM addon framework, see https://github.com/open-cluster-management-io/addon-framework/blob/main/pkg/addonmanager/controllers/certificate/csrapprove.go

So obviously this can’t be used as-is in Submariner, but I was wondering if there was anything useful to learn from that.

I will have a look. @donaldh also suggested potentially looking at creating intermediate CAs locally --- I will take a look at both and circle back

I was thinking of the CSR approval mechanism used in the OCM Submariner addon; this relies on the OCM addon framework, see https://github.com/open-cluster-management-io/addon-framework/blob/main/pkg/addonmanager/controllers/certificate/csrapprove.go
So obviously this can’t be used as-is in Submariner, but I was wondering if there was anything useful to learn from that.

I will have a look. @donaldh also suggested potentially looking at creating intermediate CAs locally --- I will take a look at both and circle back

I had a look at the addon csr signing controller - it seems to work in a similar way to the central csr signing controller in OCM in that the addon manager is serving as a custom CSR signer controller for renewing CSRs for managed clusters...
I'm not sure that it adds anything more for us, so going back to the suggestions
#102 (comment) I will push the relevant updates to the proposal

For posterity :) I've updated the EP based on the discussions we had and resolved any open issues.

I can no longer implement this EP (due to a shift in priorities), should I close this EP?

🤖 Closed branches: [z_pr102/maryamtahhan/feat_central_cert_manager]