KernelCare ePortal para grandes infraestructuras de alojamiento web

Integrar KernelCare ePortal en la gestión de flotas

KernelCare ePortal Es el componente de gestión y distribución gestionado internamente para los agentes de KernelCare en entornos Linux de gran tamaño. Agrupa conjuntos de parches, fuentes y claves de registro en un único punto controlado. De este modo, el administrador no solo decide si los hosts reciben parches, sino también desde qué fuente local y según qué lógica de autorización se lleva a cabo este proceso.

Sin el ePortal, los agentes se conectan directamente a la infraestructura de TuxCare. Esta suele ser la opción más sencilla para parques de servidores pequeños, en gran medida homogéneos y con conexión a Internet: no hay que actualizar, proteger ni supervisar ninguna plataforma central adicional. Sin embargo, a medida que aumenta el número de sistemas, esta simplicidad se convierte en un inconveniente cuando se requieren autorizaciones trazables o salidas de red limitadas.

En una flota de servidores de alojamiento suelen convivir servidores web, servidores de bases de datos, hosts de virtualización y sistemas de gestión con diferentes distribuciones y series de kernel. Un elemento central Adquisición de parches permite proporcionar a estos grupos técnicos feeds y claves específicos. Por lo tanto, ePortal no es una alternativa al agente de KernelCare, sino que amplía su obtención de conjuntos de parches con funciones de control y distribución locales.

Por lo tanto, el beneficio no se deriva únicamente del número de servidores. Son determinantes los ciclos de parches obligatorios, las obligaciones de comprobación y acreditación, las especificaciones de red, así como la cuestión de si un servicio central puede funcionar de forma fiable por sí mismo. Estos requisitos también determinan si la arquitectura adecuada es la replicación local, el almacenamiento en caché o la obtención directa.

Diferenciar entre «Live-Patching», «KernelCare» y «LibCare»

En Parcheado en directo El agente de KernelCare comprueba periódicamente si hay conjuntos de parches adecuados disponibles. Los descarga, los verifica y los instala en el núcleo en ejecución. De este modo, las correcciones de seguridad pueden activarse sin que sea necesario reiniciar el núcleo para este paso. Los conjuntos de parches aplicables dependen del núcleo instalado y de la distribución compatible.

KernelCare hace referencia a la oferta de parches en tiempo real para el núcleo. LibCare debe distinguirse de ello: se trata de un producto adicional opcional para determinados componentes del espacio de usuario y no es otro nombre para el parcheo del núcleo. Por su parte, ePortal no aplica parches al núcleo por sí mismo, sino que gestiona conjuntos de parches, fuentes y el registro de los agentes de KernelCare en una instalación empresarial local.

La denominación anterior, «KernelCare Plus», solo debería aparecer a la hora de clasificar documentación antigua. El fabricante ha dejado de comercializar este producto desde marzo de 2023 y lo ha sustituido por KernelCare. Por lo tanto, a la hora de realizar inventarios, es importante no equiparar los agentes instalados, los contratos y la documentación con los componentes o las funcionalidades actuales basándose en nombres de productos históricos.

La aplicación de parches en tiempo real no sustituye a un proceso de mantenimiento completo. Programado Reinicios Siguen siendo necesarias, por ejemplo, para los cambios habituales de kernel, las actualizaciones de hardware y firmware, las modificaciones de controladores, las tareas de configuración o los casos de error que no se pueden resolver en tiempo real. Por lo tanto, un plan operativo debería combinar la reducción del tiempo de exposición mediante conjuntos de parches con el mantenimiento de las ventanas de reinicio programadas, en lugar de eliminarlas sin sustitución alguna.

Cuándo resulta rentable la gestión centralizada de parches

ePortal es la solución adecuada cuando la empresa no solo necesita distribuir parches rápidamente, sino que también debe controlar de forma rigurosa su implementación. Esto afecta, por ejemplo, a los grupos de autorización independientes para los hosts Canary, el entorno de prueba y el de producción, a las reglas restrictivas de salida del cortafuegos o a los registros que indican qué host estaba asignado a qué feed. Asimismo, muchos sistemas con diferentes plataformas se benefician de una instancia de distribución gestionada de forma centralizada.

El beneficio adicional debe justificar el esfuerzo. Una instancia de ePortal requiere capacidad, actualizaciones, copias de seguridad, protección de acceso y supervisión; si se busca una alta disponibilidad, hay que añadir la replicación y la arquitectura de red. Por lo tanto, en el caso de unos pocos servidores similares con acceso a Internet autorizado, el acceso directo a través de la infraestructura de TuxCare suele resultar más sencillo. Un menor número de componentes supone, en este caso, una menor superficie de operaciones propia.

