Ansible for Lazy Admins

Jordan Drysdale //

ADVISORY: The techniques and tools referenced within this blog post may be outdated and do not apply to current situations. However, there is still potential for this blog entry to be used as an opportunity to learn and to possibly update or integrate into modern tools and techniques.

For the lazy server and system admins, automating those boring functions of updating packages, finding outdated ones, checking scans, et cetera, Ansible has some very nice features. Here is a quick breakdown on some of those features I have found to be very useful (throughout post, useful stuff in bold).

First, do yourself a favor and run through the best practices – here. This software is useful and amazing for so many reasons, best summarized as agentless ssh key-auth based systems administration. For the security minded admins, review “CSC 2: Inventory of Authorized and Unauthorized Software” – here. Let’s say we approve only a particular kernel version and need to know if we have servers that have fallen out of line with approvals:

system:~$ ansible droplets -m shell -a "dpkg -l |grep linux-image*" -u ansible -K
ii  linux-image-3.13.0-85-generic           3.13.0-85.129                amd64                              
Linux kernel image for version 3.13.0 on 64 bit x86 SMP
ii  linux-image-extra-3.13.0-85-generic 3.13.0-85.129                amd64                            
Linux kernel extra modules for version 3.13.0 on 64 bit x86 SMP

Or, if we have a version of everyone’s second favorite text editor that has been identified in a recent CVE:

system:~$ ansible droplets -m shell -a "dpkg -l |grep nano" -u ansible -K | SUCCESS | rc=0 >>
ii  nano    2.2.6-1ubuntu1     amd64    small, friendly text editor inspired by Pico | SUCCESS | rc=0 >>
ii  nano     2.2.6-1ubuntu1    amd64    small, friendly text editor inspired by Pico

The above chunked commands are considered ad-hoc. Let’s take a look at a YAML file to see what a playbook looks like. Playbooks can be run against all hosts, or subsets depending on your hosts.conf file. This is an apt specific .yml file for updating all packages.

It can’t be that easy, can it? I can run this on ALL of my servers at once? Yup, and let’s do it!

system:/etc/ansible$ ansible-playbook -l droplets roles/common/tasks/apt.yml -u ansible -K

PLAY [all] *********************************************************************

TASK [setup] ******************************************************************

ok: []
ok: []

TASK [Check if there are packages available to be installed/upgraded] **********

changed: []    ###changed here means apt-get upgrade
changed: []

TASK [Upgrade all packages to the latest version] ******************************

changed: []    ###changed here means apt-get upgrade
changed: []

TASK [Check if a reboot is required] *******************************************

ok: []
ok: []

TASK [Reboot the server] *******************************************************

skipping: []
skipping: []

PLAY RECAP *********************************************************************         : ok=4        changed=2        unreachable=0        failed=0         : ok=4        changed=2        unreachable=0        failed=0  

Okay, that’s fine and dandy, how about a reboot and a quick check of uptime? These .yml files are super simple, very useful and extremely handy. Again, if you were lazy and didn’t want to touch much of anything, you might want to start digging in to Ansible’s functionality.

Commands for these:

system:/etc/ansible$ ansible-playbook -l droplets roles/common/tasks/reboot.yml 
-u ansible -K
system:/etc/ansible$ ansible-playbook -l droplets roles/common/tasks/uptime.yml 
-u ansible -K

Next, let’s say I have a very standard way of deploying ssh across my servers and I want it to be super easy. My ssh.yml file will look like this:

- hosts: all
  become: yes
   - name: configure ssh options to system spec
         template: src=/etc/ansible/roles/common/templates/ssh.conf.j2 
          - restart ssh
          - force ssh update
         tags: ssh
   - name: be sure ssh is running and restarted
         service: name=ssh state=restarted enabled=yes
         tags: ssh

Note the ssh.conf.J2 – this is a standard for deploying templates with Ansible. I have also invested a fair amount of time in creating similar YAML files for deploying ntp, fail2ban, filebeat, sendmail, nginx and a ton of other packages. My favorite one so far, and that is earning me the best of the laziest title, takes a combination of iptables to filter server access services by whitelist, then deploys fail2ban with a generic jail.local file to block malicious auth attempts against various services. Then lastly, it dumps a fully TLS enabled filebeat logger back through a firewall port into an elk stack!


- hosts: all  
  become: yes
   - name: CAREFUL ## deploy canned iptables ruleset ## CAREFUL
         copy: src=/etc/ansible/roles/common/templates/iptables.rules.j2 
         tags: iptables
   - name: CAREFUL ## deploy firewall u+x file to enable iptables rules ## CAREFUL
         copy: src=/etc/ansible/roles/common/templates/firewall.j2 
         dest=/etc/network/if-up.d/firewall        mode="a+x"
         tags: firewall


- hosts: all
  become: yes
      - name: Install fail2ban
          apt: pkg=fail2ban state=installed update-cache=yes
          register: fail2ban_install
          tags: fail2ban
        - name: Install config
          template: src=jail.local.j2 dest=/etc/fail2ban/jail.local
            - reload fail2ban


- hosts: all
  become: yes
   - name: add apt_key for filebeat
         apt_key: url= 
         tags: apt_key filebeat
   - name: add apt_repo for elastic software
           repo: "deb stable main"
         tags: filebeat repo         
   - name: install filebeat
         apt: pkg=filebeat state=installed update_cache=true
         tags: filebeat
   - name: create remote directory structure /etc/pki/tls/certs
         file: path=/etc/pki/tls/certs state=directory mode=0755
         tags: filebeat tls directories 
   - name: copy over the tls verification cert for secure logging
         copy: src=/etc/ansible/roles/common/files/logstash-forwarder.crt 
         dest=/etc/pki/tls/certs mode=0755
           - restart filebeat
         tags: filebeat
   - name: deploy standardized internal network config via template
         template: src=/etc/ansible/roles/common/templates/filebeat.conf.j2 
         tags: filebeat config template
   - name: be sure filebeat is running
         service: name=filebeat state=restarted enabled=yes
         tags: filebeat

Basically, from a Linux administration perspective, Ansible is an excellent choice. What we just went through here is basically still entirely ad-hoc – I stand up a server, create a new user called Ansible, add some keys for authentication and start running playbooks and command scripts. Even better, we can use roles to do almost all of this for us and if we are using AWS or Digital Ocean. Even better yet, we can pre-bake keys and users. If you get to this point, take a look at this last hyperlink – it describes how to bake all of your .yml scripts into a single playbook for use as a “bootstrapper.” Build a Linux box, add a key for Ansible to authenticate with, in five minutes I have a system online, fully firewalled, logging enabled, configured to spec, completely patched, booted and contributing services to digital hyperspace.

Want to learn more mad skills from the person who wrote this blog?

Check out this class from Kent and Jordan:

Defending the Enterprise

Available live/virtual and on-demand!