juju wants to use the LXD UNIX socket when configured to use HTTP

Credit where credit is due, this bug was discovered and investigated by @vultaire

Junien, thanks for filing this. I was just going to file this today based upon comments you made on the internal support ticket I was asking about.

What I saw when trying to bootstrap via an LXD remote was that, in provider/lxd/credentials.go of the Juju sources, in the isLocalEndpoint method of the environProviderCredentials struct, the code seems to clearly indicate that an endpoint is considered to be a local endpoint if the endpoint address is contained within the local addresses enumerated from the host's interfaces. I see that in this case, the finalizeCredential method of the same struct will then run serverFactory.LocalServer(), which after digging down several more layers, leads to the SocketPath call in container/lxd/connection.go, resulting in a ConnectLXDUnix call.

Long story short: even if attempting to bootstrap against an LXD remote rather than "localhost", it seems like interfaces are examined, the IP found attached to one of the local interfaces, and thus isLocalEndpoint returns "true" triggering use of the UNIX socket instead of the requested HTTPS endpoint.

Given the differences in security between localhost and HTTPS access to LXD, can we either remove this defaulting-to-UNIX-socket behavior, or at least allow for an option that avoids that behavior and allows strict use of the remote endpoint?

I think this PR might be the right thing to do. It might pay to test without the fan overlay as well.

https://github.com/juju/juju/pull/14283

As a workaround in the meantime, an LXD container can be used to bootstrap - the LXD bridge provides access both to the host and likely to the networks that the controller container is being instantiated on. Some other actions, like update-credential, would also require this type of workaround.