Reemplazando Certificados en Aria Suite (vRealize Suite)

Una de las operaciones de día 2 que mas terror nos daba hace unos años o posiblemente con la que mas sufríamos, fue el reemplazo de certificados para las soluciones VMware. Los que tuvimos que luchar esa batalla, recordaremos lo tedioso que era tener que reemplazar cada uno de los certificados de una solución de forma manual y encontrarse errores diferentes conforme avanzábamos.

Por suerte, esto ha cambiado y ahora Aria Suite Lifecycle (antes vRealize Suite Lifecycle Manager) nos ofrece una forma fácil, rápida y segura de reemplazar los certificados, por lo menos de los productos asociados a la Aria Suite (antes vRealize Suite) y por supuesto que sean gestionados desde Aria Suite Lifecycle.

En el procedimiento a continuación estaremos explicando cómo reemplazar los certificado autofirmados por certificados customizados, es decir certificados firmados por una entidad certificadora del cliente o CA Enterprise. El cambio de un certificado de un autofirmado por otro igualmente autofirmado, es similar al proceso explicado en este post y simplemente costa de los siguientes dos pasos por lo que no representa mayor tiene mayor dificultad.

  1. Crear un certificado en el servicio de locker de vRealize Suite lifecycle Manager
  2. Reemplazar el certificado viejo por el nuevo

Reemplazo de Certificado autofirmado por certificados customizados

Lo primero que debemos tener presente es que el reemplazo de certificados autofirmados por certificados customizados, incluye la participación del equipo de seguridad del cliente, quien será el encargado de proveernos los certificados validos para nuestros productos.

Una manera fácil de hacer esto es solicitar al cliente el/los certificados en extensión .pem y de esta manera evitamos tener que generar un Certificate Signing Request (CSR), que si bien podemos generarlos desde vRealize Suite Lifecycle Manager, pues lo único que haría es agregarnos un paso mas en el proceso. Por esta razón, recomiendo solicitar al cliente crear directamente los certificados en su herramienta y exportarlo en el formato indicado y con el Key sin cifrar.

Una vez nos han enviado el/los certificados podemos continuar con los siguientes pasos:

1. Verificar que los certificados los entreguen en .pem y que estén bien generados. Para esto podemos abrir el archivo .pem con un editor de texto y verificar que tenga la siguiente estructura.

2. Algunas veces nos envían el certificado con el key cifrado, entonces debemos pedir que nos envíen el Key sin clave. Y Rearmar el .pem en otro archivo pero esta vez utilizando el Key sin cifrar.

Recordemos que la sección asociada al Key debería contener los siguiente:

—–BEGIN RSA PRIVATE KEY—–

—–END RSA PRIVATE KEY—–

3. Una vez hemos verificado la estructura del certificado podemos ir al servicio de Locker de Aria Suite Lifecycle e importarlos en -> Certificates -> Import. En este paso solo debemos hacer click en BROWSER FILE y buscar el archivo .pem que construimos en el paso anterior. Automáticamente los campos Private Key y Certificate Chain serán poblados. Finalizamos el proceso haciedo click en el boton IMPORT

4. Una vez importados se mostraran los detalles del certificado de manera que podremos verificar que los Subject Alternative Name de cada certificado contenga los FQDN de todos los nodos de cada solución incluyendo el FQDN del VIP del balanceador que le corresponda, de ser necesario.

5. Si vamos a reemplazar el certificado de una solucion que se encuentra detrás de un balanceador como por ejemplos VMware Identity Manager (vIDM), ahora llamado Workspace One Access (WS1), debemos primero reemplazar el certificado en el balanceador siguiendo la guía de cada fabricante.

6. Una vez realizado el cambio de certificados en el balanceador, debemos realizar la action Re-trust Load Balancer en el servicio Lifecycle Operations -> Environments -> Para este ejemplo globalenvironment (ambiente asociado a vIDM o WS1).

7. Para efectuar el reemplazo de certificados lo único que debemos hacer es ir al servicio de Lifecycle Operations -> Environments -> click en VIEW DETAILS del ambiente en cuestión (para este caso globalenvironment) -> Click en los tres puntos (…) para listar mas opciones  -> Replace Certificate

8. A continuación nos muestra un resumen del certificado actual

9. Hacemos click en NEXT para seleccionar el nuevo certificado (importado) desde la lista desplegable

