Rol de Ansible: Rsyslog

Instala y configura rsyslog en servidores Debian/Ubuntu.

Esta rol instala y configura la última versión de rsyslog desde el repositorio APT oficial (en Debian) o PPA oficial (en Ubuntu). Por defecto, tomará el contenido de /etc/rsyslog.conf y /etc/rsyslog.d/50-default.conf.

Requisitos

Ninguno.

Variables de rol

Aquí están las variables disponibles con sus valores predeterminados (como en defaults/main.yml):

rsyslog_rules: []

Un arreglo de reglas para rsyslog. Cada entrada creará un archivo de configuración separado llamado $priority-$rule_name.conf. Asegúrate de revisar defaults/main.yml para un ejemplo comentado con todas las opciones disponibles.

rsyslog_rules:
  - rule_name: "remote-udp"
    priority: 99
    ruleset: |
      module(load="omfwd")
      action(type="omfwd" target="central.server.local" port="514" protocol="udp")
    state: "present"

Aquí hay un ejemplo de una entrada rsyslog_rules completamente poblada. Observa el | para la declaración de bloque para el ruleset. Desde ahí, se utiliza la sintaxis de configuración de rsyslog.

Una alternativa a definir las rsyslog_rules de manera individual sería usar rsyslog_extra_conf_options. Esto extenderá el archivo de configuración principal /etc/rsyslog.conf con opciones adicionales en lugar de crear nuevos archivos en /etc/rsyslog.d.

rsyslog_extra_conf_options: |
  module(load="imudp")
  input(type="imudp" port="514")

Aquí también se usa | para la declaración de bloque y el código es una sintaxis de configuración de rsyslog. También se puede combinar con rsyslog_remove_default_rules: true para asegurarse de que /etc/rsyslog.d/ esté vacío.