Desde el punto de vista económico, el control centralizado resulta especialmente importante en aquellos casos en los que la simultaneidad no planificada supondría un coste elevado: por ejemplo, en el caso de numerosos servidores web de clientes, clústeres de bases de datos o hosts de virtualización. Un Proceso de liberación De este modo, se pueden reflejar conjuntamente las similitudes técnicas y el riesgo empresarial. Los grupos no solo deben crearse en función de la ubicación, sino que también deben tener en cuenta la distribución, la serie de kernel, el hipervisor, el panel de control, el hardware y el perfil del cliente.

No se debe sobrevalorar la cobertura de seguridad. KernelCare solo proporciona parches en tiempo real para un núcleo mientras el proveedor de la distribución publique actualizaciones de seguridad para la serie de núcleos en cuestión. Además, la aplicación de parches en tiempo real no es una garantía general de que se hayan solucionado todas las vulnerabilidades. El estado de los parches, la compatibilidad con la distribución y el mantenimiento periódico deben comprobarse por separado.

Por lo tanto, la decisión operativa no se reduce a una regla general del tipo „cuanto más centralizado, mejor“. ePortal resulta adecuado cuando el control local, la distribución por niveles y la trazabilidad fiable satisfacen requisitos concretos. Si no existen estos requisitos, el acceso directo —deliberadamente sencillo— puede resultar más sólido. En el siguiente paso, el modelo de implementación deseado determina las necesidades de almacenamiento y las dependencias externas.

Seleccionar correctamente la duplicación y la caché

La elección del modelo de distribución determina el grado de independencia de una flota de servidores de alojamiento a la hora de obtener parches y la cantidad de infraestructura que debe gestionar para ello. En la descarga directa, los agentes de KernelCare descargan los conjuntos de parches a través de la infraestructura de TuxCare. Por el contrario, ePortal traslada la autorización, el almacenamiento local y la distribución a una instancia propia; puede duplicar los conjuntos de parches como un archivo completo o filtrado, o almacenarlos temporalmente según las necesidades.

Una réplica completa resulta útil cuando es necesario que los conjuntos de parches ya descargados sigan estando disponibles localmente incluso si se interrumpe la conexión externa, o cuando así lo exigen las autorizaciones internas vinculantes. Una duplicación filtrada limita el tamaño del archivo y el tráfico de datos a las distribuciones que realmente se utilizan. Para ello, el inventario debe registrar de forma fiable qué series de kernel y arquitecturas utiliza el parque informático; de lo contrario, faltará un archivo precisamente cuando un host lo necesite.

El Modo caché Ahorra memoria, pero no es sinónimo de un funcionamiento totalmente aislado. ePortal carga metadatos y obtiene los datos binarios de los parches de la fuente cuando es necesario; según la documentación, los datos binarios descargados permanecen dos semanas en la caché local. Esto puede ser suficiente para redes de agentes aisladas, siempre y cuando ePortal pueda utilizar la ruta de ascendente autorizada.

Un servidor ePortal que funcione con aislamiento total del aire debe evaluarse por separado. En ese caso, los nuevos archivos de parches deberán incorporarse mediante una transferencia manual planificada por separado. Para ello, define la verificación de fuentes, el control de integridad y de firmas, la autorización de soportes o de red, el orden de importación y las responsabilidades. Ni la duplicación filtrada ni la completa generan este proceso de forma automática; solo determinan qué archivos almacena ePortal localmente.

La planificación del almacenamiento no debe limitarse al tamaño actual del archivo. TuxCare recomienda, a modo orientativo, un almacenamiento SSD para ePortal con al menos 100 IOPS, así como un crecimiento de entre 4 y 5 GiB al mes. Estos datos del fabricante no sustituyen a la planificación de la capacidad: los objetivos de recuperación, las implementaciones paralelas, las latencias de red, el número de variantes del núcleo y los requisitos de supervisión pueden influir en la arquitectura más que la capacidad libre en disco.

Crear anillos de patch para flotas de servidores

Los «anillos de parches» permiten llevar a cabo una implementación controlada a partir de un conjunto de parches disponible de forma centralizada. Primero se da luz verde a un pequeño grupo «canario», al que le siguen la fase de preparación, un grupo de producción limitado y, por último, la producción general. Cada anillo requiere métricas de seguimiento definidas de antemano y un responsable; sin estos criterios, un retraso solo aplaza el riesgo, en lugar de evaluarlo.

