Add Extra System Certificate Authorities During Juju bootstrap/add-machine

solved
networking

#1

I am trying to setup Juju for local development using the localhost cloud and I am behind an HTTPS SSL bump proxy. Because of the SSL bump I have to add the proxy’s HTTPS certificate to the system certificate authority, but I haven’t found a way to automatically do that when bootstrapping a Juju controller or when adding a new Juju machine to the localhost cloud.

Currently my workflow is to run a juju bootstrap with the the --model-default http-proxy flags and then, while Juju is running the configuration script on the new LXC container that it creates for the Juju controller, I use lxc file push and lxc exec to copy my certificate into the container and run update-ca-certifcates. After I do that, the configuration script can successfully finish downloading what it needs to bootstrap the controller.

I’m going to test it, but I’m assuming I’m going to have to add the certificate authority manually for every other machine that the controller creates as well.

Does anybody know of a way to automate this? Even if I could specify my own custom script that Juju would run before it runs its own configuration scripts that would work.


Adding trusted Certificate Authority certificates (CA certs) to machines, including machines yet to be provisioned
#2

There is a way to deliver this with the model-config value cloudinit-userdata

I’m fairly sure there is a cloudinit key that allows the writing of certs and we support that.


#3

Sweet, thanks! I’ll check it out as soon as I can, but I think that should do the trick.


#4

I can confirm that we do allow certs to be added via cloudinit-userdata, use the ca-certs key. The model config feature can be picky about spacing etc for cloudinit-userdata. There is more info in the doc linked.


#5

Perfect. And for reference on how to specify CA certs in a cloudinit file:

https://git.launchpad.net/cloud-init/tree/doc/examples/cloud-config-ca-certs.txt

And that must be put indented in the yaml correctly like the doc linked above indicates, too.