10. Si el certificado es de una solución como vIDM del cual dependen otros productos, nos mostrará que durante el proceso de cambio de certificados hará un Re-Trust sobre los productos listados allí. Click en NEXT para continuar.

11. A continuación podremos seleccionar si queremos que Aria Suite Lifecycle cree por nosotros un snapshot en la VMs involucradas . Se recomienda esta acción a no ser que ya hayamos tomado un snapshot directamente desde el vCenter. Luego Click en NEXT

12. Para validar que el certificado que vamos a aplicar es correcto, debemos ejecutar un PRECHECK haciendo click en el botón RUN PRECHECK

13. Después de finalizar el PRECHECK podemos ver que nos solicita una acción de aceptar y nos indica que el remplazo de los certificados sobre los balanceadores debe hacerse manual como lo comentamos anteriormente. Procedemos entonces a hacer click en ACEPTAR y después en FINISH

Nota 1: Si por alguna razon, reemplaza el certificado de una solucion de Aria Suite (vRealize Suite) sin haber cambiado el certificado del balanceador recibirá una notificación en el Aria Suite Lifecycle (vRealize Suite Lifecycle Manager) indicándole que debe reemplazar el certificado en el balanceador (Importar el certificado nuevo en NSX-T, NSX-v, F5, o el balanceador que corresponda) siguiendo la guia del fabricante, como comentamos anteriormente.

Nota 2: De igual forma, si se cambia el certificado del balanceador despues de cambiar el certificado de vIDM entonces recibirá una unas notificaciones en Aria Suite Lifecycle indicándole que debe realizar una acción de re-trust en cada una de las soluciones que se encuentren detras de ese balanceador. Comenzando de nuevo por Workspace One Access (WS1A).

Nota 3: Sino hacemos esto vamos a recibir un Bad Gateway al intentar a hacer login en WS1A. Para evitar esto, recomendamos reemplazar el certificado del balanceador en primer lugar como lo hemos mencionado anteriormente

14. Si realizamos el reemplazo del certificado en el balanceador, en primera instancia como lo hemos recomendado, la URL de acceso al WS1 (VIP)después del reemplazo de los certificados del globalenvironment, debería mostrar el sitio como seguro y con los detalles del certificado que hemos importado.

15. Como hemos realizado un cambio que esta por fuera del control de Aria Suite Lifecycle (vRealize Suite Lifecycle Manager) debemos realizar la acción de Re-trust Load Balancer, desde la solucion de Workspace One Access / VMware Identity Manager (globalenvironment) y para esto vamos a Environment -> global environment -> click en los tres puntos (…) para mas opciones y luego click en Re-trust Load Balancer

16. (Opcional) Cuando termine vamos a cada unos de los productos que estaba integrados con vIDM o WS1A, como por ejemplo Aria Operations (antes vRealize Operations Manager), Aria Automation (antes vRealize Automation), Aria Operations for Logs (vRealize Log Insight), etc. En algunas ocasiones podríamos necesitar hacer click Re-Trust with Identity Manager en cada una de las soluciones de Aria Suite (vRealize Suite), aunque este proceso por lo general se hace automático durante el reemplazo de certificados de Workspace One Access (WS1A).

17. El reemplazo de certificados de todas las soluciones de la Aria Suite tienen el mismo procedimiento que hemos mencionado para el Workspace One Access (globalenvironement), razon por la cual no haremos este post mas largo.

Nota 4: Para las soluciones que no están detrás de un balanceador, es claro que podemos hacer directamente el reemplazo de certificados siguiendo los pasos 7-13.

Por ultimo, vamos a realizar el reemplazo de certificados de la solucion Aria Suite Lifecycle (vRealize Suite Lifecycle Manager). El reemplazo de esta solucion no tiene un orden especifico y se puede realizar en primero o ultimo lugar. Vemos entonces los siguientes pasos.

Remplazo de certificados de Aria Suite Lifecycle (vRealize Suite Lifecycle Manager)

1. En el servicio de Locker vamos a crear o importar un certificado para esta solucion. Como ya explicamos como importar un certificado, en este caso generaremos uno nuevo desde la opción -> Certificates -> Add Certificate. Recordar que si lo generamos desde el servicio de Locker, sera entonces un certificado autofirmado o Self-Signed.

2. En Lifecycle Operations click en –> Settings -> Change Certificate

3. Click en el boton REPLACE CERTIFICATE

