4 ms·
Not sure if others feel this way but adding this line to sudo never felt right to me... deploy ALL=(ALL) ALL I usually instead limit the deploy user to a sma
by taf2 10y ago
Not sure if others feel this way but adding this line to sudo never felt right to me...
deploy ALL=(ALL) ALL
I usually instead limit the deploy user to a smaller subset of commands e.g. the init.d script to control a service.
obviously if someone gained access to deploy user we're probably sol anyway... but it just makes it seem safer... we have a to login as an ops user to install or update things on the boxes.
- codelitt 10y agoSomeone on /r/netsec rightly pointed out that you shouldn't ever add a user directly to sudoers anyways. You should add them to the sudo or wheel group. I've since updated the article. What I've described is a more of a base, but according the Principle of Least Privilege you could go even one step further and do what you're suggesting. You'd probably want to have a couple of users though. An admin user, a deploy user, and a maintain user all with different privileges.
- vacri 10y ago> you shouldn't ever add a user directly to sudoers anyways What was the reason for that? I have the deploy user able to run a couple of individual commands without a sudo password (scripts that run canned updates, to be initiated from a buildserver), but I don't see how it would improve things to use a group instead that only holds that user.
- mwpmaybe 10y agoI prefer to grant my person-user access to run any command as deploy, so I can kick off deployments from a remote machine using Ansible: - include: deploy.yml become: yes become_user: deploy And grant separate access for my person-user to restart services as root. And use sudo groups.