ansible-hardening: provide method to skip epel-release check

[Troy Engel (RAX)]

On the RHEL/CentOS platform an honest check for EPEL is being performed here:

* https://github.com/openstack/ansible-hardening/blob/master/tasks/main.yml#L55

This fails in our environment as EPEL repo use is not always dictated by that exact package, nor any package at all (no local config file). We need a way to provide a variable to allow skipping over this check - or, perhaps, check for this package is *available* but does not have to be installed.

- if EPEL is not connected, it will fail anyways to install unless you've added to your own custom repo that isn't EPEL (possible for some folks)
- if epel-release is generically available (yum list epel-release) then EPEL is connected and does not need to have this package installed

EPEL uses a vast mirror system; for our high security customers, generically allowing egress to any IP on the mirror list is unacceptable. To solve this need, we mirror EPEL to our own infrastructure that has a defined IP list, then pull in the EPEL content to a RHN Satellite (RHEL servers) and Spacewalk (CentOS servers) for managing RHEL and CentOS systems. We then provide two methods for access:

1. a custom packaging of epel-release, renamed, that provides a yum config that only points at our local mirror (and the EPEL GPG key) of defined IPs
2. connecting it using the Satellite/Spacewalk mechanisms on the server side, which requires no 'release' package be installed on the client and uses defined IPs

Each method has it's use case (method #1 is good for a Cloud customer for instance), but in both cases the package 'epel-release' will not be installed and should not be by a playbook, so providing the task a variable to skip over this attempted package install would be enough.

A better solution might be to do something like "yum list epel-release" to ensure it's available (ergo, EPEL is connected) or similar, but it doesn't have to be installed. $0.02 on this part. :)

[Jean-Philippe Evrard (jean-philippe-evrard)]

Completely agreed we should think about this and improve how it's done.
I think I still have a patch pending on a similar topic (https://review.openstack.org/#/c/463845/3/tasks/rhel7stig/packages.yml).

We agreed that we should check if epel is available + enabled and use this as a conditional for some package installation/configuration modification.

[Troy Engel (RAX) (terackspace)]

As far as I can tell (I'm new to this playbook), we only need EPEL for certain items - clamav seems to be the big one. As my company offers a 3rd party Managed A/V solution from a proprietary vendor, the A/V requirement is fulfilled but not in any way that is applicable to this project.

Here's the general playbook I'm running so far as I tune (rough first draft, day 1):

- name: Test ansible-hardening
  hosts: all
  become: yes
  vars:
    stig_version: rhel7
    security_package_state: present
    security_rhel7_enable_linux_security_module: no
    security_enable_virus_scanner: no
    security_enable_firewalld: no
    security_require_grub_authentication: no
    security_ntp_servers:
     - <my custom time server in my datacenters>
     - 0.rhel.pool.ntp.org
     - 1.rhel.pool.ntp.org
     - 2.rhel.pool.ntp.org
     - 3.rhel.pool.ntp.org
  roles:
    - ansible-hardening

Given this, I have no EPEL packages installed after test running the playbooks a few times and working on things. So I think the entire EPEL check would benefit from a 'when:' clause that examines the input variables tied to EPEL and just skips it if no EPEL is needed. $0.02!

[Major Hayden (rackerhacker)]

Troy -- I like the epel check idea. We could look through the variables that would require EPEL to be configured and only add EPEL if it's needed.

I'll take on this work.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/480734

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/480737

[Troy Engel (RAX) (terackspace)]

The patches look good so far! The one missing item which will still fail is that we don't install the named package (see above), so having the package state: present would actually attempt to install it when I do not want it that way. It's for when you have EPEL in your Spacewalk/Satellite management layer and do not use /etc/yum.repos.d/*.repo configs locally.

my-epel-release = /etc/yum.repos.d/my-epel.repo
(no package) = Satellite / Spacewalk upstream config

So I would say that in addition to the above two PRs (thanks!) we need a conditional bool variable something like "security_epel_install_release: yes" (as the default) so it would look something like:

# EPEL repository package name
# Some deployers install a customized EPEL package that redirects servers to
# their internal EPEL mirrors. Provide the name of the EPEL repository package
# (epel-release by default on CentOS) or a URL to an EPEL release RPM file.
security_epel_install_release: yes
security_epel_release_package: epel-release

====

- name: Install EPEL repository
  yum:
    name: "{{ security_epel_release_package }}"
    state: "{{ security_package_state }}"
  when:
    - ansible_pkg_mgr == 'yum'
    - security_epel_install_release | bool
    - security_enable_virus_scanner | bool

Not sure what the AND'd version of that looks like in yaml, it's a logical "you want the clamav AND you need a release package installed" op. Perhaps the end user's clamav is somewhere in their own repos (something other than EPEL) that would satisfy without needing EPEL at all -- not my use case, but I see it as valid.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/480734
Committed: https://git.openstack.org/cgit/openstack/ansible-hardening/commit/?id=a64c833a71e4f6f28d38c866388d54b9d9565845
Submitter: Jenkins
Branch: master

commit a64c833a71e4f6f28d38c866388d54b9d9565845
Author: Major Hayden <email address hidden>
Date: Thu Jul 6 08:23:13 2017 -0500

    Conditionally install EPEL if needed

    The current behavior of the hardening role is to install the
    epel-release package on all deployments. This patch changes
    the logic to only install the EPEL repository if the deployer
    has asked for ClamAV to be installed.

    The patch also provides an option to disable the installation
    of EPEL entirely using a variable.

    Closes-Bug: 1702167
    Change-Id: I9c5e6048f95636faf2a6d71ac9217ba69ca41296

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/480737
Committed: https://git.openstack.org/cgit/openstack/ansible-hardening/commit/?id=bcce655e086067af0808dc6d7a0e7678b9a0a782
Submitter: Jenkins
Branch: master

commit bcce655e086067af0808dc6d7a0e7678b9a0a782
Author: Major Hayden <email address hidden>
Date: Wed Jul 5 15:54:21 2017 -0500

    Allow epel-release package name customization

    This patch allows deployers to provide a custom name/URL for the
    traditional epel-release package.

    Related-bug: 1702167
    Change-Id: Ie5e30776d2d25a8c254f88c16e17ea15aa38ef26

[Troy Engel (RAX) (terackspace)]

Confirmed working. :)

$ grep epel *.yml
stig_rhel7ord.yml: security_epel_install_repository: no

TASK [ansible-hardening : Install EPEL repository] *****************************
task path: ansible-hardening/tasks/rhel7stig/main.yml:56
skipping: [server1234::server1234] => {
    "changed": false,
    "skip_reason": "Conditional result was False",
    "skipped": true
}

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/ansible-hardening 16.0.0.0rc2 release candidate.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/ansible-hardening 17.0.0.0b1 development milestone.