VCAP-CIA Objetivo 1.1 o el misterio del logging de vCloud Director

Contar con los mecanismos para indagar en el pasado y rastrear eventos ó comportamientos de un sistema computacional es uno de los requisitos principales para contar con una infraestructura tecnológica administrable, escalable y que facilite el cumplimiento de regulaciones en el ámbito de seguridad de la información.

En el caso de VMware vCloud Director y su componente de seguridad y conectividad vCloud Networking & Security existen diferentes métodos por los cuales se pueden recolectar registros de actividad así como niveles de detalle de esos registros ó logs.

Dominar éste tema es el objetivo 1.1 del examen de certificación VMware Certified Advanced Professional – Cloud Infrastructure Administration, mejor conocido como VCAP-CIA; y lo trataremos con detalle en éste post.

Logging en vCloud Director
vCloud recolecta dos tipos de log: audit log que es el registro de actividades en el espacio de usuario así como eventos de los servicios que componen a vCloud.  Entre otros, estos eventos incluyen inicios de sesión, operaciones sobre vApps, orgvDCs y estado del servicio. El otro tipo de log es el diagnostic log que reporta el estado de los diferentes componentes del servicio vCloud Director y tiene varios niveles de detalle, cuya selección debe obedecer al caso de uso que se busque evaluar (clic para ver más sobre los niveles de logging). En todo caso, los audit logs por defecto se almacenan en la base de datos por 90 días y al ingresar la IP o nombre de un servidor syslog en el menú de instalación de vCloud,  se está dando la instrucción de re dirigir el audit log a ese servidor syslog en que se podrá manejar una retención mayor.

¿Qué es log4j y que papel cumple?

Es un interceptor de logs para aplicaciones Java y se denomina así por no insertar mínimas declaraciones de logging en las aplicaciones (en éste caso vCloud Director) e interceptar el contenido para alojarlo en ubicación externa (que desde el punto de vista de la aplicación, puede ser el almacenamiento local).

Con respecto a vCloud Director, cumple la función de procesar los diagnostic logs y habilitar el envío de éstos a ubicación centralizada (syslog). También administra los diferentes niveles de detalle que los diagnostic logs pueden registrar.

Logging en vShield Manager

vShield Manager es el plano de control que lleva a cabo la implementación de los appliance sobre los que corren módulos como vShield Edge, vShield Edge o Endpoint. Sin embargo vSM no interactúa directamente con el tráfico de red o las reglas de seguridad como si lo hacen los módulos mencionados, sino que mantiene el inventario de la ubicación, propiedad (a qué tenant pertenece) y características de los módulos desplegados en el entorno.

Quizá atribuìdo a esa función de mera supervisión que cumple vSM, es que la única opción de logging corresponde a un sólo servidor syslog a donde vSM enviará los logs tipo audit:

Syslog para vShield Manager

Métodos de captura de logs

 

1. Local

Caso de uso: retención de audit logs por máximo 90 días, espacio NFS para almacenamiento de diagnostic logs.

Este es el método de recolección de log que por defecto usa vCloud Director en caso que no se especifique ningún servidor syslog. En éste caso los logs audit y diagnostic se almacenan en $VCLUD_HOME/logs en el almacenamiento de cada vCloud cell.

