Users on minion changing password in user states?
59 views
Skip to first unread message
Jason Toothaker
Jun 30, 2016, 10:59:13 AM6/30/16
to Salt-users
Hello, I'm pretty new to Salt, only been working with it for a couple weeks, and I'm trying to figure out a way to allow users on a minion to change their password without having access to the master.
Is there a way to script a salt state that would recognize if a user's password was changed in the shadow file on a host and reflect that change in the user's state file?
Essentially, I'm looking for a way to allow a user to change his or her password on a host, and have that change reflected across all minions when the state is applied to them.
Is there a way to script a salt state that would recognize if a user's password was changed in the shadow file on a host and reflect that change in the user's state file?
Essentially, I'm looking for a way to allow a user to change his or her password on a host, and have that change reflected across all minions when the state is applied to them.
Let me know if this can be done!
Thanks
Thanks
Jason
Christopher Baklid
Jun 30, 2016, 2:58:02 PM6/30/16
to Salt-users
This is an interesting one, at the moment I can't think of a "simple solution" given the constraints, but...
With that in mind, I'd recommend setting up the REST API and maybe hooking up a little web interface for the user to issue the command through.
Having thought a little about it, I would give the person explicit permission to the salt-master to only be allowed to issue one specific command, this can be achieved using the external authentication
With that in mind, I'd recommend setting up the REST API and maybe hooking up a little web interface for the user to issue the command through.
That way you don't expose direct access to the salt-master host and the person who needs to change passwords for all their minions can do so without bothering you for to change it in the pillars/states
And while I was writing this I recalled this:
the peer system, to have minions issue commands directly to eachother, but I can say whether that would help your use case or not
I hope you can draw some inspiration from any of this
Jason Toothaker
Jun 30, 2016, 3:21:00 PM6/30/16
to Salt-users
Thank you for your help! I did look into configuring eauth to allow our users to use shadow.set_password commands, but then i think it would allow users to change the password for other users. We only have about 10 users, but want to be able to allow them to change their passwords without changing another user's, either intentionally or by accident. I don't have experience with REST APIs, would it constrain a user to changing only their password and not another user's?
I'm reading up on the peer communication bit now. Thank you again!
Jason
Jason
Jason Toothaker
Jun 30, 2016, 3:56:41 PM6/30/16
to Salt-users
The ideal scenario (and simplest, IMO) would be a user on a minion using a command via eauth or publisher ACL which would change the pillar data for 'passwd' for only their own userID. I'm just not sure how to restrict a user's ability to only change their own pillar data and not anyone else's.
Jeff
Jun 30, 2016, 4:42:41 PM6/30/16
to salt-...@googlegroups.com
Not sure if this is doable in your environment, but have you considered looking into an centralized identity management system that handles SSO and simply using Salt to provision the minions to integrate with the external system?
We recently implemented FreeIPA for our Ubuntu lab and development systems (300+ and growing) to remove the shared user/password we had been using. Now I use my own user and if I change my password, it works on all systems. It presents users to the system like a local user via PAM I believe. At least I have been able to configure my salt master using my FreeIPA user permissions in the external_auth:pam settings.
We recently implemented FreeIPA for our Ubuntu lab and development systems (300+ and growing) to remove the shared user/password we had been using. Now I use my own user and if I change my password, it works on all systems. It presents users to the system like a local user via PAM I believe. At least I have been able to configure my salt master using my FreeIPA user permissions in the external_auth:pam settings.
It can get a little quirky if you are installing on an unofficially supported OS or are cloning VM's that already have been configured, but overall, I like being able to use the same login and not have to worry about insecure shared accounts or changing passwords on many systems.
It is essentially an LDAP server with an agent that runs and communicates with a central server (+ replicas). Systems are "joined" to the IPA database and access (including SUDO and DNS) can be managed from IPA if you want to go that route. You can create "auto groups" where based on name and such they will be put into a group of servers and automatically get the permissions and rules configured for that group which is handy for lab environments where most systems have the same access needs by all users.
Anyway, another option to consider at least. There may be other similar systems that could be better. It also apparently manages SSH keys and certificates, but I haven't gotten in that far yet.
-Jeff
--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Jason Toothaker
Jul 1, 2016, 8:22:48 AM7/1/16
to Salt-users
Thank you for the insight Jeff. I'll look into FreeIPA today.
Reply all
Reply to author
Forward
0 new messages