User management by ansible - any ideas ?

Archives Ansible Project
1

I would like to use ansible for our user management (I know there are software for it like LDAP but not for now …).
This is typical definition of users and their groups:

Groups and users:

  • group1

  • user1

  • user2

  • group2

  • user1

  • user2

  • user3

  • group3

  • user1

  • user2

  • user3

  • user4

The problem I have is that every server is going to have subset of all groups, i.e:

  • server1
  • group1
  • group3- server2
  • group3- server3
  • group1

Then there is a request from business/developers/managers/whatever that particular group of users should have access to particular servers so we need to modify ansible config and add e.g. group3 to server3.

Is it possible to create a role with a sort of “map” file where I could specify which server will have particular user groups
so we could modify this one (!) file, run site.yml and done (the role and its file knows where to create each group).

I would like to avoid redundancy in terms of user definitions (error prone) and have just one file with all users defined in it.

That way I could include this role in every playbook and it would automatically create (or not) particular group of users
on every host.
Is it possible to do that ?

2

You can parameterise roles, maybe that would help.
(http://docs.ansible.com/playbooks_roles.html )

Define all the group memberships in your accounts role
(accounts/defaults/main.yml)
and then in your inventory, load the accounts role into specific hosts
with a list
of the groups you want defined.

3

While reading this URL I came across the following example:


- hosts: webservers
  roles:
    - common
    - { role: foo_app_instance, dir: '/opt/a',  port: 5000 }
    - { role: foo_app_instance, dir: '/opt/b',  port: 5001 }

Can anyone show me how would the “foo_app_instance” role look like ?

4

I’m using this user role, https://github.com/mivok/ansible-users
Maybe you can take a look at this too.

5

Basically it could be anything, it would just be able to use variables like {{ port }} in the playbooks or Jinja2 templates.

6

Here’s how I solved this problem for myself: https://gist.github.com/awheeler/a3e4c500f1bb70bd31dd
You can define groups that users should be members of with a host specification that is a regex, so:

users: devdomain.net$

would say that the user should be in the users group on all hosts with ansible_fqdn that end with devdomain.net.
You can get just as complex as you want:

wheel: ((host1|differenthost2|cluster_nodes[0123])-[0-9]+.proddomain.com|devdomain.net|another.devhost.dev)$

The thing that makes this possible is the fact that you can embed complex jinja2 in the middle of an Ansible task, a fact which is not immediately apparent.

7

Here’s an easier way that avoids the messy Jinja2 in the playbook, which we as a community like to discourage (it’s the reason Ansible templates don’t evaluate into YAML, but are YAML… Jinja2 is intended to be just a quick way to get variables, unless you are in a template)

In ansible, a host specification that is a regex starts with “~”

hosts endsing in devdomain or qadomain:

hosts: “~(devdomain.net|qadomain.net)$”

Thus you can have multiple plays in the playbook

Etc

8

I think I get where you are going with the idea of different plays, but they way I understand it, I would need a different play for every user that had different host/group requirements.
So, with 100+ users, 70 might need the same access for a given set of hosts (1 play), but there could be 30 that have unique requirements. So, that means 31 plays, and probably logging into some of the servers in question 31 times.
Ugh! I am not a huge fan of my creation (it’s not clean and elegant, though the line-breaks make it better), other than the fact it is very flexible, and reasonably efficient. I would love to be able to convert it to something more consistent with what the community recommends, but I don’t see how to do it without possibly creating a different play for every user.

With my solution, every host is only accessed once, and each user can have a different host regex for each group, and the full definition of what permissions a user has is all in once place.

9

“I think I get where you are going with the idea of different plays, but they way I understand it, I would need a different play for every user that had different host/group requirements.”

Definitely not.

This is where useful things like “with_items” come in, and you can do

“with_items: myusers”.

Thus you can still keep one play that uses a variable to source the list of users, and that variable can come from things like group_vars.

10

The problem with this approach is that it requires the servers name to be similar (regex).
In our case the servers name could be totally different so it won’t work (perhaps …)

11

“The problem with this approach is that it requires the servers name to be similar (regex).”

You should use groups. We recommend this in nearly all cases, hardly anyone is using host patterns matched by regex.

If using cloud services, tags also automatically form groups, which is highly useful, as servers can self-declare what groups they are in.