We don’t have any feature or product functionality that would make this easy to do. There is a decent amount of cert legwork to standing up a cluster.
In theory, it might be possible to hack something together using existing features, depending how strict you’re requirements are.
- You can customize the runtime container (the planet container). So you can rewrite the configuration files within that container, to launch kubernetes with an alternate set of certificates. https://gravitational.com/gravity/docs/pack/#custom-system-container
- You can mount directories from the host to planet, if that’s where you’re certs are located, for the services to load: https://gravitational.com/gravity/docs/pack/#image-manifest-format
So you can probably customize a majority of the control plane this way. Some of the gravitational agents and kubeconfig would still be a challenge though, as they probably hard code where to locate the certs on the filesystem.
Depending how strict you’re requirements are, the upgrade/operation agent might be a challenge. Temporarily during operations, like while the cluster is upgrading, an agent is deployed with it’s own set of x509 secrets. If you need to cover this temporary agent as well it would be difficult to do without hacking out the internals and building yourself.
So I’m not recommending this approach at all, but this is the closest I can think of in a few minutes if you really want to try it. It’s likely to be painful, and we don’t have anything on a short or medium term roadmap that would help. You’d also need to be careful to track the project as we make changes to paths, SANs, etc.
This isn’t possible without building gravity yourself at present. It’s probably time for me to go through and update everything back up to Mozilla Modern compatibility which is what we normally use as a reference. https://wiki.mozilla.org/Security/Server_Side_TLS