Yesterday, I deployed a controller 2.9.45 and did
enable-ha which scales up to a total of 3 instances and automatically places the controller in ha-mode (awesome feature). I was careful to name the controller to my intended dns-name lets say: foo.example.com I’m not sure if it matters, but still I did so.
After the controller was up and available in AWS, I added the three IP-addresses to our DNS. The DNS returned all the three public addresses in a round-robin way, which was what I expected and wanted. This means that if one controller IP stops working, the controller is still available (ha).
Now, after this - I wanted to see if I could register and get someone else to test the controller. So I called @hallback and asked him to test. so I created his user:
juju add-user hallback
Which returned a registration token string that worked just fine for him - WITHOUT any added SSL-cert or haproxy etc (!) Happy days.
We then REMOVED the controller from @hallback controllers.yaml and had him try again to login to the controller - this time with just supplying the name of the controller and its dns-name (fqdn).
juju login -c foo.example.com foo.example.com:17070
This also works just fine.
This situation is rather OK - without having to mess with haproxy and certficates etc. Since the traffic seems to be all encrypted, I’m not risking my password and data to be leaked at some internet-cafe and all is good.
Is this secure and “good enough” to be considered a best practice? It matters since I’m also working on a “administration guide” where this kind of information might be added.
What are your thoughts on this @jameinel @hmlanigan ?
As a side note, the notable difference between the client controllers.yaml file after being updated by “register vs login” is that:
- When using the “register” way, it populates the file with a list of all the IP:s that the controller has, while
- … the same file after “login” contains only the domain-name fqdn (foo.example.com).
My fight with this continues…