When automating MySQL server setup with Ansible, we often need to set the root password during installation. While using the debconf module with vault-protected variables works, we encounter a critical security issue where the plaintext password appears in system logs.

# Problematic log entries example
Apr 10 14:39:59 db01 ansible-debconf: Invoked with value=SuperSecret123! vtype=password question=mysql-server/root_password name=mysql-server

Ansible modules typically log their invoked parameters for debugging purposes. The debconf module is no exception - it records all parameters passed to it, including password values marked as sensitive.

1. Using no_log Parameter

The most straightforward solution is adding no_log: true to tasks handling sensitive data:

- name: Set MySQL root password securely
  debconf:
    name: 'mysql-server'
    question: 'mysql-server/root_password'
    value: "{{ mysql_root_pwd | quote }}"
    vtype: 'password'
  no_log: true  # This prevents logging of the entire task

2. Customizing Ansible's Log Filtering

For system-wide protection, configure ansible.cfg:

[defaults]
log_filter = ~(password|passwd|secret|key|token).*

3. Advanced: Using Callback Plugins

Create a custom callback plugin to sanitize logs:

from ansible.plugins.callback import CallbackBase

class SensitiveFilter(CallbackBase):
    def v2_runner_on_ok(self, result):
        if 'value' in result._result.get('invocation', {}).get('module_args', {}):
            if 'password' in str(result._result['invocation']['module_args']):
                result._result['invocation']['module_args']['value'] = 'VALUE_REDACTED'
        super(SensitiveFilter, self).v2_runner_on_ok(result)

• Always store passwords in Ansible Vault
• Use temporary password files with proper permissions (600) when necessary
• Consider using MySQL's ALTER USER after initial setup for password changes
• Regularly audit your logs for accidental exposures

After implementation, test with:

ansible-playbook playbook.yml -vvv
# Check /var/log/syslog and Ansible logs for sensitive data

When automating MySQL server setup with Ansible, security-conscious administrators often face an unexpected issue: the MySQL root password appears in clear text within system logs. This occurs even when using Ansible Vault for password storage, as the debconf module parameters get logged during execution.

Ansible's default logging behavior captures module parameters for debugging purposes. The debconf module is no exception. When you examine /var/log/syslog or /var/log/auth.log, you'll find entries like:

ansible-debconf: Invoked with value=THEPASSWORD vtype=password question=mysql-server/root_password

1. Using no_log Parameter

The most straightforward solution is to add no_log: true to sensitive tasks:

- name: Set MySQL root password before installing
  debconf:
    name: 'mysql-server'
    question: 'mysql-server/root_password'
    value: "{{ mysql_root_pwd | quote }}"
    vtype: 'password'
  no_log: true

- name: Confirm MySQL root password before installing
  debconf:
    name: 'mysql-server'
    question: 'mysql-server/root_password_again'
    value: "{{ mysql_root_pwd | quote }}"
    vtype: 'password'
  no_log: true

2. Ansible Configuration Adjustment

For system-wide changes, modify your Ansible configuration file (ansible.cfg):

[defaults]
no_target_syslog = True
display_args_to_stdout = False

3. Alternative MySQL Installation Approach

Consider using the mysql_user module after installation instead of debconf:

- name: Install MySQL server
  apt:
    name: mysql-server
    state: present

- name: Set root password
  mysql_user:
    name: root
    password: "{{ mysql_root_pwd }}"
    check_implicit_admin: yes
    login_unix_socket: /var/run/mysqld/mysqld.sock
  no_log: true

After implementing these changes:

• Check your system logs for any remaining password traces
• Verify MySQL root access works with the new password
• Test that Ansible playbooks still execute correctly

For comprehensive security:

• Always store passwords in Ansible Vault
• Restrict log file permissions
• Consider using centralized logging with access controls
• Regularly audit your system logs