{"id":3387,"date":"2018-05-28T18:02:02","date_gmt":"2018-05-28T23:02:02","guid":{"rendered":"https:\/\/dev.iachieved.it\/iachievedit\/?p=3387"},"modified":"2018-05-28T18:02:02","modified_gmt":"2018-05-28T23:02:02","slug":"ansible-and-aws-part-5","status":"publish","type":"post","link":"https:\/\/dev.iachieved.it\/iachievedit\/ansible-and-aws-part-5\/","title":{"rendered":"Ansible and AWS – Part 5"},"content":{"rendered":"

In Part 5 of our series, we’ll explore provisioning users and groups with Ansible<\/a> on our AWS<\/a> servers.<\/p>\n

Anyone who has had to add users to an operating environment knows how complex things can get in a hurry. LDAP<\/a>, Active Directory<\/a>, and other technologies are designed to provide a centralized repository of users, groups, and access rules. Or, for Linux systems, you can skip that complexity and provision users directly on the server. If you have a lot of servers, Ansible can easily be used to add and delete users and provision access controls.<\/p>\n

Now, if you come from an “enterprise” background you might protest and assert that LDAP is the only<\/i> way to manage users across your servers. You’re certainly entitled to your opinion. But if you’re managing a few dozen or so machines, there’s nothing wrong (in my book) with straight up Linux user provisioning.<\/p>\n

Regardless of the technology used, thought must still be given to how your users will be organized, and what permissions users will be given. For example, you might have operations personnel that require sudo<\/code> access on all servers. Some of your developers may be given the title architect<\/code> which provides them the luxury of sudo<\/code> as well on certain servers. Or, you might have a test group that is granted sudo<\/code> access on test servers, but not on staging servers. And so on. The point is, neither LDAP, Active Directory, or Ansible negate your responsbility of giving thought to how users and groups are organized and setting a policy around it.<\/p>\n

So, let’s put together a team that we’ll give different privileges on different systems. Our hypothetical team looks like this:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n<\/table>\n

We’ve decided that access on a given server (or environment) will follow these rules:<\/p>\n

Name<\/th>\nGroup<\/th>\n<\/tr>\n
alice<\/td>\narchitects<\/td>\n
bob<\/td>\ndevelopers<\/td>\n
carol<\/td>\noperations<\/td>\n
dave<\/td>\ntesters<\/td>\n
dave<\/td>\ntptesters<\/td>\n
\n\n\n\n\n\n
Environment<\/td>\nAccess<\/th>\n<\/tr>\n
production<\/td>\nOnly architects and operations gets access to the environment, and they get `sudo` access<\/td>\n
staging<\/td>\nAll users except tptesters get access to the environment, only architects, operations, and developers get `sudo` access<\/td>\n<\/tr>\n
test<\/td>\nAll users get access to the environent, and with the exception of `tptesters`, they get `sudo` access<\/td>\n<\/tr>\n
operations<\/td>\nOnly operations get access to their environment, and they get `sudo` access<\/td>\n<\/tr>\n<\/table>\n

Now, let’s look at how we can enforce these rules with Ansible!<\/p>\n

users Role<\/h2>\n

We’re going to introduce Ansible roles<\/i> in this post. This is by no means a complete tutorial on roles, for that you might want to check out the Ansible documentation<\/a>.<\/p>\n

Note: git clone https:\/\/github.com\/iachievedit\/ansible-helloworld<\/code> to get the example repository for this series, and switch to part4<\/code> (git checkout part4<\/code>) to pick up where we left off.<\/p>\n

Let’s get started by creating our roles<\/code> directory in ansible-helloworld<\/code>.<\/p>\n

[code lang=text]
\n# git clone https:\/\/github.com\/iachievedit\/ansible-helloworld
\n# cd ansible-helloworld
\n# git checkout part4
\n# mkdir roles
\n[\/code]<\/p>\n

Now we’re going to use the command ansible-galaxy<\/code> to create a template (not to be confused with a Jinja2 template!) for our first role.<\/p>\n

[code lang=text]
\n# cd roles
\n# ansible-galaxy init users
\n– users was created successfully
\n[\/code]<\/p>\n

Drop in to the users<\/code> directory that was just created and you’ll see:<\/p>\n

[code lang=text]
\n# cd users
\n# ls
\nREADME.md files meta templates vars
\ndefaults handlers tasks tests
\n[\/code]<\/p>\n

We’ll be working in three directories, vars<\/code>, files<\/code>, and tasks<\/code>. In roles\/vars\/main.yml<\/code> add the following:<\/p>\n

\n---\nusergroups:\n  - architects\n  - developers\n  - operations\n  - testers\n  - tptesters\n\nusers:\n  - {name:  alice, group: architects}\n  - {name:  bob,   group: developers}\n  - {name:  carol, group: operations}\n  - {name:  dave,  group: testers}\n  - {name:  eve,   group: tptesters}\n<\/pre>\n
Recall in previous tutorials our variables definitions were simple tag-value pairs (like HOSTNAME:  helloworld<\/code>).  In this post we’re going to take advantage of the fact that variables can be complex types that include lists and dictionaries.<\/p>\n
Now, let’s create our users<\/code> role tasks.  We’ll start with creating our groups.  In roles\/tasks\/main.yml<\/code>:<\/p>\n
\n---\n- name:  Create groups\n  group:\n    name:  \"{{ item }}\"\n    state: present\n  loop:  \"{{ usergroups }}\"\n<\/pre>\n
There’s another new Ansible keyword in use here, loop<\/code>.  loop<\/code> will take the items in the list<\/i> given by usergroups<\/code> and iterate over them, with each item being “plugged in” to item<\/code>.  The Python equivalent might look like:<\/p>\n
\nfor item in usergroups:\n  groupadd(item) # Assume groupadd is implemented\n<\/pre>\n
Loops are powerful constructs in roles and playbooks, so make sure and review the Ansible documentation<\/a> to review what all can be accomplished with them.  Also check out Chris Torgalson’s Untangling Ansible’s Loops<\/a>,  a great overview of Ansible loops and how to leverage them in your playbooks.  It also turns out this post is using loops and various constructs to provision users, so definitely compare and contrast the different approaches!<\/p>\n
Our next Ansible task will create the users and<\/i> place them in the appropriate group.<\/p>\n
\n# Creating users\n- name:  Create users\n  user:\n    name:  \"{{ item.name }}\"\n    state: present\n    groups: \"{{ item.group }}\"\n  loop:  \"{{ users }}\"\n<\/pre>\n
Here it’s important to note that users<\/code> is being looped over (that is, every item in the list users<\/code>), and that we’re using a dot-notation to access values inside<\/i> item<\/code>.  For the first entry in the list, item<\/code> would have:<\/p>\n
[code lang=text]
\nitem.name = alice
\nitem.group = architects
\n[\/code]<\/p>\n
Now, we could have chosen to allow for multiple groups for each user, in which case we might have defined something like:<\/p>\n
\nusers:\n  - {name:  alice, groups: [architects, developers]}\n<\/pre>\n
That looks pretty good so we’ll stick with that for the final product.<\/p>\n
With our user definitions in hand, let’s create an appropriate task to create them in the correct environment.  There are two more keywords to introduce:  block<\/code> and when<\/code>.  Let’s take a look:<\/p>\n
\n- block:\n  - name:  Create users for production servers\n    user:\n      name:  \"{{ item.name }}\"\n      state: present\n      groups: \"{{ item.groups }}\"\n    loop:  \"{{ users }}\"\n  when:\n    - \"'production' in group_names\"\n    - \"('architects' in item.groups) or\n       ('operations' in item.groups)\"\n<\/pre>\n
The block<\/code> keyword allows us to group a set of tasks together, and is frequently used in conjunction with some type of “scoping” keyword.  In this example, we’re using the when<\/code> keyword to execute the block when a certain condition is met.  The tags<\/code> keyword is another “scoping” keyword that is useful with a block<\/code>.<\/p>\n
Our when<\/code> conditional indicates that the block will run only if the following conditions are met:<\/p>\n