16. Security Best Practices¶

16.3.1. Minimize administrative accounts¶

Minimizing the access to system administrative accounts is crucial for maintaining a secure system. A system administrator/root user can access, edit, and disrupt any system application. Keep the number of people/accounts with root access to as small of a group as possible. Do not give out sudo to root or awx (the controller user) to untrusted users. Know that when restricting administrative access via mechanisms like sudo, that restricting to a certain set of commands may still give a wide range of access. Any command that allows for execution of a shell or arbitrary shell commands, or any command that can change files on the system, is fundamentally equivalent to full root access.

In a controller context, any controller ‘system administrator’ or ‘superuser’ account can edit, change, and update any inventory or automation definition in the controller. Restrict this to the minimum set of users possible for low-level controller configuration and disaster recovery only.

16.3.2. Minimize local system access¶

automation controller, when used with best practices, should not require local user access except for administrative purposes. Non-administrator users should not have access to the controller system.

16.3.3. Remove access to credentials from users¶

If an automation credential is only stored in the controller, it can be further secured. Services such as OpenSSH can be configured to only allow credentials on connections from specific addresses. Credentials used by automation can be different than credentials used by system administrators for disaster-recovery or other ad-hoc management, allowing for easier auditing.

16.3.4. Enforce separation of duties¶

Different pieces of automation may need to access a system at different levels. For example, you may have low-level system automation that applies patches and performs security baseline checking, while a higher-level piece of automation deploys applications. By using different keys or credentials for each piece of automation, the effect of any one key vulnerability is minimized, while also allowing for easy baseline auditing.

16.4.1. Audit and logging functionality¶

For any administrative access, it is key to audit and watch for actions. For the system overall, this can be done via the built in audit support (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/chap-system_auditing.html) and via the built-in logging support.

For automation controller, this is done via the built-in Activity Stream support that logs all changes within the controller, as well as via the automation logs.

Best practices dictate collecting logging and auditing centrally, rather than reviewing it on the local system. It is recommended that automation controller be configured to use whatever IDS and/or logging/auditing (Splunk) is standard in your environment. automation controller includes built-in logging integrations for Elastic Stack, Splunk, Sumologic, Loggly, and more. See Logging and Aggregation for more information.

16.4.2. Existing security functionality¶

Do not disable SELinux, and do not disable the controller’s existing multi-tenant containment. Use the controller’s role-based access control (RBAC) to delegate the minimum level of privileges required to run automation. Use Teams in the controller to assign permissions to groups of users rather than to users individually. See Role-Based Access Controls in the Automation Controller User Guide.

16.4.3. External account stores¶

Maintaining a full set of users just in the controller can be a time-consuming task in a large organization, prone to error. Automation controller supports connecting to external account sources via LDAP, SAML 2.0, and certain OAuth providers. Using this eliminates a source of error when working with permissions.

16.4.4. Django password policies¶

Controller admins can leverage Django to set password policies at creation time via AUTH_PASSWORD_VALIDATORS to validate controller user passwords. In the custom.py file located at /etc/tower/conf.d of your controller instance, add the following code block example:

AUTH_PASSWORD_VALIDATORS = [
    {
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
        'OPTIONS': {
            'min_length': 9,
        }
    },
    {
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
]

For more information, see Password management in Django in addition to the example posted above.

Be sure to restart your controller instance for the change to take effect. See Starting, Stopping, and Restarting the Controller for detail.