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

[Junien F]

Hi,

juju 2.9.32

If you add a LXD cloud with an HTTPS endpoint, such as :

mylxdcloud:
  defined: built-in
  type: lxd
  description: LXD Cluster
  auth-types: [certificate]
  endpoint: https://10.130.64.14:8443
  regions:
    default: {}

then when bootstrapping to this cloud, if the IP of the HTTPS endpoint exists on the local machine, juju will try to use the LXD UNIX socket instead of the HTTPS endpoint.

There are 2 problems with that :
1. juju doesn't do as instructed
2. access the UNIX socket gives trivial root access to the machine, as documented in LXD docs (you can map host files to containers which you control). Access to the HTTPS endpoint can be more restricted.

Could we please make juju use the HTTPS endpoint when configured to use the HTTPS endpoint ?

Thanks

[Junien F (axino)]

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

[Paul Goins (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?

[Ian Booth (wallyworld)]

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

[Paul Goins (vultaire)]

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.