Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/288#issuecomment-105133656
The issue now is that root credentials for the host are stored in the db,
and even echoed back if you ask to list hosts with details. It's a huge step
forward to have a single user who only has access to run
cloudstack-setup-agent. Perhaps you don't have the same root everywhere, but
you don't have to have the same non-root user/password everywhere, either. You
can even remove/disable this user after the host is added.
In addition, many places don't allow root to SSH as a basic infosec policy.
I'd like us to get out of the business of dictating and conflicting with
configuration management, where possible, including things suggested like
changing passwords upon agent setup. These things will rub big shops who have
their config management story together the wrong way, and we already do way too
much (like touching iptables and libvirt settings) IMO. They also confuse
newbies more than they help ("why can't I log in anymore?", and I've heard a
lot of "why did my networking get screwed up and restart?" from the existing
setups scripts).
Also re: agent listening, I don't think we want the agent to listen. It
has been a huge boon to have all ports closed on the hypervisor except SSH,
everywhere I've gone, from an infosec standpoint. I'm also not sure there's a
meaningful gain by having the mgmt server contact the host via a listening
agent port vs contacting the host via SSH and a user who has no access other
than to run setup. I'm also more confident that SSH would pass a penetration
test.
An easy fix that I think would accommodate everyone at this point is to
only use 'sudo' if the user passed in is not 'root'. Then everyone doing it the
current way is unaffected by the sudo and requiretty, and people who want to
only pass non-root credentials to cloudstack mgmt server can do that as well
with a sudoers line for cloudstack-agent-setup and a -t for the sudo (or
perhaps just document the requiretty along with the sudoers line).
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
