Open Stack

On 13 January 2016 at 15:10, Major Hayden <major at mhtx.net> wrote:

>
> For example, the STIG requires[1] that all system accounts other than root
> are locked.  This could be dangerous on a running production system as
> Ubuntu has non-root accounts that are not locked.  At the moment, the
> playbook does a hard stop (using the fail module) when this check
> fails[2].  Although that can be skipped with --skip-tag, it can be a little
> annoying if you have automation that depends on the playbook running
> without stopping.
>
> Is there a good alternative for this?  I've found a few options:
>
>   1) Leave it as-is and do a hard stop on these tasks
>   2) Print a warning to the console but let the playbook continue
>   3) Use an Ansible callback plugin to catch these and print them at the
> end of the playbook run
>
> Thanks in advance for any advice!
>
> [1]
> https://www.stigviewer.com/stig/red_hat_enterprise_linux_6/2015-05-26/finding/V-38496
> [2]
> https://github.com/openstack/openstack-ansible-security/blob/master/tasks/auth.yml#L60-L87


I think the best thing to do here is to take a stance on what the
project/role deems to be a good set of defaults for the environment its
catering for. Whatever that stance is should be rigorously enforced (ie the
playbook should hard stop if there is non-compliance).

For anyone using automation, if they wish to skip particular compliance
elements then they should build the skip into their automation (ie add
--skip-tags). Skipping compliance should be a conscious action implemented
deliberately by the consumer of the role.

Darren's reply is interesting and perhaps worth consideration. As far as I
recall the security role adopted the STIG primarily because it was the only
openly available set of standards that didn't require licensing. If there
are other options to explore and ways to consume them, then perhaps that
should be an initiative for the Newton cycle?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160208/65b757ec/attachment.html>