Add ability to generate config trust tokens

[stew3254]

I am currently working on a scenario where I deploy a MAAS container and would like to connect it to the host LXD in order to spin up VMs to use within MAAS. This is a nice system because it can fully utilize the host's resources, and can be fully automatic by using a LXD trust password. However, the trust password is going away and there is no way for me to generate a token via Terraform to supply to my container so it can add its client cert.

If possible, I propose a new resource be created which allows users to create trust tokens and a method by which they can be consumed by another resource.

[MusicDin]

Hmm, I see where this is going and I like the idea, but the issue with trust_token resource is that it is a one time operation, which we want to avoid as much as possible. Ideally the resource configuration should be reflected in the LXD, which is not the case for tokens (as they are required/consumed only once).

While the creation of a token can be easily implemented, my question is what do we do with the resource (and its state) once the token is generated (can we avoid having it in a state) and consumed (do we just remove it and ignore the resource on future applys)?

@simondeziel any thoughts?

---

Another potential approach would be to have a function that would request a token with a given name when called. If the token already exists, it would return it, otherwise it would request a new one. This way, we don't have to track the state for this resource, as all the user cares is to get the token that works. The downside would be that we cannot clean it up if it is not consumed.

Just to emphasize, I'm not sure if this would work - just an idea.

---

Finally, could the new trust_certificate be of use in this scenario? It would require you to provide an existing client certificate. Therefore, it is not ideal, but may serve as a temporary workaround. (this will be included in next terraform release - unreleased docs)

[stew3254]

Hello @MusicDin. I realized there might be some complication in both of the first two scenarios, but I'm still new to Terraform and learning the model. I'm not sure I can provide much input on the two, but am happy to learn!

Regarding the third, it might work in my case. I'm using Terraform to generate the MAAS machine, so I'm not sure I can force it to have a specific client certificate. It might be possible for me to work around by using a bind mount device to provide the cert and and cloud-init script to replace whatever LXD generated. Then, Terraform would also be able to see the file and add it to the local trust store.

[simondeziel]

As explained by Din, the ephemeral nature of the remote join token that it's requested and consumed only once makes it a bad fit for automation via Terraform.

[stew3254]

The function idea is interesting. If coupled with a short expiration timeout which corresponds with the machine's creation timeout (just a suggestion for lifetime of the token), it would be convenient. Then you don't have to worry much about it being used.

[stew3254]

After more thought on it, the function idea would probably be the best solution when coupled with a short token expiration timeout. It would make it very simple to pass the token into instances via user.* keys. If that instance failed to deploy, and the function returns the same token if the client name already exists, that would keep it from generating tons of tokens in the trust list. Then, worst case if it weren't used at all, it would disappear shortly after anyways, so there isn't much fear of leaving behind residue.

In the meantime, I can try to see how to force the trust_certificate to work when that comes out. I'm thinking if I use a bind mount device I can take whatever the client generates and write it to a particular path which otherwise holds a dummy / old data. If I run terraform apply again once the client wrote its data out, it should fix things. Another way is to simply generate my own ECDSA cert with openssl prior and pass it into the vm and copy it over to $HOME/snap/lxd/common/config/client.{crt,key}. That's an acceptable work around for now.

Thanks all for your help and feedback!

[stew3254]

@MusicDin @simondeziel Merely for planning purposes, not to rush you in any way as there is no timeline on my end for this, do you have a time on when I can expect the new resource (and possibly also function) to be available to consume?

[MusicDin]

@stew3254 I've quickly checked the functions, but it seems that Terraform function cannot access the provider's metadata, which would be required to access information about different LXD remotes. Therefore, we will probably go with a resource, but I would like to postpone it to release 2.3.0 to get some more time for investigation (2.2.0 will be very soon).

[stew3254]

@MusicDin Thanks for the update!