Para los anillos de producción, es Estable El canal previsto. «Testing» es adecuado para un proceso de evaluación independiente y deliberadamente controlado, ya que este canal incluye todos los conjuntos de parches disponibles y, por lo tanto, puede contener conjuntos de parches adicionales que aún no están marcados como «Stable». Según la documentación, «Unstable» es un canal de acceso anticipado y no se recomienda su uso. Por lo tanto, «Testing» y «Unstable» no deben considerarse como prueba general de producción.

Los anillos deben agruparse en función de su similitud técnica, y no únicamente según la ubicación del centro de datos. Son relevantes la distribución y la serie del kernel, la plataforma de hardware, la virtualización, el panel de control, la pila del servidor web y el perfil del cliente. Un host «canario» con otra serie de kernel u otra tecnología de virtualización solo refleja de forma limitada el comportamiento de un sistema de destino en producción. En el caso del alojamiento compartido, los perfiles de recursos y las configuraciones del Gestores de LVE de CloudLinux en esta evaluación, ya que pueden influir en los patrones de carga y de fallos.

Hay que prestar especial atención a las nuevas instancias de ePortal. Según las especificaciones del fabricante, ePortal comprueba cada diez minutos si hay nuevos conjuntos de parches y los descarga, pero no los pone a disposición automáticamente en todos los feeds. Cuando se cargan archivos por primera vez, a los conjuntos de parches que contienen se les asigna la misma fecha de publicación. Por lo tanto, un retraso ya configurado puede provocar que, una vez transcurrido dicho plazo, todo el contenido inicial pase a un feed que se actualiza automáticamente.

Por lo tanto, durante la sincronización inicial, suspende la actualización automática de los feeds productivos y su asignación de claves en entorno productivo. Carga el stock inicial al completo, compruébalo junto con la configuración del feed y, solo después, asigna las claves de forma controlada a los anillos previstos o activa su actualización automática. La lógica de retardo se aplica posteriormente a los conjuntos de parches recién recibidos; no separa de forma fiable el stock inicial histórico de una nueva instancia.

Separar feeds, claves y clientes

Los feeds representan el aspecto técnico de los anillos de implementación: conectan el canal de parches y la lógica de retardo con un grupo de sistemas. Las claves de registro pueden vincularse a los feeds y dotarse de límites de servidor. De este modo, un operador puede, por ejemplo, proporcionar a plataformas internas, ofertas de servidores gestionados y entornos de clientes independientes distintas rutas de autorización, sin tener que modificar la configuración de los agentes en cada host por separado.

Sin embargo, esta asignación no constituye un límite de seguridad completo. La función opcional Unidades de negocio Admite la multitenencia en el ePortal, pero no sustituye ni a la segmentación de la red, ni a un modelo de permisos, ni a las competencias administrativas separadas. Asimismo, el registro de eventos, la gestión de secretos y la verificación de quién está autorizado a crear claves o modificar feeds deben planificarse y supervisarse periódicamente, independientemente de la funcionalidad del producto.

En entornos de clientes, la separación entre la gestión de parches y el resto del aislamiento del alojamiento es especialmente importante. Una clave puede limitar la asignación prevista de fuentes y el número de servidores registrables, pero no impide los accesos cruzados en otros componentes de la infraestructura. El aislamiento de procesos y del sistema de archivos siguen siendo tareas independientes; a este respecto, el artículo sobre CloudLinux SecureLVE el nivel de cuentas y sitios web.

A partir de la versión 2.14-1 de ePortal, se pueden utilizar claves API para la API pública como alternativa a la autenticación básica. La gestión de ePortal permite, entre otras cosas, que las claves API se puedan revocar individualmente y que tengan una fecha de caducidad opcional. Esto facilita la asignación de permisos independientes para las conexiones a la CMDB o la automatización de la configuración, siempre que se limiten deliberadamente los derechos de la cuenta de usuario correspondiente.

Almacena los tokens como secretos en un sistema de gestión de secretos, no en playbooks, imágenes, historiales de shell ni tickets. Se trata de una medida de seguridad operativa y no de una propiedad impuesta automáticamente por ePortal. Un proceso práctico asigna a cada clave un propietario, una finalidad, los productos permitidos, un límite de servidores y una fecha de rotación.

Las claves API deben revocarse de forma específica en caso de cambio de sistema, cambio de rol o cuando ya no se necesite el acceso a la automatización. Las claves de registro se gestionan de forma diferente: según la documentación, al eliminar una clave de este tipo, también se eliminan de ePortal todos los servidores registrados bajo ella. Por lo tanto, antes de eliminarla, planifica la migración a una nueva clave o el nuevo registro de los hosts afectados y, a continuación, comprueba su asignación de feeds y su estado de registro.

