Como empresa de observabilidad, New Relic crea y mantiene agentes específicos de tecnología y múltiples idiomas para recopilar telemetry data de los entornos de nuestros clientes. Cuando estos equipos de agentes lanzan nuevas actualizaciones manualmente, realizan numerosas verificaciones para garantizar que el proceso no introduzca regresiones causadas por errores humanos. Para reducir el tiempo necesario para implementar una nueva versión, el equipo de agentes de Kubernetes automatizó completamente el proceso de lanzamiento del agente de software. Los flujos de trabajo reutilizables de GitHub Actions mantienen un registro de dependencias vulnerables, escriben documentación y se sincronizan con socios como Amazon Elastic Kubernetes Service (Amazon EKS) en cualquier lugar. Anteriormente, las actualizaciones de envío de nuestra integración de Kubernetes eran manuales y tardaban hasta dos semanas; ahora un proceso automatizado lleva una hora por semana.
Disminución del tiempo de respuesta para incidentes de seguridad
Uno de nuestros desafíos fue nuestra respuesta a las vulnerabilidades de seguridad: reaccionaríamos ante una vulnerabilidad solo cuando un cliente contactara al Soporte Técnico Global (GTS) con una escalada. Eso provocaría tanto la frustración de los clientes con nuestra integración como el estrés de los desarrolladores porque tendríamos que detener el trabajo planificado para parchear nuestro software.
Como parte de nuestro proceso de integración continua (CI), habilitamos herramientas de escaneo de código para mantenernos informados sobre las últimas vulnerabilidades descubiertas en nuestra base de código. Habilitamos CodeQL para buscar vulnerabilidades en nuestra base de código y usamos Trivy para garantizar que nuestras imágenes docker no incluyan vulnerabilidades inyectadas desde la imagen base y la biblioteca incluida con ella.
Uno de nuestros casos de uso comunes es la detección de vulnerabilidades en nuestra imagen base (Alpine). Este proceso nos alerta sobre problemas actuales que deben solucionarse. Al combinar el escaneo de vulnerabilidades con la gestión automática de dependencias, podemos parchear automáticamente las correcciones del código base sin necesidad de interacción humana. Nuestro flujo de trabajo se ejecuta semanalmente, lo que significa que los clientes obtienen una versión parcheada dentro de una semana de estar disponible una solución.
Como ejemplo concreto de nuestro mayor tiempo de respuesta, nuestro dashboard de seguridad nos alerta sobre las siguientes vulnerabilidades de seguridad en alpine:3.18.4 (la imagen que estamos usando en la integración nri-Kubernetes en ese momento):
Esas vulnerabilidades se solucionaron en alpine:3.18.5, publicado el 30 de noviembre de 2023, y alpine:3.19.0, publicado el 7 de diciembre de 2023. Renovate, nuestra herramienta universal de gestión de dependencias, creó [la] solicitud de extracción para ambas versiones el mismo día en que se publicaron y se incluyeron en nuestra versión el 8 de diciembre de 2023, solo un día después del lanzamiento de alpine:3:19.0 .
Las tres imágenes alpinas mencionadas tienen dos vulnerabilidades más que se detectaron posteriormente:
- CVE-2023-6129 el 9 de enero de 2024
- CVE-2023-6237 el 15 de enero de 2024
Esas dos vulnerabilidades pendientes están actualmente marcadas en nuestro dashboard de seguridad.
Tan pronto como Alpine publique una solución, nuestros clientes pueden esperar una versión corregida de nuestra integración dentro de una semana.
Proporcione soporte de vanguardia para la última versión de Kubernetes
Dar soporte a nuevas versiones de Kubernetes implica actualizar herramientas de prueba de terceros y realizar pruebas de conformidad exhaustivas para garantizar que una nueva versión de Kubernetes no tenga cambios importantes en nuestra integración. Un problema común que necesitamos validar es una API de Kubernetes que se encuentra en versión alfa o beta, ya que puede haber cambios sin previo aviso.
Con nuestras herramientas de gestión de dependencias totalmente automatizadas, una vez que las herramientas están implementadas, tenemos acceso inmediato a ellas. Además, debido a que nuestras pruebas de conformidad están completamente automatizadas, podemos acelerar el tiempo de validación, lo que nos permite estar a la vanguardia del soporte de Kubernetes.
Cuando esté disponible una nueva versión de Kubernetes, es fundamental actualizar nuestro flujo de trabajo de prueba para incorporar la última versión. Renovate, nuestra herramienta de gestión de dependencias, abrió automáticamente una [la] solicitud de extracción (PR) para actualizar Minikube a la última versión. Usamos minikube para poner en marcha rápidamente un clúster y luego ejecutar pruebas de un extremo a otro, y luego ejecutamos toda la batería de pruebas en cada versión de Kubernetes que admitimos. Una vez que ese minikube se actualiza con la última versión de Kubernetes, habilitamos las pruebas para esa versión en nuestro framework de pruebas. Si las pruebas confirman que la integración funciona como se esperaba, podemos declarar soporte para la última versión de Kubernetes. Debido a nuestro flujo de trabajo automatizado, actualizamos nuestro conjunto de pruebas para aprovechar la última versión de Kubernetes el mismo día en que minikube anunció el lanzamiento. Esto nos permitió probar la compatibilidad en un día y comunicar que nuestra integración de Kubernetes era compatible con la última versión siete días después del lanzamiento de minikube.
Sincronice la última versión del agente con los complementos de AWS EKS Anywhere
New Relic respalda el programa Amazon EKS Anywhere Partner al ofrecer nuestro agente de Kubernetes como un complemento listo para usar para el clúster Amazon EKS Anywhere. Desarrollamos un flujo de trabajo de GitHub Actions para abrir automáticamente una solicitud de extracción [la] cuando cortamos una nueva versión de nuestro agente. Esto mantiene a nuestro usuario final de Amazon EKS Anywhere actualizado con las últimas versiones de agentes, lo que garantiza que New Relic continúe pasando las últimas pruebas de conformidad y permanezca como socio validado de Amazon EKS Anywhere.
Automatizar el registro de cambios, las comunicaciones y la documentación
La creación y actualización de documentación consume mucho tiempo. Para obtener una cadencia semanal de lanzamientos, necesitábamos actualizar todos los canales de comunicación para nuestras partes interesadas internas, clientes externos y socios externos. Para automatizar las comunicaciones con todas estas partes interesadas, creamos un flujo de trabajo reutilizable que se ejecuta todas las semanas y actualiza automáticamente las notas de la versión, envía mensajes de Slack de las últimas versiones en los canales internos de las partes interesadas de New Relic y actualiza la documentación de los desarrolladores.
Luego, nuestro propio flujo de trabajo de GitHub compila la documentación y las notas de la versión, y envía comunicaciones a través de todos los canales. Para comunicarnos mejor con las partes interesadas internas, creamos nuestro propio robot agente K8s vinculado a nuestro flujo de trabajo de GitHub Actions, para que nuestros clientes y socios puedan recibir notificaciones automáticas sobre las actualizaciones de lanzamiento.
Conclusión
Un canal de CI ofrece más beneficios que simplemente hacer la vida más fácil a los desarrolladores: los clientes obtienen acceso a software más seguro, bien documentado y de vanguardia.
Un canal de CI eficaz es más que simplemente crear automatización en el proceso de liberación del agente; implica mejorar las pruebas para garantizar que no se produzcan regresiones en el proceso, detectar vulnerabilidades de seguridad rápidamente y abordarlas con prontitud, y comunicarse con todas las partes interesadas de forma clara y eficaz.
Próximos pasos
¡Consulte nuestra integración de Kubernetes de código abierto y consulte nuestros documentos para comenzar a obtener visibilidad de su clúster de Kubernetes!
Las opiniones expresadas en este blog son las del autor y no reflejan necesariamente las opiniones de New Relic. Todas las soluciones ofrecidas por el autor son específicas del entorno y no forman parte de las soluciones comerciales o el soporte ofrecido por New Relic. Únase a nosotros exclusivamente en Explorers Hub ( discus.newrelic.com ) para preguntas y asistencia relacionada con esta publicación de blog. Este blog puede contener enlaces a contenido de sitios de terceros. Al proporcionar dichos enlaces, New Relic no adopta, garantiza, aprueba ni respalda la información, las vistas o los productos disponibles en dichos sitios.
