Tailscale browser login (rebase) #51
Conversation
1.19.109 adds `tailscale up --json` support Signed-off-by: Denton Gentry <[email protected]>
Save the tailscale.state file to the host, to not require re-authentication for Tailscale each time Docker Desktop starts up. Signed-off-by: Denton Gentry <[email protected]>
Writing to /etc/resolv.conf in the container isn't working yet turn off DNS settings until we have a solution. Signed-off-by: Denton Gentry <[email protected]>
tailscaled can use /dev/net/tun in TAP mode to provide tailscale connectivity on behalf of a single container. https://github.com/tailscale/tailscale/blob/main/net/tstun/tap_linux.go TAP mode in tailscaled isn't finished yet and may not be used for initial launch, but to be able to work with it: - switch back to using docker compose to build - add CAP_NET_ADMIN and the /dev/net/tun device Signed-off-by: Denton Gentry <[email protected]>
authkeys are only available to admins of the tailnet. Use the (newly added) "tailscale up --json" support to provide a URL to click on. Signed-off-by: Denton Gentry <[email protected]>
|
I understand why adding a user login, I think the token login would also be valuable as an option, I'd like to keep this available somehow. Would that be possible ? |
|
authkeys are intended for authenticating servers and infrastructure, with design choices to match:
If a desktop client like the one in Docker Desktop uses authkeys then it encourages people to actually use authkeys for desktop environments. In multi-user tailnets we're likely to end up with all of the Docker Desktop nodes owned by the IT Admin and having the ACL access of the IT department, which is unlikely to be what they intended. We'd expect this to lead to feature requests for authkeys for use by regular desktop users, which isn't how we want the feature to evolve. On personal tailnets authkeys seem better, because the personal user is also the admin of the tailnet. One common reason for using authkeys on personal tailnets has been to authorize devices for family members or other devices where one doesn't want to log into one's own Google/Microsoft/GitHub accounts, or perhaps when the device is remote and having to walk the family member through it on the phone. We have a different solution for that: the authorization page which opens does not have to be answered on that specific machine. If the family member is able to copy the URL from the browser and forward it, you can open it on your own machine to authorize the remote machine. What we are likely to do in the future is allow an authkey to be pasted into the browser authentication page where an email address is currently accepted. This would let people use an authkey with a mobile device or whatever if they really want to, without encouraging authkeys be used for desktop environments.
|
|
I think we've each been waiting for the other to merge this. I've been able to work from a local clone of the repo, but we'd like to rebase to HEAD. I'm going to try to merge it. |
This PR tries to rebase the work from #49 into
HEAD.See below the video showing how to login via the browser instead of using auth keys:
Screen.Recording.2021-12-10.at.08.23.57.mov
@gtardif Can you run it on your local with our latest Docker Desktop build to ensure this works for you too?
/cc @DentonGentry @mayakacz