If I use a GMail address and password as a way to authenticate Tailscale devices, does that mean that Google can also access my devives, since Google must also know my Gmail address and password?
Basic question, I know, but I have searched extensively, and cannot find an answer.
Google could pwn your account, but to access your network they would have to pwn your account and then add a device that does the accessing (without you noticing). Google does not do that.
Umm⌠so if this is correct, I seem to be entitrly reliant on Googleâs trustworthiness not to set up a new device on my account (since they know the user name and password) and do what they wish with all my connected devices. I donât think I would notice immediately if a new device were added to my account. This does seems rather unsecure to me.
I think I am going to uninstall Tailscale until reliance on the likes of Google is removed.
A couple notes:
Itâs also worth pointing out that most people put all of their account recovery steps for every product they use, including all their personal information, into a single email box, often Gmail.
Itâs a bit of a fallacy that, say, moving your username and password directly into Tailscaleâs servers (what will we do for account recovery when people lose their passwords? recovery email? Or should our support department do account recovery on the phone based on whether you can recite your social security number or mailing address?), or into a self-hosted identity system, makes you more secure. Generally itâs better to choose an identity provider you trust and then use it for everything.
We support other identity providers such as Okta and Ping Identity if you donât like Google in particular.
á§
Just because lots of people âput all of their account recovery steps for every product they use, including all their personal information, into a single email box, often Gmaiâ does not mean that it is a good thing to do. Popularity is not an indication of prudence. If it were, â123456â would be a good password because it is used by so many people.
I would not dream of storing sensitive information on an email server, so I am not sure why my login to an email server should effectively be the keys to my kingdom.
Tailscale could also probably access your devices. No offense to the Tailscale peeps but I suspect theyâre a far more vulnerable target than Google.
If you canât trust anyone, a self-hosted wireguard would be far more applicable. Especially because youâre also trusting that Tailscaleâs https relays\clients\auth servers have no back doors.
Gavin is right, thatâs the fundamental tradeoff. Youâre trusting Tailscale, and your selected identity provider, to do the jobs we promise to do. If you donât trust us and canât find a way to do so, itâs better to look elsewhere.
In the not-so-distant future, weâll be adding a new âlockdownâ mode that accepts nodes into your network only if they have been cryptographically confirmed by other nodes. That reduces some of the avenues for attack, even if your identity provider is compromised. But even that may not provide the level of paranoia youâre looking for, which might be attainable only with a fully open source software stack whose code you have audited yourself.
We have good chunk of SSO investment in Okta and I would assume others do too. Please make it as straight forward as possible without having to trouble the support team. I have been testing Tailscale for the last couple of weeks and I want this PoC of ours to succeed.
I find that Tailscale is many things. Of interest to us are:
Few things stood out which is preventing me from rolling it out in general:
Again, many thanks Tailscale folks!
I expect to add a self-service function to switch to Okta / Onelogin / etc at some point. We have not done so yet because sometimes, mistakes are made in the setup (for example in the OIDC redirect_uri) and the new authentication doesnât immediately work.
When we handle it in Support we can switch back to the original authenticator and work with the user to get corrected parameters. In a self-service function it would all have to be automated, maybe switch back if the first login doesnât succeed within N minutes or something. We donât want users locked out of their Tailnet.
- First class, no-brainer Okta integration
The next Okta-related feature Iâd expect is SCIM integration for automatic
group synchronization and automatically disabling users on update from Okta
- Employees using the same gmail address of the organisation? This means
automagic join to the Tailscale network - we would like to prevent that.
At least at present, a given Tailnet only has one source of truth for identity.
If the Tailnet is set to use Okta to login, a Google login will be declined.
âŚwithout having to trouble the support teamâŚ
If I could just say: it isnât troubling us, it is literally our job to support use of the service.
Thanks @DGentry. Those are all amazing! We would love to get the fully tested and working Okta integration in as soon as possible (hopefully, soon! 
) so I could hand off the Okta bits to our relevent engineers that manages SSO/2FA stuffs.
As for the Google to Okta transition, thatâd work perfect for us - Okta doing SSO/2FA and becoming the source of truth which is what we have for almost all other applications in our org.
Thanks for the kind words. We will surely be pestering the Tailscale team if all goes well 
Until there is a self-serve process, setting up Okta means following these steps and submitting the relevant parameters via the form in step 6: Setting up Okta to work with Tailscale ¡ Tailscale
Ack. Will do so @DGentry
Just to add one clarification about the way users logging into tailscale automatically puts them in your tailnet: a workaround for now is to set your ACLs with a fixed list of users who have access. Then if any other users manage to log in, they donât have access to anything so itâs harmless.
Because all your active users will have the same permissions or none, this doesnât trigger the per-user ACL pricing (thus is included in the Team plan without extra costs).
Another option to consider is handling it in the identity provider; in the one we use at my employer, we have internal group memberships which are required in order for the identity provider to authorize a login to a particular service. This avoids the problem of all ~20K employees being able to login to every service.
Good point! Not every IdP can do this, but at least Okta can.
I honestly do not think that being wary of what information miner Google is up to coule be considered âparanoiaâ. The fundamental nature of Googleâs business is to extract as much information as possible from any source available to them. Google droped the idea of âDonât Be Evilâ many years ago now.
I think that Google make it reasonably clear that they machine-read GMail messages and use their content to target cross-site advertising. Therefore, it seems to me that using a GMail account as a way of âsecuringâ anything is a fundamentally flawed idea.
Yes, this is looking much more reasonable! I have an extremely busy few weeks ahead but I will certaily look into this once I have a bit of time!
Yep no worries. It has been a good experience thus far with Tailscale.