4. Revisamos los detalles del certificado actual y hacemos click en NEXT

5. Seleccionamos el nuevo certificado, que importamos o generamos en el servicio de Locker y click en NEXT

6. Click en RUN PRECHECK para verificar que todo este bien con el certificado y si todo esta ok, click en FINISH

Nota: Después de un par de minutos, en el servicio de Lifecycle Operations deberíamos ver el Request asociado a este reemplazo de certificados como Completed.

Y podemos validar que el Subject del certificado ahora contienes los datos que configuramos en el nuevo certificado.

Nota 5: (Opcional) Si ha realizado reemplazo de certificados para WS1A antes de cambiar los de Aria Suite Lifecycle entonces realize una acción de RE-REGISTER dentro del servicio de Lifecycle Operations -> Settings -> Authentication Provider. Debería haberse realizado de manera automática, pero si tiene algún problema con la autenticación de usuarios de dominio en la solucion Aria Suite Lifecycle, este paso solucionara el inconveniente.

Referencias

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.

Exportar reglas del Firewall Distribuido de NSX-T con vRNI

Muchas veces bien sea desde el lado de implementación o desde la operación, nos encontramos con el problema de no poder exportar las reglas del Firewall Distribuido de NSX-T en las versiones 3.0 y anteriores. Esta característica ha sido recientemente adicionada a la versión 3.1 (ver aquí), de manera que si tenemos una version anterior nos vemos obligados a recurrir a APIs para poder extraer la configuración de estas políticas y reglas.

Por suerte, por lo general cuando hablamos de Micro-Segmentación casi siempre tenemos a la mano la herramienta vRealize Network Insight con lo cual esta tarea se resume a una consulta y a un export.

PROCEDIMIENTO

En la caja de búsqueda de vRNI realice la siguiente consulta: NSX-T Firewall rule

En el filtro NSX Manager, seleccione el NSX Manager de interés. Si solo tiene un NSX Manager conectado a vRNI omita el paso.

Haga clic en More Option y después clic en Export as CSV.

Clic en Clear All para eliminar todas las propiedades y poder ajustar las que son de nuestro interés.

Clic en ADD PROPERTIES y agregue las siguientes propiedades:

Nota: Puede utilizar el buscador para encontrar las propiedades rapidamente.

  • Section Name
  • Rule ID
  • Configure Source
  • Configure Destination
  • Service
  • Port Range Display
  • Applied to
  • Action
  • Direction

Activamos el check Save changes to: Create a new template, para crea una plantilla con las nueve (9) propiedades seleccionadas.

Por ultimo, en el campo de texto Create a new template asignamos un nombre a la plantilla (en este caso hemos definido Export DF Rules Template)y hacemos clic en EXPORT.

Seleccionamos el destino y nombre para el archivo .csv y clic en Save.

clip_image005

La próxima vez que desee exportar nuevamente las reglas únicamente tendrá que seleccionar en Property Template la plantilla guardada y automáticamente se cargaran las propiedades asociadas.

Una vez hemos exportado la información simplemente lo importamos en Excel para poder visualizarla como filas y columnas.

(Opcional) Una vez la tenemos en este formato, recomiendo crear una tabla dinámica para organizar mejor la información de forma similar a como la vemos en el Firewall Distribuido.

Para esto, active el Diseño de tabla dinámica clásica antes de seleccionar la información de las columnas.

clip_image010

Organice las filas en el siguiente orden y seleccione la opción No mostrar subtotales en el diseño de la tabla dinámica

  • Section Name
  • Rule ID
  • Configure Source
  • Configure Destination
  • Service
  • Port Range Display
  • Applied to
  • Action
  • Direction

Por ultimo, utilice la función buscar y remplazar para eliminar la palabra «default.» que antepone cada security group en la información exportada. De esta manera podrá visualizar mejor la información presentada.

Actualizando vRealize Network Insight 5.x (Online Update)

