jefflill
commented
1 year ago The #1770 login refactor is now persisting the deployment information including the hosting details and secrets to the cluster and I first thought that we could just obtain this information from the cluster.
Unfortunately, this won't work for scenarios where the cluster isn't running (paused or stopped) and the user needs to restart the cluster. This isn't an issue for Hyper-V again, because no host authentication is required but is a problem for the other hosting managers.
We're going to continue including the hosting information in the kubeconfig cluster. I believe that ultimately, secrets like this will need to be persisted elsewhere, perhaps neonCLOUD or a password manager and then we'll need to figure out how to secure access to that.
Local cluster login files include the cluster definition but we've been scrubbing hosting manager related secrets here after cluster setup completes as a security measure.
Unfortunately, now neon-desktop now periodically checks the status of the cluster, we need hosting related credentials to query the state of the hosting platform. I didn't notice this when deploying clusters to Hyper-V because are are no credentials necessary for the local built-in cluster but I did run into this today while testing the new status and resource check updates for the XenServer hosting manager.
We're going to need a better strategy for handling secrets, probably some combination of neonCLOUD accounts, Vault, and perhaps 1Password but this need so to work for users as well.
For the time being, I'm going to disable the cluster definition code that clears the hosting secrets but we'll need to address this before shipping.