I'm not entirely convinced I want a feature that adds even more exposure to the sort of goofy login flow Tailscale has.
Of course, it's also worth knowing that SSO is basically a universal best-practice for security teams, and while it's not de jure required by SOC2, it's almost de facto required. For once, I think the best-practices and compliance people have this one right: you are extraordinarily unlikely to get burnt for trusting Google in this instance, and the security track record of ad-hoc authentication is worse than abysmal (ad-hoc authentication is probably implicated in a plurality of all major incidents).
For business users that isn't as much the case since there are good support options and it isn't likely you'll get locked out.
Great for businesses, potentially risky for individuals.
It is also best practice that some things explicitly don't sit behind SSO for defense in depth. If for example you leave CrowdStrike and JAMF behind Okta, and Okta gets popped an attacker can disable your endpoint protection and push ransomware to every machine.
We are looking at a future where a security breach or misbehavior by one of a handful of companies could mass-compromise millions of businesses and critical infrastructure and possibly hundreds of millions to billions of devices. Even worse this permission is clandestine. It could be exercised against individual targets with no obvious audit trail, since auditing tends to also be delegated to the IAM provider (and nobody looks at local logs in most cases).
I guess we've been handing vendors a lot of power for a while with OS vendors that have "push" software update capability, but this is adding not only even more carte blanche permission to a small number of companies but extending it across systems running different OSes and even open source platforms like Linux and BSD.
Software update capability is also fairly coarse grained. Apple or Microsoft could push a compromised or malicious update, but it would be harder for them to specifically target a single user reliably and without being noticed. (Wait... why did I get a macOS update and none of my friends did?) SSO/IAM providers could easily do this. Imagine a subpoena that targets your SSO/IAM provider that gives the government (and maybe not even your government!) silent unlimited remote access to everything you have.
I can also imagine "cancellation" scenarios where a company doesn't like what you say so they dump your account and lock you out of all your infrastructure, requiring you to manually go around and "root" all your stuff. (If you think this would only ever be deployed against Nazis, study history a bit. Political winds shift.)
It's just a monstrous amount of power to give out, and I feel like people aren't thinking this through or maybe are not even aware of the power they are delegating.
I feel like people should at least understand what they are doing when they choose to delegate all their authentication to Google.
One answer is to have many, many SSO/IDP systems -- and for anyone technical enough to set up a homelab to be able to be their own IDP.
I can foresee this eventually being a revenue stream for a lot of companies where they charge payola to be listed as an IAM provider, sort of like the browser CA inclusion or browser default search engine list rackets.
It supports both SAML and OpenID Connect/OAuth2. With an LDAP backend you can also use that LDAP backend for other services that don't support those two protocols for SSO, but it is not required.
Keycloak offers a much more "roll your own" design.
I think this is my biggest concern, it's really scary to have Google Auth as literally the only barrier between no access and complete production access. I understand that a lot of the time Google accounts hold the literal keys to the kingdom anyway (customer data, internal company data, maybe source trees), but SSH was one of the last frontiers remaining.
maybe i have an antiquated view of browser security but it seemed... unnerving.
So e.g. if you use "log in with Google" on a web site, Google now has access to your account too (if they behaved badly or were compromised).
Spreading SSO auth everywhere gives the SSO provider login access to absolutely everything you have.
You are delegating authentication, so your delegated authenticator can authenticate anything they want.
I feel like a large number of people adopting SSO/IAM systems don't fully understand this. If they do understand and are making a cost/benefit based choice to do this that's one thing, but... I think people should understand.
- Tailnet traffic needs to be associated with an approved device key
- Tailnet device addition needs to be signed by the offline key of another approved device
If a compromised control plane and/or SSO provider can add and approve devices on their own then the security architecture of Tailscale would be fundamentally broken. I wouldn't even call it end-to-end encrypted.
That's an easy one to circumvent if you don't need to install the malware Right Now: just wait until the next update cycle and slipstream your targeted malware in with it.
Can you be more specific about your complaints?
When I add a new server I get given a URL that looks like https://login.tailscale.com/a/c44a243b to visit in a browser and authenticate the new device, the meaning of which is quickly lost as soon as you go through a Google Authenticator sign in flow, fill out some recaptchas and find your phone for a SMS token, and then the device is added to your account with no further clicks (unless you enable device authorization). It feels very weak, the connection between logging in and performing an action is fuzzy.
Due to the use of Google SSO it just has the usual problems that you get. It's not quite clear when you're logged in or not or with which of the 12 google accounts you own, it's not clear what will pop 2FA requests or login prompts. As a service tailscale has made it clear that they don't want to be an "identity provider", which means you're sort of stuck with something that doesn't feel like you can make authoritative decisions about how it acts.
You can also apply an ACL tag to it so that it is no longer authorized as the user and instead takes on the permissions of the tag.
In our deployments we have the headless servers pull the tagged auth key from secrets manager on boot and then just `tailscale up --authkey <value>`.
I agree the default login flow is usually not what you want for headless servers. It sort of leads you down the wrong path.
Stop logging in to your personal accounts on your work machine.