Antes de comenzar a actualizar la solución es recomendable considerar los siguientes puntos:

  • Después de la actualización, vRealize Network Insight tarda entre 12 y 24 horas en procesar los datos que estaban en proceso durante la operación de actualización y reflejarlos en la interfaz de usuario.
  • vRealize Network Insight no admite rollback ni downgrade del producto por lo que se debe realizar una copia de seguridad antes de continuar con la actualización. Para obtener más información sobre el proceso de backup y restauración ver aquí.
  • En un entorno de clúster, debe realizar la operación de actualización solo en el nodo Platform 1.
  • Después de actualizar a vRealize Network Insight 6.x, algunos de los ID de reglas de firewall pueden cambiar a los nuevos ID devueltos por la API de VMware Cloud on AWS 1.9. Si existe alguna regla de firewall de VMware Cloud on AWS 1.8 adjunta a los flujos:
    • Las reglas de firewall de VMware Cloud on AWS 1.9 correctas o respectivas se adjuntarían inmediatamente después de la actualización para todos los flujos activos.
    • Las reglas de firewall se referirían a reglas inexistentes para los flujos cuyo período de inactividad es mayor a 24 horas antes de actualizar la versión 1.8 a 1.9.
  • La solución debería tener acceso a internet para la descarga de los paquetes necesarios de manera automática. Este acceso a internet puede ser directo o a través de un web proxy.
  • La opción Online Update deberá estar habilitada en Settings | Infrastructure and Support | Overview and Update y deberá existir un paquete disponible para instalar.
  • Asegúrese de tener soporte activo para la solución vRealize Network Insight antes de actualizar.
  • Si va a realizar un Upgrade (cambio a una nueva versión) entonces deberá realizar el upgrade también de la licencia en my.vmware.com.

PROCEDIMIENTO

1. Genere un Snapshot para cada una de la maquinas virtuales que conforman la solución (nodos Platform y Proxies) o asegúrese de tener un backup de cada una de ellas en caso de que algo salga mal.

2. Inicie sesión en vRealize Network Insight como administrador y vaya a Settings | Infrastructure and Support | Overview and Update para revisar la existencia de actualizaciones disponibles.

image

3. Verifique el estado de salud de la infraestructura sea Good.

image

4. Haga clic en el enlace View details frente a la nueva versión de paquete que aparece disponible.

image

5. Revise el numero de compilación de la nueva versión y lea atentamente la información de la ventana emergente. (Opcional) haga clic en View release note para conocer mas acerca de la nueva versión.

image

6. Haga clic en CONTINUE para iniciar el proceso de actualización y espere pacientemente a que todos los pasos finalicen con éxito.

image

7. Cuando aparezca el botón DONE en la parte inferior, sabrá que el proceso de actualización ha terminado. Y podrá hacer clic sobre el para cerrar la ventana emergente e ir a la ventana de inicio de sesión.

image

8. Inicie sesión en la solución vRealize Network Insight como administrador y revise las notas What is New de bienvenida, para familiarizarse con las bondades de la nueva versión. Cierre la ventana emergente haciendo clic en la X.

image

9. Una vez cierre la ventana anterior, aparecerá una notificación para ingresar la licencia asociada a la nueva versión.

Nota: Si únicamente se hace un Update dentro de la misma versión no tendrá que hacer este paso.

image

10. Haga clic en PROCEED para ir automáticamente a la sección License and Usage e ingrese la nueva llave que previamente debió haber actualizado desde el portal de my.vmware.com.

image

11. Verifique que el estado de salud para cada uno de los componentes de la infraestructura continúe en Good, en la sección Settings | Infrastructure and Support | Overview and Updates.

image

12. Por ultimo pero no menos importante, verifique que las fuentes de datos continúen recolectando datos.

Implementando vRealize Network Insight (vRNI) 5.2

Si bien éste no será un post en el que revelaremos las grandes ventajas y funcionalidades de vRealize Network Insight, si diremos que es una de las herramientas más potentes que existen para lograr una visión 360° de nuestro Centro de Datos, debido a que nos permite recolectar información de lo que pasa con el flujo de información en el mundo virtual, físico e incluso a través de nuestros ambientes multicloud. Para conocer un poco acerca de los beneficios claves de la solución ver aquí.

Sus principales Casos de Uso

  • Planificación de Microsegmentación para los clientes que no conocen el flujo de información en sus aplicaciones.
  • Visibilidad 360° no solo del ambiente virtual sino también de la capa física.
  • Implementación de mejores practicas para NSX en la infraestructura.

Dicho lo anterior, nos concentraremos en la implementación de la solución para un ambiente virtual y para esto debemos tener presente cada uno de los componentes que hacen parte de la solución.

image

PROCEDIMIENTO

Clic en el siguiente video para visualizar el procedimiento de instalación y configuración de vRealize Network Insight 5.x. Este procedimiento aplica también para la versión 6.x

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.