As you build up your roles and playbooks to implement security baselines, you will discover that some of your implementation will be cut and dried (for example, you will almost certainly know whether you want root SSH logins to be possible or not), whereas there will be decisions to be made for other aspects. Time synchronization is one such example, and in this section, we will explore this in more detail to demonstrate the kinds of decisions you can expect to make when designing your roles, as well as how to address them in a constructive manner.

If you review section 2.2.1 of the RHEL 7 CIS Benchmark (version 2.2.0), you will see that it is entirely concerned with time synchronization. Indeed, this is an important function in just about every Enterprise Linux infrastructure, and discrepancies between the clocks on servers can cause issues such as with certificate validity and Kerberos tickets.

Although it is almost universally agreed that time synchronization is vitally important, there is less agreement on the way to achieve it. For example, there are two main time synchronization services available for most mainstream Linux distributions:

• chrony
• ntpd 

Although chrony is now the standard on RHEL 7, this does not mean that the venerable ntpd service will no longer work – in fact, some enterprises still choose to implement this because they have extensive experience with it.

It is entirely possible to get Ansible to detect which of these two services a given Linux server is using – at a high level, we could get Ansible to do the following:

1. Query the RPM package database to see whether ntpd, chrony, or both are installed.
2. If one or both are installed, detect which one is active:

a. If neither are active, this needs rectifying as we have established the need for time synchronization.

b. If both are active, the services will clash and one should be disabled. 

As I'm sure you will see, there comes a point in the preceding process where an intervention is required – if neither service is started, we need to choose one to start. If both are active, we need to disable one. This is where Ansible's ability to help ends – it cannot decide for your particular enterprise which of these two perfectly valid services is best for your use case.

Thus, it is important to make a decision up-front about which time synchronization service you are using. With this decision made, playbooks can then be specifically coded to perform the appropriate checks and equally perform the appropriate remediation steps as required. In addition, we know from our discussion in Chapter 1, Building a Standard Operating Environment on Linux, that automation at enterprise scale is supported by commonality and standards – so we know from these principles that we should choose a standard time synchronization service and stick with it except where there is a good business reason to raise an exception.

To progress this example, let's look at recommendation 2.2.1.1. This states that we should ensure that a time synchronization service is in use – though it is agnostic about which one. If we have made our decision up-front about which service is relevant, our playbook development is easy. Suppose we have chosen chrony (the default for RHEL 7); our role for this recommendation might be as follows:

---
- name: 2.2.1.1 Ensure time synchronization is in use (Not Scored - L1S L1W)
  yum:
    name: chrony
    state: present

- name: 2.2.1.1 Ensure time synchronization is in use (Not Scored - L1S L1W)
  service:
    name: chronyd
    state: started

This simple code ensures that we both check for and satisfy recommendation 2.2.1.1 without the need for any logic to detect which time service is in use. Of course, we could choose to be more thorough and check that ntpd is not started, but this is left as an exercise to you.

Naturally, we cannot fit all the Ansible code that's required for the roughly 400 recommendations in this CIS Benchmark into this book – that would deserve an entire book to itself! In addition, this example is just for one benchmark – if your enterprise introduces a new operating system such as RHEL 8, you can be sure there will be a separate CIS Benchmark for this operating system that will need to be implemented. However, it is hoped that the development of these examples from the RHEL 7 CIS Benchmark is sufficient for you to design and build your own policy. Thus, in the next section of this chapter, we will look at techniques for making this task manageable at enterprise scale.