It might be a good idea to think about a system that can update/rotate your keys across all of your servers on the fly in case one is compromised or assumed to be compromised. (disclosure: I work @ userify)
In addition, it might be a good idea to think about a system that can update/rotate your keys across all of your servers on the fly in case the third-party service you're using to manage the keys to the kingdom is compromised or assumed to be compromised.
I really must have missed the story here -- people pay for a third party service to manage their private keys?
... Err. That's so illogical it's making my brain hurt to even work out why I would need to explain how illogical it is...
I can't even come up with a good analogy for how wrong that whole idea is, fortunately I don't have to though since no one that has mastered 'ssh-keygen' and 'cp' would actually do so.....
2FA, okay; the service provider only has half the story. ssh-keys-as-a-service? WAT.
Edit:
Okay, I looked a bit more at userify and it seems to be an agent that runs on your systems which generates authorized_keys files....
From their docs:
"There are two parts of the Userify installation: creating the agent (readable only by root) in /opt/userify, and setting the agent to start at bootup. Setting the agent to start at bootup is a bit trickier, but the installation process attempts to detect the server type and set it up properly."
Am I reading this wrong? You hook up an agent, which runs as root, which farms out authorized_keys entries across the estate? One possible mech for deploying the agent is conf management?
What the actual fuck? Why would anyone do this? Do I even need to explain why this is blowing my mind so much?
keyegn + cp don't do everything. Unless the distribution and session killing is automated, you can't easily revoke access. Of course you could implement this fairly easily with {chef/puppet/salt/ansible/...} and ldap, but it requires time / bandwidth. This is what userify seems to give you.
I'm not saying it's a good solution though. I agree that it's giving someone full access to your whole environment and it's a bad idea.
Okay, there are a few things here.. I'm not trying to rant at the people behind this directly, there are a number of similar agent-based tools which have similar issues, so please don't take it personally...
1) If you have the ability to roll out an agent such as this, with your conf management, then you could just manage your users that way instead....
2) Even assuming that this SAAS is un-hackable (lolz), you're now in the situation where all access to every machine in your environment can be changed with a single password on some web ui you don't control, which can be accessed from anywhere.
3) This should go without saying -- I can't put too much faith in how well it's implemented -- pwn the saas, then I immediately own every system connected to it..
4) The enterprise docs talk about sitting it next to your LDAP system... If I had an ops discipline and environment which has gotten to the point where I'm dealin with LDAP, why wouldn't I just configure PAM to read my ssh keys from that, instead of this?
I understand this is one of many such products which are coming out of the lack of desire/time/staff to handle opsy-style tasks when features could be getting written (I'm planning a talk on this...)
But.. does anyone really think that the cost of spending a day wrangling ansible to manage access to your servers is worth more than giving some random third party the ability to add users to your production databases?
I've dealt with many, many different auth mechanisms up to this point. LDAP+Pam_MkHomedir, NFS, Config Management, Shared Keys, Shared Passwords, etc etc. Each have problems, but I don't think the issues with any of those are solved by this, are they?
This must be aimed solely at small startups with no ops experience, right? No one would actually put this near real data, would they?
> Do I even need to explain why this is blowing my mind so much?
Not to me, I felt exactly the same way.
I simply cannot fucking believe that somebody would "outsource" something as sensitive as this. Then again, I don't run my services on other people's computers either. My servers are either in our cages in datacenters or in buildings that we own, they're locked down as much as I can get them (DISA STIGs, etc.), we encrypt the hell outta data, we have strict security policies, etc.
I really can't imagine doing something this crazy but clearly I'm in the minority.
Userify is available as on-premise too. (btw I strongly agree with you... we're offering 5 server enterprise license model and we're looking at an unlimited stripped-down free version.)
Also, you're probably running servers at a third party hypervisor already.. ;) they could be scanning your RAM and reading your disk and you'd never know.
Yeah, actually I'm not. All of my servers are either in our own cages in datacenters or housed in buildings that we own. We don't do AWS/DigitalOcean/etc. (Nice attempt at a jab, though.)
I certainly wasn't trying to shit on you (or your company/employer) personally... but to me the idea of turning over ultimate control of all my servers, data, etc., to some unknown third-party and simply trusting them is absolutely fucking absurd.
I pretty much agree with everything cyberpunk said in this thread. I've been around long enough that it shouldn't but some of the things people do with regard to security sometimes surprises me and just leaves me standing there with my mouth hanging open, saying "WTF?".
Are you really asking the difference between the CA bundle and some node+redis+python startup being able to drop authorized_keys across your datacenter?
The original conmment was about "unknown third parties". I'm not advocating handing over your ssh keys to anyone but if you did, at least this would be a third party you consciously chose to trust. The crap load of CA's you implicitly trust on the other hand... Do you even know the names of 10 out of about 200 of them embedded in your browser?
