Right now, when performing a manual provisioning of charms with juju, the provisioning script is executed from the Juju client machine, not from the controller.
We talked with @pengale, and we thought it would be a good idea to move the logic that handles the manual provisioning from the client to the controller.
From a security standpoint, it is better that the provisioning is done from the controller, because there might not be connectivity between the Juju client and the charms of the manual cloud; and right now we would need to enable that communication, when we could be deveraging the connectivity between the controller and the charm that already exists.
You are welcome to share your thoughts about this.
I definitely agree we should support this option, but I might suggest making this process adaptable based on the “proxy-ssh” setting in the model-config.
This setting determines whether the model operator intends for the juju client to perform the ssh directly to the managed metals or if the juju client should proxy the ssh session through the controller for more granular network access management.
I think the fundamental question is how do you get a trusted route from the controller to the target machine. eg, what SSH private key should be used that is authorized to access the machine to run the scripts. If you have to ssh as your user to then add a credential for the controller to SSH in as, you haven’t gained much. I suppose if you provisioned ahead of time with a known key that the controller has access to (as part of the machine cloud-init, etc), then it would be plausible to have the controller get access.
I’m guessing you mean machines/containers/vms here vs charms?
In general we don’t require that the controller has a route to the machines, just that the machines have a route to the controller. But obviously for manual provisioning something has to have a route to the machine and then that machine needs to route to the controller.
