Use existing ETCD and Kubernetes CA certificates #463
Replies: 3 comments 4 replies
-
|
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 @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. |
Beta Was this translation helpful? Give feedback.
-
|
Any update on this please ? this is something very important for us @log1cb0mb |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
How about... User StoryImport Existing In-House PKI Certificates and etcd Datastore into KamajiAs a Kubernetes cluster administrator, I want to import the TLS certificates from my in-house Public Key Infrastructure (PKI) and the existing etcd datastores from my three current Kubernetes clusters into Kamaji, so that I can seamlessly migrate my existing clusters to Kamaji’s hosted control plane management without regenerating certificates or losing critical cluster state data, reducing operational overhead and maintaining continuity. |
Beta Was this translation helpful? Give feedback.
-
|
For the Datastore I don't see a huge problem. I think the challenge here is about the CA: if we regenerate certs for the user facing ones, I don't see a huge problem, isn't it? Are you expecting a field in the Tenant Control Planes specification where to retrieve the CA? Does cert manager plays a role in the equation? |
Beta Was this translation helpful? Give feedback.
-
|
@rossigee just a follow up to continue the work I'd like to put in place |
Beta Was this translation helpful? Give feedback.
-
Yes, probably a reference to an existing secret.
Not in my particular case, although it might in others. In my case, I have an organisational intermediate CA from which I create a cluster-specific CA signing key/cert. I would then install them on the master node (directly into In the kamaji context, I would expect to just place them in a Secret and point to it from the TenantControlPlane resource. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
Beta Was this translation helpful? Give feedback.
All reactions