Using RHEL 8 and cloud-init and have a need to specify sudo rules for a group NOT a user. For example the wheel group in sudoers. I have users that are authenticated using radius and not added to the system explicitly, radius puts them in a group that is not wheel (I do not have control over this). I just need cloud-init to throw in a %mygroup ALL=(ALL) NOPASSWD:ALL in sudoers or sudoers.d. I don't see an option in documentation for this, is there another or better way?
https://cloudinit.readthedocs.io/en/latest/topics/modules.html?highlight=group#users-and-groups
Related
I am the sudo user (main_user) of my server (redhat8) and have many user accounts (user1, user2,....).
I can run installed application in server using main_user account but the other users are not able to execute the program or run the application.
** I have installed the applications/programs from main_user account which is not a root user but having sudo previlages.
What can be done to make the application and programs available to other users as well.
What I tried:
I have made alias in both ./bashrc and profile.d/all_user.sh, and source them but no luck.
You can implement sudo. First in /etc/sudoers file add line like:
user1,user2,user2 ALL=/path/to/the/program
If the users above are in specific group you can add something like:
%usergroup ALL=/path/to/the/program
And run the program like:
sudo -u main_user /path/to/the/program
When running a saltstack, for security reasons I don't want them to run as root. Although I would not mind creating a new 'salt' user with NOPASS sudo access to run the salt minion / master on.
My question is that even though the documentation says here: https://docs.saltstack.com/en/latest/ref/configuration/nonroot.html that we can configure salt to run as a non root user, does it append sudo to normal commands instead or looses that functionality entirely.
Additional Research: Both the master and the minion config files have an uption for setting the users to anything other than root but the minion config file has an option to setup a sudo-user which defaults to saltdev but I changed to root. Not sure if this implies that the minion should sudo and use the root account or not. If so, why is this not present on the master config file.
The direct answer to the title question is NO. As stated in the docs:
[...] running the minion as an unprivileged user will keep it from making changes to things like users, installed packages, etc. unless access controls (sudo, etc.) are setup on the minion to permit the non-root user to make the needed changes.
In order to setup sudo on the minion you should use the sudo_user config. After setting a user to this variable Salt will invoke the salt.module.sudo every time a command is issued to this minion.
This sudo option is only available on the minion because the execution of commands on hosts is intended to be made only by the minion. Even if you are managing your master with Salt, the minion inside the master is what runs the commands.
On a vagrant box precise64 (ubuntu 12.04)
While creating a user resource with Chef, the home directory is not created:
My recipe:
user "myuser" do
supports :manage_home => true
shell "/bin/bash"
home "/home/myuser"
comment "Created by Chef"
password "myencryptedpassword"
system true
provider Chef::Provider::User::Useradd
action :create
end
When I authenticate:
$ su - myuser
Password:
No directory, logging in with HOME=/
Update - The workaround for precise64 (Ubuntu 12.04 64bit)
directory "/home/myuser" do
owner "myuser"
group "myuser"
mode 00755
action :create
end
While system users usually don't have a home dir, chef will create the home dir even for system users if you specify home. I've tried it, and cannot reproduce the issue.
What is going on is a little bit hidden in the documentation. The chef documentations says:
system | Use to create a system user. This attribute may be used with useradd as the provider to create a system user which passes the -r flag to useradd.
If have a look at the man page of useradd:
-r, --system
Create a system account.
System users will be created with no aging information in /etc/shadow,
and their numeric identifiers are chosen in the SYS_UID_MIN-SYS_UID_MAX
range, defined in >/etc/login.defs, instead of UID_MIN-UID_MAX
(and their GID counterparts for the creation of groups).
Note that useradd will not create a home directory for such an user,
regardless of the default setting in /etc/login.defs (CREATE_HOME).
You have to specify the -m options if you want a home directory for
a system account to be created.
However, it seems like chef is passing the -m option explicitly if you specify a home dir. I could not reproduce this issue therefore.
Did you add the home attribute to the recipe after the user was already created? When I was first hacking around with creating a system user, I didn't add the :manage_home and home bits to the recipe until after I had run the recipe and verified that the user was created. Subsequent runs of the recipe after adding home directory management and the home attribute didn't actually work until I deleted the user and run the recipe again.
I assume that useradd won't execute again if the user already exists, so adding -m via the recipe wouldn't happen unless and until the user is deleted and the recipe re-runs against a clean system and sends useradd -rm.
I was able to reproduce this problem and work around it.
The hint was in the chef docs for the user resource.
"[homedir] will be created unless CREATE_HOME in /etc/login.defs is set to no". On a fresh Ubuntu install that line did not exist. Perhaps it defaults to no if missing.
In /etc/login.defs I added:
CREATE_HOME yes
Once that was added my chef run would complete and create the homedir allowing my to then modify contents of the user homedir. This method may be simpler than manually creating homedirs for each user.
Background
My question seems simple, but it gets more complex really fast.
Basically, I got really tired of maintaining my servers manually (screams in background) and I decided it was time to find a way to make being a server admin much more liveable. That's when I found Ansible. Great huh? Sure beats making bash scripts (louder scream) for everything I wanted to automate.
What's the problem?
I'm having a lot of trouble figuring out what user my Ansible playbook will run certain things as. I also need the ability to specify what user certain tasks will run as. Here are some specific use cases:
Cloning a repo as another user:
My purpose with this is it run my node.js webapp from another user, who we'll call bill (that can only use sudo to run a script that I made that starts the node server, as opposed to root or my user that can use sudo for all commands). To do this, I need the ability to have Ansible's git module clone my git repo as bill. How would I do that?
Knowing how Ansible will gain root:
As far as I understand, you can set what user Ansible will connect to the server you're maintaining by defining 'user' and the beginning of the playbook file. Here's what I don't understand: if I tell it to connect via my username, joe, and ask it to update a package via the apt module, how will it gain root? Sudo usually prompts me for my password, and I'd prefer keeping it that way (for security).
Final request
I've scoured the Ansible docs, done some (what I thought was thorough) Googling, and generally just tried to figure it out on my own, but this information continues to elude me.
I am very new to Ansible, and while it's mostly straight-forwards, I would benefit greatly if I could understand exactly how Ansible runs, on which users it runs, and how/where I can specify what user to use at different times.
Thank you tons in advance
You may find it useful to read the Hosts and Users section on Ansible's documentation site:
http://docs.ansible.com/playbooks_intro.html#hosts-and-users
In summary, ansible will run all commands in a playbook as the user specified in the remote_user variable (assuming you're using ansible >= 1.4, user before that). You can specify this variable on a per-task basis as well, in case a task needs to run as a certain user.
Use sudo: true in any playbook/task to use sudo to run it. Use the sudo_user variable to specify a user to sudo to if you don't want to use root.
In practice, I've found it easiest to run my playbook as a deploy user that has sudo privileges. I set up my SSH keys so I can SSH into any host as deploy without using a password. This means that I can run my playbook without using a password and even use sudo if I need to.
I use this same user to do things like cloning git repos and starting/stopping services. If a service needs to run as a lower-privileged user, I let the init script take care of that. A quick Google search for a node.js init.d script revealed this one for CentOS:
https://gist.github.com/nariyu/1211413
Doing things this way helps to keep it simple, which I like.
Hope that helps.
My 2 cents:
Ansible uses your local user (eg Mike) to ssh to the remote machine. (That required Mike to be able to ssh to the machine)
From there it can change to a remote user if needed
It can also sudo if needed and if Mike is allowed. If no user is specified then root will be selected via your ~/.ansible.cfg on your local machine.
If you supply a remote_user with the sudo param then like no.3 it will not use root but that user.
You can specify different situations and different users or sudo via the playbooks.
Playbook's define which roles will be run into each machine that belongs to the inventory selected.
I suggest you read Ansible best practices for some explanation on how to setup your infrastructure.
Oh and btw since you are not referring to a specific module that ansible uses and your question is not related to python, then I don't find any use your question having the python tag.
Just a note that Ansible>=1.9 uses privilege escalation commands so you can execute tasks and create resources as that secondary user if need be:
- name: Install software
shell: "curl -s get.dangerous_software.install | sudo bash"
become_user: root
https://ansible-docs.readthedocs.io/zh/stable-2.0/rst/become.html
I notice current answers are a bit old and suffering from link rot.
Ansible will SSH as your current user, by default:
https://docs.ansible.com/ansible/latest/user_guide/intro_getting_started.html#connecting-to-remote-nodes
Ansible communicates with remote machines over the SSH protocol. By default, Ansible uses native OpenSSH and connects to remote machines using your current user name, just as SSH does.
This can be overridden using:
passing the -u parameter at the command line
setting user information in your inventory file
setting user information in your configuration file
setting environment variables
But then you must ensure a route exists to SSH as that user. An approach to maintaining user-level ownership I see more often is become (root) and then to chown -R jdoe:jdoe /the/file/path.
In my 2.12 release of ansible I found the only way I could change the user was by specifying become: yes as an option at the play level. That way I am SSHing as the unprivileged, default, user. This user must have passwordless sudo enabled on the remote and is about the safest I could make my VPS. From this I could then switch to another user, with become_user, from an arbitrary command task.
Like this:
- name: Getting Started
gather_facts: false
hosts: all
become: yes # All tasks that follow will become root.
tasks:
- name: get the username running the deploy
command: echo $USER
become_user: trubuntu # From root we can switch to trubuntu.
If the user permitted SSH access to your remote is, say, victor, and not your current user, then remote_user: victor has a place at the play level, adjacent to become: yes.
What I'm basically trying to do is allow jenkins access my android-sdk-linux folder and all the sub-directories. My boss does not want to change permissions on the folder himself. I am supposed to do it during the build process. I have seen some examples that run some commands in the execute shell during the build process. Is there some commands that can I can run in that execute shell so that jenkins can have read write and execute authority on my android-sdk-linux folder?
As bcolfer said, you should be able to just run your shell commands with "sudo" in front of it. You will want to be sure that the user that started the Jenkins slave is a sudoer.
As root, run "visudo", this will open the /etc/sudoers file. At the bottom add a line similar to this if it is not a current sudoer:
jenkins ALL=(ALL) NOPASSWD: ALL
"Jenkins" being the user that started the slave.
OR
You could try adding the user to the group that owns that directory. IF you run "ls -l" you should be able to see the permissions and then the user, and the group that owns the directory. Once you know the group, as root run:
usermod -a -G group Jenkins
"Jenkins" being the user that started the slave, and "group" being the actual group name.
One possibility is to use sudo to run commands that specifically target those files. There are a bunch of ways to manage the sudo privileges limit and log what actions happen on those files.