Se pueden modificar las siguientes opciones para los diagnostic logs alojados localmente:

  • Nivel de detalle (ver VMware KB # 1026815)

 

¿Cómo hacerlo?

A. Iniciar sesión en la celda vCloud

B. Editar el archivo $VCLOUD_HOME/etc/log4j.properties:

blog51

C.  Siguiendo la KB 1026815 ubicar las líneas

# Root logger log4j.rootLogger=ERROR, vcloud.system.debug, vcloud.system.info

y

log4j.appender.vcloud.system.debug.threshold=DEBUG

Una vez se haya elegido un nivel de logging, se debe editar en éstas dos líneas fijándolas en el mismo nivel de detalle. Por ejemplo, si eligiera el nivel “TRACE”, que trae el mayor detalle, las líneas finalmente se verían así:

Root logger log4j.rootLogger=TRACE, vcloud.system.debug, vcloud.system.info

log4j.appender.vcloud.system.debug.threshold=TRACE

D. Guardar los cambios y reiniciar el servicio vCloud Director
Nivel de retención y tamaño de archivos de log

 

¿Cómo hacerlo?

A. Editar el archivo $VCLOUD_HOME/etc/log4j.properties

B. Editar las líneas log4j.appender.vcloud.system.debug.MaxFileSize y log4j.appender.vcloud.system.debug.MaxBackupIndex fijando el tamaño máximo de los archivos de log y el número máximo de archivos a retener, respectivamente.

C. Guardar cambios en el archivo

D. No se requiere reiniciar el servicio vCloud Director

 

2. Local redireccionado

Consiste en usar el servicio rsyslog corriendo en el sistema operativo (RHEL o CentOS) en el que corre vCloud Director, para atrapar los logs que vienen de la aplicación y redirigirlos a uno o más servidores syslog remotos.  Debido a que syslog es un protocolo UDP y que por tanto carece de métodos de retransmisión en caso de pérdida de paquetes, es recomendable tener múltiples servidores syslog habilitados para captura de logs remotos.

¿Cómo hacerlo?

A. Instalar el paquete “rsyslog” en la celda vCloud (en caso que no esté ya instalado)

yum install rsyslog -y

B. Modificar el archivo $VCLOUD_HOME/etc/global.properties editando la línea

audit.syslog.host = 127.0.0.1

En éste punto, si solo se requiere redireccionar audit logs se procedería al paso D, si se busca redirigir también diagnostic logs, el procedimiento continúa en el punto C:

C. Editar el archivo $VCLOUD_HOME/etc/log4j.properties y agregar las líneas que indica la VMware KB # 2004564 especificando el servidor syslog local en la línea:

log4j.appender.vcloud.system.syslog.syslogHost=127.0.0.1

Los siguientes pasos consisten en habilitar a rsyslog para que reciba logs de la aplicación y los envíe a syslog remotos:

D.  Editar el archivo /etc/rsyslog.conf descomentando las siguientes líneas:

$ModLoad Imudp

$UDPServerRun 514

E. En el extremo inferior de ése mismo archivo, agregar la dirección IP de los syslog a los que se enviarán los logs:

*.*  @@server1

*.*  @@server2

..

F.  Guardar cambios en el archivo y reiniciar el servicio rsyslog:

service rsyslog restart

En éste punto ya empezarán a recogerse logs en el servidor o servidores syslog que se haya especificado.
3. Directamente centralizado

Finalmente, éste método provee envío directo de audit y diagnostic logs a un y solo un servidor syslog remoto que puede ser TCP o UDP.

¿Cómo hacerlo?

Envío de audit logs:

  1.  Modificar el archivo $VCLOUD_HOME/etc/global.properties editando la línea

audit.syslog.host = IP_SYSLOG_REMOTO

para que refleje la IP del syslog server.

2. Reiniciar el servicio vmware-vcd

Envío de diagnostic logs:

A. Editar el archivo $VCLOUD_HOME/etc/log4j.properties y agregar las líneas que indica la VMware KB # 2004564 especificando el servidor syslog local en la línea:

log4j.appender.vcloud.system.syslog.syslogHost=IP_SYSLOG_REMOTO

B.  Reiniciar el servicio vmware-vcd

Otros recursos

Recomendado Sesión 192 del Podcast de Packetpushers.net : “Logging design and best practices

http://packetpushers.net/show-192-logging-design-best-practices/

PDTA: Sé que este es un post largo y puede resultar confuso el tema, si se generan dudas no dude en escribirlas en los comentarios; pronto estarán publicados los slides y la grabación del podcast vBrownBag LATAM en el que traté este tema con un lab en vivo.

Saludos!

 

 

Advertisements

vExpert 2014: ¡gracias totales!

La noticia me tomó por sorpresa.

Había aplicado al programa VMware vExpert para el Q2 de 2014 en el track de Customer, y aunque rellené los campos en el formulario, realmente no pensé nunca que me fueran a seleccionar, menos aún contemplando la labor de algunos de los demás profesionales en la lista publicada.

Sólo tengo palabras de gratitud para mi esposa, porque comprende mi interés y pasión por la computación en general, y la virtualización en particular.

También que ésta sea una oportunidad para agradecer públicamente a Dios, cuya gracia y amor me han traído hasta aquí.

Los escenarios de participación y aporte a la comunidad en que he podido estar presente, han sido creados o promovidos por la comunidad #vBrownBag a quienes extiendo mi agradecimiento.

El reconocimiento me convierte en el tercer vExpert de mi país, y ésto solo renueva mi compromiso por permanecer relevante y aportar en alguna medida a la comunidad de tecnología de la región.