HOWTO
Learn how to secure SSH with Ansible and protect your Linux systems from unauthorized access with this step-by-step guide. Table of Contents Introduction Ansible is
Are you looking to enhance the security of your server? Learn how to enable tls1.2 on your cockpit server using Ansible and keep your data safe from potential threats.
In a previous article (below), we reviewed a scenario where your security team had informed you about a vulnerability on your cockpit servers (naturally running on port 9090) with a TLS Version 1.1 Protocol Deprecated (157288) finding.
We provided a step-by-step procedure for resolving this finding and in this article, we will explore how to automate those step using Ansible.
Enable TLS1.2 on Cockpit Server
Ansible is an open-source IT automation tool that allows system administrators to automate deployment, configuration, and management tasks across a large number of servers. It uses a simple, human-readable language and does not require agents or additional software to be installed on remote machines.
Ansible was created by Michael DeHaan in 2012 and was later acquired by Red Hat in 2015. Since then, it has become one of the most popular automation tools used by DevOps teams and system administrators worldwide. Its popularity can be attributed to its simplicity, scalability, and ease of use, making it an ideal choice for managing large-scale infrastructure deployments.
It is important for running Ansible playbooks to be idempotent, which means that the same playbook can be run multiple times without changing the outcome or causing any adverse effects. This ensures that the system is always in a consistent and predictable state, regardless of how many times the playbook is executed.
For illustrative purposes, we’ve created a yaml file called: set_tls_setting.yaml and in the following sections, we will breakdown the playbook line-by-line.
---
- name: Configure cockpit service
hosts: all
become: yes
tasks:
- name: Check if ssl.conf file exists and delete it
file:
path: /etc/systemd/system/cockpit.service.d/ssl.conf
state: absent
become: yes
ignore_errors: yes
- name: Create /etc/systemd/system/cockpit.service.d directory
file:
path: /etc/systemd/system/cockpit.service.d
state: directory
become: yes
- name: Re-create ssl.conf file
file:
path: /etc/systemd/system/cockpit.service.d/ssl.conf
state: touch
become: yes
- name: Ensure [Service] line exists in ssl.conf
lineinfile:
path: /etc/systemd/system/cockpit.service.d/ssl.conf
line: '[Service]'
become: yes
- name: Ensure environment variable exists in ssl.conf
lineinfile:
path: /etc/systemd/system/cockpit.service.d/ssl.conf
line: 'Environment=G_TLS_GNUTLS_PRIORITY=SECURE128:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1'
insertafter: '[Service]'
become: yes
- name: Reload systemd daemon
systemd:
daemon_reload: yes
become: yes
- name: Restart cockpit service
systemd:
name: cockpit
state: restarted
become: yes
Lets examine the first 12 lines:
---
- name: Configure cockpit service
hosts: all
become: yes
tasks:
- name: Check if ssl.conf file exists and delete it
file:
path: /etc/systemd/system/cockpit.service.d/ssl.conf
state: absent
become: yes
ignore_errors: yes
The first line “---” indicates the start of a YAML file.
The next line “- name: Configure cockpit service” defines a task with a name “Configure cockpit service”.
The “hosts: all” line specifies that this task will be executed on all hosts defined in the inventory file.
The “become: yes” line indicates that the playbook should run with elevated privileges, typically via sudo or a similar mechanism.
The “tasks:” line indicates the start of a list of tasks that will be executed in order.
The “- name: Check if ssl.conf file exists and delete it” line defines a sub-task that will check if a file called “ssl.conf” exists in the directory “/etc/systemd/system/cockpit.service.d/” on the remote server and delete it if it exists.
The “file:” line specifies that the “file” module should be used to check the file’s existence and delete it.
The “path:” line specifies the full path to the file that should be checked.
The “state: absent” line indicates that the file should be deleted if it exists.
The “become: yes” line again indicates that this sub-task requires elevated privileges.
The “ignore_errors: yes” line indicates that if the file does not exist, Ansible should continue with the playbook execution without raising an error.
Overall, this playbook task will check for the existence of a specific file on all hosts, and if it exists, delete it. This task is useful for configuring the Cockpit service without SSL. This is also a crucial step to ensure the playbook is idempotent. Each time the playbook runs it will either create a new file or re-create it which is essentially like starting the procedure from scratch.
Now, lets examine the rest of the playbook. Each line is commented and describes what each line is doing.
- name: Create /etc/systemd/system/cockpit.service.d directory # Defines the name of the task
file: # Defines the module to use
path: /etc/systemd/system/cockpit.service.d # Specifies the path to the directory
state: directory # Sets the directory state to "directory" (if doesn't exist, create it)
become: yes # Sets the privilege escalation to "yes"
- name: Re-create ssl.conf file # Defines the name of the task
file: # Defines the module to use
path: /etc/systemd/system/cockpit.service.d/ssl.conf # Specifies the path to the file
state: touch # Sets the file state to "touch" (if doesn't exist, create it)
become: yes # Sets the privilege escalation to "yes"
- name: Ensure [Service] line exists in ssl.conf # Defines the name of the task
lineinfile: # Defines the module to use
path: /etc/systemd/system/cockpit.service.d/ssl.conf # Specifies the path to the file
line: '[Service]' # Specifies the line to add
become: yes # Sets the privilege escalation to "yes"
- name: Ensure environment variable exists in ssl.conf # Defines the name of the task
lineinfile: # Defines the module to use
path: /etc/systemd/system/cockpit.service.d/ssl.conf # Specifies the path to the file
line: 'Environment=G_TLS_GNUTLS_PRIORITY=SECURE128:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1' # Specifies the line to add
insertafter: '[Service]' # Specifies where to insert the line
become: yes # Sets the privilege escalation to "yes"
- name: Reload systemd daemon # Defines the name of the task
systemd: # Defines the module to use
daemon_reload: yes # Reloads the systemd daemon
become: yes # Sets the privilege escalation to "yes"
- name: Restart cockpit service # Defines the name of the task
systemd: # Defines the module to use
name: cockpit # Specifies the name of the service to restart
state: restarted # Specifies the state of the service after restart
become: yes # Sets the privilege escalation to "yes"
Run the following command to execute the playbook:
$ ansible-playbook -i ~/workspace/ansible/inventory.yaml -l 'all:&testing' set_tls_settings.yaml -Kk
Based on this inventory file, the ansible-playbook will run on or be limited to nodes 5-8 only.
# inventory.yaml
all:
children:
production:
hosts:
node1.dev.infotechys.com:
node2.dev.infotechys.com:
development:
hosts:
node3.dev.infotechys.com:
node4.dev.infotechys.com:
testing:
hosts:
node5.dev.infotechys.com:
node6.dev.infotechys.com:
node7.dev.infotechys.com:
node8.dev.infotechys.com:
Lets take a look at the ansible-playbook command (above) and examine what it’s doing:
ansible-playbook command-line tool to run a playbook named set_tls_settings.yaml against a group of hosts defined in the Ansible inventory file located at ~/workspace/ansible/inventory.yaml.-l option is used to limit the scope of the playbook to hosts that meet a specific criteria, in this case the pattern 'all:&testing' is used to match all hosts except those with the testing tag.-K option prompts the user for the sudo password when executing tasks that require elevated privileges.-k option prompts the user for the SSH password for the target hosts.We have just reviewed the set_tls_settings.yaml line-by-line to gain a better understanding of what the playbook is expected to do when it runs. This is just one way to achieve the tasks required to successfully set TLS to version 1.2 on a cockpit server.
Ansible allows us to automate the process and achieve the same tasks in large environments across several hundred or thousand machines. Was this article helpful to you? If so, let us know in the comment section below and share!
Related Posts
Learn how to secure SSH with Ansible and protect your Linux systems from unauthorized access with this step-by-step guide. Table of Contents Introduction Ansible is
In this article, we will examine a play used to change the root password using Ansible. It will also encrypt the file the password is stored
In today’s Ansible series, we will learn about automating changes using Ansible. Specifically, we will automate changes to the sshd config file. Table of Contents