Gestionar la replicación y el TLS de forma fiable

Para un Distribución de parches de alta disponibilidad Se combinan varios nodos de ePortal de tal manera que los agentes de KernelCare se conecten a un nombre DNS de clúster común o a un equilibrador de carga HTTP. Para las tareas administrativas, en cambio, se utiliza un punto final de administración controlado y específico para cada nodo. Según el fabricante, no se debe utilizar el punto final común del clúster para realizar operaciones en la interfaz de administración de ePortal.

Antes de la puesta en producción, la arquitectura no solo debe tener en cuenta el fallo de un servidor ePortal. También son relevantes la resolución de DNS, el equilibrador de carga, los certificados, el almacenamiento de archivos de parches, la conexión a la fuente de parches y la accesibilidad desde cada segmento de red. Un segundo nodo sin una supervisión coordinada de la red y del funcionamiento mejora la disponibilidad solo de forma limitada; en caso de fallo, puede incluso ocultar estados anómalos.

Los nodos sincronizan los cambios mediante replicación. Esta sincronización no tiene por qué ser visible de forma inmediata. Especialmente en el caso del algoritmo «round-robin», un agente que acaba de registrarse puede acceder primero al primer nodo para registrarse y, justo después, a un nodo que aún no se ha sincronizado para la actualización. Por lo tanto, los procesos automatizados deberían incluir un breve tiempo de espera o una lógica de reintento con un número limitado de repeticiones, en lugar de considerar que la obtención inmediata de un parche constituye un estado final fiable.

Las desconexiones prolongadas también forman parte del escenario de fallo. Según la documentación, los protocolos de replicación se conservan durante siete días; si un nodo permanece desconectado durante más tiempo, puede perderse algunos cambios. El Retraso en la replicación Se trata, por tanto, de un estado operativo, no solo de un valor de diagnóstico. Por ello, tras producirse fallos en la red, debes comprobar las asignaciones de feeds, el conjunto de claves y el archivo de parches en el nodo que se ha recuperado, antes de que vuelva a atender con normalidad las solicitudes de los agentes.

La replicación se realiza a través de HTTP. Por lo tanto, sin un cifrado TLS adecuado, los datos de replicación se transmiten sin cifrar. Segmenta este tráfico de datos, como mínimo, en una red de confianza o configura el TLS de acuerdo con la arquitectura. Para los puntos finales de los agentes accesibles desde el exterior o entre redes, una cadena de certificados verificable es un componente importante de la Terminación TLS; desactivar la verificación de certificados no es una solución viable a largo plazo.

Si hay un proxy inverso delante de ePortal, es necesario configurar los nombres de host permitidos para que ePortal limite las solicitudes de encabezado de host. Además, el proxy debe reenviar correctamente el encabezado de host original y el campo «X-Forwarded-Proto». De lo contrario, pueden producirse URL externas erróneas, problemas de redireccionamiento o una identificación incorrecta del protocolo utilizado. Por lo tanto, esta configuración de los encabezados debería formar parte de cualquier modificación del proxy y de su aceptación.

Establecer registros, copias de seguridad y sistemas de supervisión

La aplicación de parches en tiempo real controlada requiere comprobaciones periódicas, no solo una instalación inicial satisfactoria. Registra, como mínimo, la asignación de feed de cada host, el último registro del agente, el estado de parches notificado y el estado de las claves de registro. Complementa estos datos con los equipos responsables y una decisión de autorización trazable. De este modo, ante un aviso de seguridad, se puede determinar de forma específica qué grupo utiliza cada vía de implementación.

Otros controles fijos se refieren al crecimiento del almacenamiento, al espacio libre para los archivos, al estado de la replicación y a la rotación o revocación de claves que ya no son necesarias. Las claves API son más adecuadas para las consultas automatizadas que las contraseñas de administrador compartidas, ya que se pueden gestionar y revocar de forma individual y, opcionalmente, se les puede asignar una fecha de caducidad. Como medida de seguridad operativa, guárdalas en un gestor de secretos, no en imágenes, playbooks ni tickets.

Para un clúster existente, la siguiente llamada de comprobación, que no realiza modificaciones, es un componente adecuado para la supervisión o para una comprobación de estado programada. Proporciona un estado resumido legible por máquina que incluye el retraso en la replicación. En caso de problema, la llamada finaliza con el código de salida 1; el sistema de supervisión debería alertar de este estado, pero también debería delimitar la causa basándose en los datos de los nodos y de la red.

