Hacker News new | ask | show | jobs
by crandles 4781 days ago
"We require that you deploy our public key to your root account’s authorized_keys file so that we can provision users on your behalf."

That feels like a big requirement. What is the gain of using your UI/service over using puppet in-house and creating your own UI?

1 comments

Well, we talked to server admins (mostly at companies that run servers on behalf of web design or web services clients) and heard that they didn't want us to impose the requirement of adding another package to their deploy scripts. They'd have to keep the version up to date, make sure it's installed on their machines, etc. That's feedback was really the only reason why chose to impose this requirement for the beta.

I'd love to hear more about your use case and if you'd feel more comfortable having a daemon run on your servers (so that our service wouldn't have root login ability).

> That's feedback was really the only reason why chose to impose this requirement for the beta.

I'm not sure how accurate this quotation is, but Henry Ford may have said:

"If I had asked people what they wanted, they would have said faster horses."

As a consultant I feel it is my duty to advice people when they are asking me to implement something that is not in their best interests.

If someone has told you that "installing packages is difficult, just login as root", I think it is your duty to educate them as to why that is a bad idea.

Anyone familiar with security best practices would never even consider allowing an untrusted third-party to log in to their servers as root, which drastically reduces the size of your potential market.

Currently, your target market is: people who find it difficult to use configuration management tools, and who aren't aware of good security practices.

Just about anything would be better than 100% root access and "employed measures to make sure that we never have unattended access to your servers", and there's no reason you can't offer two solutions.
You'll have to develop a cryptographic scheme makes sure that when your management service is compromised, it does not affect the servers the management server controls. We've done that work.

Say we have a daemon though - the daemon would require root access in order to create user accounts. If the management service is compromised, the user accounts can be created. That's why we've made it infeasible to access SSH keys even if the management server is compromised.