Además, actualmente hay tres reglas rsyslog preconfiguradas. Todas tienen plantillas dedicadas (templates/*.conf.j2). Solo una de ellas está habilitada por defecto y se llama, bueno, default. Esta toma la definición del archivo /etc/rsyslog.d/50-default.conf. Se puede desactivar fácilmente especificando state: "absent".

rsyslog_rule_default:
  rule_name: "default"
  priority: 50
  template: "default.conf.j2"

La segunda es docker, que gestiona los registros de los contenedores de Docker que se ejecutan en el host dado. Se define en el archivo /etc/rsyslog.d/20-docker.conf.

rsyslog_rule_docker:
  rule_name: "docker"
  priority: 20
  template: "docker.conf.j2"
rsyslog_rule_docker_tag_all: true

Esto creará /var/log/docker y colocará archivos de registro dentro con el esquema de nombrado $CONTAINER_NAME.log. Se espera que el $syslogtag contenga docker/ en el nombre (consultar el ejemplo a continuación), de lo contrario, enviará todos los registros a /var/log/docker/no_tag.log. Además, hay una opción rsyslog_rule_docker_tag_all que se puede activar cuando hay más de un contenedor en ejecución en el host dado y permite un único archivo con registros agregados de todos ellos en /var/log/docker/all.log (Nota: esto duplicará el espacio necesario para los registros de los contenedores). Puedes revisar mi rol hadret.containers para un ejemplo de la definición de contenedores con soporte syslog habilitado.

containers:
  - name: cadvisor
    image: "google/cadvisor:latest"
    state: started
    log_driver: journald
    log_options:
      tag: docker/cadvisor

journald actualmente es recogido automáticamente por rsyslog.

Por último, pero no menos importante, está la gestión remote. Quería crear una solución lista para usar para manejar tanto las partes del cliente como del servidor. La registración remota es actualmente muy básica, pero funciona desde el principio con una configuración mínima.

rsyslog_rule_remote:
  rule_name: "remote"
  role: server
  priority: 99
  template: "remote.conf.j2"
  ruleset_name: "remote"

Al menos un protocolo remoto (relp/tcp/udp) debe ser especificado (Nota: no hay valor predeterminado y especificar solo rsyslog_rule_remote fallará). La manera en que se maneja el lado del servidor requiere un ruleset_name definido, ya que es el ruleset que ejecuta la acción real de registrar los registros (a través de omfile) y aplica las plantillas predefinidas. Estos están configurados para ser lo más similares posible a las reglas "ordinarias" con los siguientes salidas predefinidas: auth.log, syslog.log, rsyslog.log, kern.log y mail.log.

rsyslog_rule_remote_relp:
  port: 514

Actualmente, solo relp admite la configuración TLS.

rsyslog_rule_remote_relp:
  address: 0.0.0.0
  port: 514
  tls: true
  tls_cacert: "/tls-certs/ca.pem"
  tls_mycert: "/tls-certs/cert.pem"
  tls_myprivkey: "/tls-certs/key.pem"
  tls_authmode: "fingerprint"

Tanto tcp como udp actualmente solo permiten especificar address (opcional en modo servidor), target (requerido en modo cliente) y port (requerido en ambos modos).

rsyslog_rule_remote_tcp:
  address: 0.0.0.0
  port: 514

rsyslog_rule_remote_udp:
  address: 0.0.0.0
  port: 514

Ten en cuenta que puedes definir los tres, con diferentes direcciones y puertos (pero cada uno solo una vez). Toda la configuración caerá, por defecto, en /etc/rsyslog.d/99-remote.conf (tanto servidor como cliente). Actualmente, es imposible que una sola máquina actúe tanto como servidor como cliente simplemente usando rsyslog_rule_remote_relp, pero se puede especificar una regla adicional con rsyslog_extra_conf_options o rsyslog_rules.

rsyslog_rule_remote:
  rule_name: "server"
  role: server
  priority: 99
  template: "remote.conf.j2"
  ruleset_name: "server"

rsyslog_rule_remote_udp:
  port: 514

rsyslog_rules:
  - rule_name: "client"
    priority: 99
    ruleset: |
      module(load="omfwd")
      action(type="omfwd" target="central.server.local" port="514" protocol="tcp")

Nota: las tres reglas rsyslog preconfiguradas son diccionarios, no arreglos. Solo rsyslog_rules permite múltiples definiciones de regla.

Ampliar y reemplazar plantillas

Me doy cuenta de que no todo está cubierto con variables y hay muchas opciones de configuración posibles. Esa es la razón por la que utilizo plantillas para todas las reglas, lo que permite una fácil ampliación, reemplazo por bloques (a través de herencia de plantillas Jinja2) o un intercambio total de plantillas para ajustarse a las necesidades que no he considerado.

rsyslog_conf_template: "rsyslog.conf.j2"
rsyslog_rules_template: "rules.conf.j2"

También se puede cambiar según cada regla.

rsyslog_rule_default:
  rule_name: "default"
  priority: 50
  template: "{{ playbook_dir }}/templates/custom-default.conf.j2"

rsyslog_rule_docker:
  rule_name: "docker"
  priority: 20
  template: "{{ playbook_dir }}/templates/custom-docker.conf.j2"

rsyslog_rules:
  - rule_name: "remote-udp"
    priority: 90
    template: "{{ playbook_dir }}/templates/custom-udp.conf.j2"
  - rule_name: "remote-tcp"
    priority: 91
    template: "{{ playbook_dir }}/templates/custom-tcp.conf.j2"

Ejemplo: ampliando el bloque de módulos en el archivo de configuración principal

rsyslog_conf_template debe establecerse para apuntar al nuevo archivo en el directorio de tu playbook.

rsyslog_conf_template: "{{ playbook_dir }}/templates/custom-rsyslog.conf.j2"

El archivo de plantilla personalizado debe colocarse en relación con tu playbook.yml.

{% extends 'roles/external/hadret.rsyslog/templates/rsyslog.conf.j2' %}

{% block modules %}
$ModLoad imuxsock
$ModLoad imklog
$ModLoad immark

$ModLoad imudp
$UDPServerRun 514

$ModLoad imtcp
$InputTCPServerRun 514
{% endblock %}

El ejemplo anterior reemplaza/amplía el bloque modules en el archivo de configuración principal de rsyslog.

Dependencias

Ninguna.

Ejemplo de playbook

hosts: all
  roles:
    - hadret.rsyslog

Licencia

MIT.

Autores

Este rol fue ensamblado en 2019 por Filip Chabik.