kc.eportal replication --short-status

ePortal distingue entre una copia de seguridad con archivo de datos y una copia de seguridad de la base de datos propiamente dicha. La sintaxis completa del comando es: kc.eportal backup <path_to_archive>; crea un archivo de copia de seguridad que incluye los archivos del conjunto de parches. Con kc.eportal backup-db <path_to_backup> En cambio, si solo realizas una copia de seguridad de las bases de datos sin los archivos del conjunto de parches, esta segunda opción es adecuada para los datos de configuración y del servidor, pero no para el archivado local de parches.

Estas copias de seguridad del ePortal no incluyen automáticamente todo el entorno. La configuración del sistema operativo, la configuración del proxy inverso y del equilibrador de carga, los certificados TLS y las claves privadas, los ajustes de DNS, así como las configuraciones externas del cortafuegos o de gestión de secretos, requieren sus propias reglas de copia de seguridad y restauración. Define, para cada tipo de copia de seguridad, su finalidad, el periodo de conservación, la ubicación de almacenamiento y el procedimiento de restauración correspondiente.

Durante una restauración, es necesario detener el servicio ePortal. Planifica esta interrupción del servicio, informa a los equipos operativos afectados si es necesario y, a continuación, comprueba de forma específica la coherencia de los datos y la accesibilidad para los agentes. Una copia de seguridad solo se considera válida tras una planificación controlada Restaurar como resistente. En este sentido, una prueba no debe modificar accidentalmente los feeds productivos ni las asignaciones de claves.

Evaluar los patrones de fallo y tomar decisiones operativas

Si no se reciben los parches esperados, en primer lugar hay que distinguir entre falta de disponibilidad, falta de descarga y falta de autorización. Comprueba la versión instalada del agente y del ePortal, las claves y el feed asignados, la distribución adecuada, incluida la serie del kernel, así como la conexión con la fuente de los parches. Además, un parche puede faltar si la serie de kernel en cuestión ya no recibe actualizaciones de seguridad por parte del proveedor de la distribución; la aplicación de parches en tiempo real no elimina esta limitación.

Las notas históricas del fabricante relativas a versiones antiguas de los componentes no deben interpretarse como una especificación de versión definitiva. Una nota de diciembre de 2025 se refería, entre otras cosas, a KernelCare-Agent 3.x y ePortal 2.20 en el contexto de un nuevo formato de parche firmado. Por lo tanto, antes de realizar actualizaciones, comprueba la versión actual Matriz de compatibilidad, las versiones realmente instaladas y el orden de actualización aprobado internamente.

En el modo de caché, una falta de caché con acceso externo restringido puede retrasar la descarga del parche, ya que el archivo binario necesario aún no se encuentra en el sistema local. Esto no constituye una prueba de un funcionamiento totalmente aislado. Para las zonas restrictivas, especifica qué conexiones están permitidas, cómo se transfieren los archivos que faltan y quién es responsable de la autorización, la integridad y el momento de dicha transferencia.

Otro problema que puede surgir es una implementación inesperadamente amplia tras la primera descarga de archivos de parches en una nueva instancia. Dado que, para la lógica de retardo, los archivos descargados por primera vez aparecen simultáneamente como nuevos, un retardo establecido previamente no protege de forma fiable contra una implementación conjunta. Retrasa las actualizaciones automáticas de los feeds y las asignaciones de claves en producción durante la sincronización inicial, comprueba el inventario inicial y, solo después, activa los anillos de producción de forma controlada.

Las brechas de replicación tras una interrupción prolongada de un nodo y los proxies inversos defectuosos requieren medidas diferentes: las primeras exigen una sincronización del estado del nodo, mientras que las segundas requieren una comprobación de TLS, de los nombres de host permitidos y de los encabezados reenviados. Ambos casos deben incluirse en manuales de procedimientos con una escalación clara. Un reinicio general no soluciona ni la falta de datos ni un límite de confianza incorrecto.

ePortal resulta especialmente útil cuando se requieren realmente ciclos de parches, distribución local, salidas de red controladas o autorizaciones verificables. Para un parque de servidores pequeño, homogéneo y con conexión a Internet, suele ser más sencillo el acceso directo a través de la infraestructura de TuxCare. Por lo tanto, la decisión debería sopesar el esfuerzo operativo adicional frente a las obligaciones concretas de control y justificación, y no basarse únicamente en el número de servidores.