Use existing ETCD and Kubernetes CA certificates

[log1cb0mb]

Ability to allow users to provide an existing CA certificate for both ETCD and Kubernetes in the form of a secret containing content however Kamaji expects it to be.

Current behaviour seems to be that ETCD CA is pretty much hard coded and is utilised during etcd datastore bootstrap.

TCP does allow reusing existing secret (named exactly what TCP specs expect) containing CA certificate but due to Kamaji controller not maintaining checksums for the secret containing CA certificate, reconciliation keeps triggering deletion of existing secret. In case the secret is not available by the time Kamaji controller gets to the phase of using it, it generates its own CA certificate.

This would be a helpful feature:

• Organisations that tend to streamline central PKI usage in their infrastructures
• Allow creating certificate based credentials in advance to kubernetes control plane bootstrap e.g terraform workflow where valid credentials for Kubernetes API must be known before the bootstrap.

[prometherion]

I spent the whole holiday trying to find a solution to this. However, it would be cool and helpful to have a proper user story, along with the tools and some examples used to achieve the offloading of the certificates to a third party.

What we could introduce from Kamaji's standpoint is a knob, potentially an annotation on the TenantControlPlane resource.

@log1cb0mb it would be cool if you could provide further details about it, such as skipping all the certificates checksum checks, or making it fine-grained: again, it's a use-case particular, we're open to getting this implemented, we need to gather more details and a user-story would be really helpful.

[HamzaZo]

Any update on this please ? this is something very important for us @log1cb0mb

[prometherion]

@HamzaZo right now this feature is not planned because we were waiting for a user story from @log1cb0mb.

Feel free to share yours so we can evaluate to add it to the pipeline.