4 ms·
Would that be a good use case for something like Userify, so that there's no need to store any keys in a base image/AMI where they can't be easily updated/remov
by hobobaggins 5y ago
Would that be a good use case for something like Userify, so that there's no need to store any keys in a base image/AMI where they can't be easily updated/removed? Then you don't need to give your private keys to a third party, either.
- nijave 5y agoWe didn't store keys in the AMI. We added the public half to EC2 then attached that key to the launch configuration where it gets added to the VMs authorized_keys on startup. I don't think running a Userify daemon on the server is better than a private key in 1Password. At least with the private key approach, you can layer on network access restrictions (firewall rules or VPN). Userify would need to create an outbound connection to its control plane to manage keys
- gunapologist99 5y agoThe Userify daemon in this case is just a shell or python script (https://github.com/userify/shim https://github.com/userify/shim) so pretty simple to audit.
- nijave 5y agoSure but it's still reaching out to a cloud service for auth info. You swap "someone could steal my private key from SaaS" with "someone could upload an additional key to SaaS" which I guess just helps if you're reusing keys for unrelated systems? I think Userify could potentially increase auditability by limiting key sharing but I don't see it actually increasing security assuming you can revoke/rotate shared keys.
- gunapologist99 5y agoWell, rather than have my private key stored in a remote repository, I upload only my public key to Userify, and that shim thing automatically distributes my public key to the authorized_keys file in my homedir, exactly in the same way as if I was doing it by hand. If 1Password was ever compromised, the attacker could use my private key to log into any server that I have access to at any time forever, and in fact I won't even know! But, if Userify is compromised, then the attacker can only deploy their OWN public key but my private key is still safe. This means that if 1Password is compromised, ALL private keys are compromised forever. If Userify is compromised, the compromise only lasts for as long as the attacker is actually logged in as you, and the prize for the attacker isn't getting your key (because it's public already), but only that they can deploy their own public key (and that produces a notification). So, you're right in that you still have to place some degree of trust in a third party SaaS, but the simplicity of Userify's model and narrow scope which minimizes access to any secret material is very appealing because it's very easy to understand and audit. Userify is about as close to Zero Knowledge as you can get for an SSH connection. And, if that's not enough, I can just buy my own Userify Express server and close it off on my own private Wireguard network or VPC and never let the outside world anywhere near it.
- nijave 5y ago>If 1Password was ever compromised, the attacker could use my private key to log into any server that I have access to at any time forever, and in fact I won't even know! Right, this is only a problem if you don't have another form of key and don't have login auditing With access to Userify, an attacker could upload a key to any server anywhere and still have access. In the original post, I mentioned we already had an easy way to rotate keys via automation. We also had CloudTrail alerts and AWS Config alerts around port 22 security group rules (they were closed by default). Sure Userify provides a lot of these things like key management and audit trails but my original point was it's silly to worry about storing private keys in SaaS when you use SaaS for other authentication and authorization anyway.