Securing orcharhino

orcharhino uses firewalld. It is enabled by default on every Kickstart installation and available on CentOS, Oracle Linux, and Red Hat Enterprise Linux version 7 or newer. The firewall daemon can be enabled by running systemctl enable firewalld and started/stopped running systemctl {start|stop} firewalld. Running systemctl status firewalld shows whether the firewall service is currently running; firewall-cmd --help shows the inbuilt documentation. firewalld relies on zones and services:

You can restrict user access to orcharhino using roles and filters.

You can also restrict access using a location and organization context. This limits the user’s access to orcharhino’s resources, for example hosts and job templates.

If you want to run job templates against the orcharhino server or orcharhino proxies, then orcharhino’s remote execution features require SSH access. To make setting up the required SSH access easy, ATIX provides the orcharhino-rex-user RPM package.

Install the package to set up the or-rex linux system user, along with sudo rules, and the required authorized_keys file:

You will also need to set a host parameter for orcharhino’s remote execution features to use the new user:

Your sufficiently privileged orcharhino users can now run job templates against the relevant target host.

When you execute a remote job targeting your orcharhino Server, ensure your orcharhino Server is in a subnet with the correct smart proxy set for remote execution. This prevents remote execution jobs that you run on your orcharhino Server itself to try and use every other orcharhino Proxy first. It saves a lot of time, especially in scenarios with multiple orcharhino Proxies, as you no longer have to wait until the remote job has ran into the SSH timeout for each orcharhino Proxy.

The following procedure allows you to run remote execution on hosts without a subnet configuration.

Job templates can be used to execute arbitrary commands on any system that accepts the SSH key used by orcharhino’s remote execution features. By default, this will include all managed systems as many orcharhino features depend on it. In addition, ATIX provides job templates intended to target the orcharhino host itself in order to automate orcharhino administration.

As a result, it is highly recommend to limit job template access for standard users. You can disable job template access completely by ensuring your standard users do not have access to either the Remote Execution Manager or the Remote Execution User roles. Since users will often need access to at least some job templates, you can also use a combination of the Remote Execution User role along with filters to limit users to specific templates and/or specific hosts, allowing for almost arbitrarily fine grained permissions management.

The example below uses a filter to exclude users from using the Run Command - SSH Default and Run Command - Ansible Default templates. These templates are particularly versatile, since even users that may not edit any job templates (Remote Execution Manager role) can use them to run arbitrary commands with job parameters.

You can use a custom user for remote execution using SSH or Ansible. By default, orcharhino uses the root user to connect to managed hosts.

Your custom user can now use sudo to run commands as root user without password query.

By default, each Smart Proxy, that is, orcharhino Server and orcharhino Proxies, creates its own RSA SSH key pair. You can find the SSH key on your orcharhino Server or orcharhino Proxy under /var/lib/foreman-proxy/ssh/ that gets deployed to newly provisioned hosts by default according to your provisioning templates. You can change the default SSH key, for example if you do not want to use RSA SSH keys.