fix(auth tokens) Added support for auth tokens

[Pive01]

Problem

With localstack 2.2 we introduced the machine.json file which failed to be mounted because the cli attempted to mount it into /root (which does not have permission to). This is because the cli uses the $HOME env variable inside the host to determinate where it should mount these files. The problem is that it's used inside a container and the HOME for the container is pointing to /root so it tries to mount on root of the host

Solution

Overriding the HOME env variable with the correct one (already available because used for the mount point). This requires also a bit more tricks to it:

• the cli implementation of the auth token check is just inside the pro image so you need to start the pro container to spawn the cli
• the binaries of the cli are not present in the pro image so we invoke it directly via python inside venv
• the cli need the community image to work so we kind of force to have both on the host machine (that's why we download both of them)

As a side note, something changed with the parsing of additional flags, that's why I removed the \'

[whummer]

Kudos for tackling this @Pive01 ! 🚀

I'll leave the more detailed to @lukqw , but conceptually I think it would be great if we can find a way that doesn't require downloading both, the localstack and localstack-pro image.

We could, for example, use one of the two images (whichever the user chooses to use) to launch a container with a volume mount from the host (e.g., LocalStack volume dir), then download the CLI binary to the mounted volume dir (if it doesn't exist yet), and then call the CLI binary from there. This would be a bit more efficient and save most users quite some download bandwidth.. 👍

Haven't looked into all the details, but conceptually I think something like this should (hopefully) work. But again, will leave it up to you two to decide..

[Pive01]

Kudos for tackling this @Pive01 ! 🚀

I'll leave the more detailed to @lukqw , but conceptually I think it would be great if we can find a way that doesn't require downloading both, the localstack and localstack-pro image.

We could, for example, use one of the two images (whichever the user chooses to use) to launch a container with a volume mount from the host (e.g., LocalStack volume dir), then download the CLI binary to the mounted volume dir (if it doesn't exist yet), and then call the CLI binary from there. This would be a bit more efficient and save most users quite some download bandwidth.. 👍

Haven't looked into all the details, but conceptually I think something like this should (hopefully) work. But again, will leave it up to you two to decide..

Downloading the binaries in a volume implies that we also need to check if there are new binaries and download them each time replacing the old ones which is a bit of an overhead to do. As a quicker solution, we could simply check if one of the env variables is LOCALSTACK_AUTH_TOKEN and if it is use the pro container (will have to download both anyway); if it's not set just spawn the normal one

[lukqw]

LGTM