Mostrando entradas con la etiqueta docker. Mostrar todas las entradas
Mostrando entradas con la etiqueta docker. Mostrar todas las entradas

martes, abril 15, 2025

Cómo servir modelos de ML e IA (LLMs) en Kubernetes con KServe: Autoscaling Inteligente y Eficiencia en GPU

La Inteligencia Artificial no se detiene, y su adopción en producción tampoco, pero hay una brecha silenciosa entre entrenar un modelo y servirlo de forma eficiente, escalable y mantenible. Aquí es donde Kubernetes se convierte en el aliado perfecto, y donde herramientas como KServe (el sucesor de KFServing) brillan.

Figura 1: Cómo servir modelos de ML e IA (LLMs) en Kubernetes con KServe.
Autoscaling Inteligente y Eficiencia en GPU

En este artículo te cuento cómo puedes montar una plataforma moderna para servir modelos de IA y LLMs sobre Kubernetes, aprovechar las novedades más recientes de KServe, y hacer que tu infraestructura escale según uso real y consumo de GPU

Spoiler: sí, se puede tener eficiencia, velocidad y buena arquitectura al mismo tiempo.

¿Por qué servir modelos sobre Kubernetes?

Entrenar un modelo es sólo la mitad del camino. Lo difícil viene después: ponerlo a funcionar en producción de forma fiable, segura y escalable.
  • Alta disponibilidad
  • Autoescalado según carga real
  • Seguridad, versionado, observabilidad
  • Integración con pipelines CI/CD y orquestadores como Argo Workflows o Kubeflow
Kubernetes permite todo esto. Pero no hay que reinventar la rueda, y ahí entra KServe.

Antes de continuar… ¿Qué es Kubeflow y qué ofrece?

Kubeflow es una plataforma Open Source pensada para desplegar, escalar y gestionar flujos de trabajo de Machine Learning (ML) sobre Kubernetes. Su objetivo principal es llevar el desarrollo de modelos de ML a producción de forma reproducible, escalable y portátil.


Kubeflow no es una herramienta única, sino un conjunto de componentes modulares que cubren distintas etapas del ciclo de vida del modelo de Machine Learning:
  • Kubeflow Pipelines: Orquestación de pipelines de ML (entrenamiento, preprocesado, validación, etcétera).
  • Katib: AutoML y búsqueda de hiperparámetros.
  • KServe (antes KFServing): Serving de modelos con escalado automático y despliegues sin downtime.
  • Notebook Servers: Entornos Jupyter en Kubernetes, listos para trabajar con datos y modelos.
  • Central Dashboard y Profiles: Gestión multiusuario, RBAC, y control de recursos por equipo o proyecto.
Kubeflow se posiciona como una plataforma completa para MLops sobre Kubernetes, especialmente útil cuando necesitas estandarizar y automatizar todo el flujo de trabajo desde el desarrollo hasta el despliegue.

Figura 4: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen TorranoFran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Aunque KServe puede funcionar por separado de Kubeflow, se integra perfectamente como pieza de serving dentro del stack Kubeflow.

KServe: servir modelos como si fueran microservicios

KServe es un componente de Kubeflow, pero puede usarse de forma independiente. Te permite desplegar modelos como recursos de Kubernetes (CRDs), exponiéndose vía REST o gRPC, con soporte para, entre otros, PyTorch, TensorFlow, XGBoost, SKLearn, ONNX etc... e incluso tus propios contenedores.
  • Lo bueno: cada modelo es un InferenceService, y tú defines lo que necesita: CPU, GPU, versiones, etcétera.
  • Lo brutal: KServe soporta escalado automático hasta cero réplicas, y las vuelve a levantar cuando hay tráfico. Nada de infra desperdiciada.
GPU autoscaling
  • Puedes escalar vertical y horizontalmente tus modelos en GPU.
  • Mediante Prometheus Adapter + HPA Custom Metrics, se puede escalar según uso de memoria GPU, uso de batch o incluso peticiones por segundo.
Raw Deployment mode
  • 1.- KServe por defecto usa Knative para autoescalar.
    • Escala basándose en tráfico HTTP (requests por segundo).
    • Esto no es suficiente cuando usas GPUs, ya que estas no se liberan con tráfico bajo.
    • Además, los workloads con GPU suelen tener procesamiento batch o tiempos largos de inferencia, donde Knative no escala de forma óptima.
  • 2.- Para modelos en GPU, muchas veces no se usa Knative, sino raw deployment mode en KServe, para tener más control.
    • Aquí ya no dependes de Knative, sino de un Deployment + HPA.
  • 3.- Prometheus Adapter + HPA con métricas personalizadas
    • Prometheus Adapter permite exponer métricas personalizadas (por ejemplo: uso de memoria GPU, utilización del device, número de peticiones, etc.) como Custom Metrics API.
    • Con eso puedes configurar un HPA (Horizontal Pod Autoscaler) para escalar los pods de inferencia según esas métricas.
    • Esto se usa en entornos donde se necesita un autoscaling más inteligente y específico, especialmente con GPU.
Scale down a cero

¿Qué significa “scale down a cero” en KServe?
  • Es la capacidad de escalar a cero réplicas un modelo cuando no está recibiendo peticiones, y volver a levantarlo automáticamente (auto-scale up) cuando llega una nueva petición.
¿Qué beneficios tiene esta solución?
  • Ahorro de costes brutal: Si tienes muchos modelos desplegados pero no todos se usan constantemente, con scale-to-zero no malgastas CPU ni RAM. Ideal en entornos cloud donde pagas por uso de recursos, como en clusters gestionados (EKS, GKE, AKS…).
  • Optimización de recursos en el cluster: En vez de mantener todos los pods activos, los que no reciben tráfico se eliminan temporalmente, dejando espacio a otros workloads que sí lo necesitan. Ayuda a evitar sobrecargas y reduce la necesidad de sobredimensionar el cluster.
  • Despliegue eficiente de muchos modelos: Puedes permitir que muchos equipos o usuarios publiquen sus propios modelos sin saturar el sistema. Esto habilita patrones como “multi-tenancy” eficiente para inferencias bajo demanda.
  • Escalado bajo demanda: Si un modelo recibe tráfico repentino, KServe lo activa rápidamente. Esto es perfecto para modelos que solo se usan de vez en cuando o que funcionan como microservicios ML reactivos.
Canary rollout

KServe soporta dividir tráfico entre versiones de modelo (v1, v2, etcétera). Por ejemplo puedes hacer un 90/10, observar métricas y logs, y luego promover o descartar la nueva versión. Pero… ¿qué es Canary rollout

Figura 6: Canary Rollout

El Canary rollout te permite probar una nueva versión de un modelo (por ejemplo v2) con una pequeña parte del tráfico real, mientras que la versión estable (v1) sigue sirviendo la mayoría del tráfico. Esto es clave para:
  • Validar rendimiento y exactitud del modelo en producción.
  • Detectar errores o regresiones antes de hacer el cambio completo.
  • Observar métricas y logs reales sin impactar a todos los usuarios.
Ejemplo de Canary rollout en KServe
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
 name: sklearn-iris
 namespace: kserve-test
spec:
 predictor:
   model:
     modelFormat:
       name: sklearn
     storageUri: "gs://kfserving-examples/models/sklearn/1.0/model-1"
   canaryTrafficPercent: 10
   canary:
     model:
       modelFormat:
         name: sklearn
       storageUri: "gs://kfserving-examples/models/sklearn/1.0/model-2"
  • storageUri: del bloque principal. Apunta a model-1, la versión actual y estable del modelo.
  • canary: Define model-2 como la nueva versión que se quiere probar.
  • canaryTrafficPercent: 10: indica que el 10% del tráfico entrante será dirigido a model-2, mientras que el 90% restante seguirá siendo servido por model-1.
Novedades destacadas

Desde la versión v0.15.0, KServe ha incorporado mejoras significativas para el despliegue de modelos de lenguaje (LLMs), incluyendo soporte distribuido con vLLM, mejoras en el runtime de Hugging Face y optimizaciones para almacenamiento y readiness. Esto abre la puerta a escenarios como:
  • Servir un modelo LLaMA o Falcon en múltiples nodos GPU.
  • Integrar modelos de Hugging Face con pipelines existentes y autoscaling por demanda.
  • Aprovechar técnicas avanzadas como RAG o agentes con herramientas directamente desde Kubernetes.
Si antes KServe era ideal para modelos tradicionales de Machine Learning, ahora también lo es para los modelos de última generación. 

Algunas otras funcionalidades adicionales:
  • Soporte para descarga de archivos individuales desde GCS Google Cloud Storage), lo que mejora los tiempos de inicio.
  • Readiness probes más precisas, especialmente para modelos en transformers, mejorando la confiabilidad de despliegues en producción.
  • Introducción de “KServe Guru” en Gurubase.io, un espacio para encontrar y compartir soluciones de la comunidad.
Arquitectura tipo: Cómo lo montamos

Una plataforma de inferencia moderna sobre Kubernetes podría verse así:
  • KServe + Istio: para gestión de modelos como microservicios.
  • Knative Serving: para escalado a 0, cold start optimizado.
  • Prometheus + Grafana: para métricas personalizadas de GPU o latencia.
  • Cert-Manager + Ingress Gateway: TLS automático para exposición segura.
  • ArgoCD o Flux: GitOps para definir modelos como código.
  • GPU Operator de NVIDIA: para gestionar drivers y nodos GPU
¿Y si no quieres montar todo esto desde cero?

Aunque herramientas como KServe y Kubeflow son muy potentes, su configuración desde cero puede requerir tiempo, conocimientos avanzados de Kubernetes y una buena integración con infraestructura cloud o on-prem. Aquí es donde entran plataformas como Axebow.io, que están diseñadas para facilitar el despliegue de aplicaciones, entornos de Machine Learning e IA y plataformas completas sobre Kubernetes. Esto permite que equipos de IA y Data Science se enfoquen en desarrollar y servir modelos sin preocuparse por los detalles de infraestructura.


Axebow.io proporciona configuraciones optimizadas para rendimiento, autoscaling con GPU y despliegues reproducibles, lo que reduce la complejidad operativa y acelera el time-to-production. Si estás interesado en saber más, contacta con nosotros.

Autores: Miguel Angel Chuecos Carlos García Blanco, CEO de Kumori

miércoles, enero 15, 2025

"Arquitectura de Seguridad y Patrones de Diseño". El nuevo libro de 0xWord escrito por Elías Grande

Ya os he dicho lo contentos que nos ponemos cuando tenemos un nuevo libro en 0xWord que presentar, y tener el primero del año 2025 en Enero hace que sea un día feliz. Como digo muchas veces, cuesta mucho sacar adelante este proyecto editorial, y poder decir que hoy tenemos ya a la venta el nuevo ejemplar de "Arquitectura de Seguridad y Patrones de Diseño" escrito por Elías Grande, y en el que yo he tenido el placer de escribir el prólogo es por si un hito que tenemos que celebrar. 
El nuevo libro de 0xWord escrito por Elías Grande

El libro, como os he dicho, lo ha escrito Elías Grande, del que he publicado muchos artículos a lo largo de los últimos años por aquí. Ha estado trabajando en mi equipo, es un ponente destacado en conferencias de seguridad, un trabajador de este mundo y autor ya de otro libro de seguridad. Un autentico profesional del mundo de la cibrerseguridad y voz autorizada.

Este libro es un manual de referencia para aquellos que quieren pasar a ser Arquitectos de Seguridad, y hacerlo siguiendo las normas de la Ingeniería de Seguridad. Para eso se analizan los diferentes Patrones de Diseño y cómo estos se aplican para diferentes tipos de servicios y entornos. Arquitecturas de seguridad para Microservicios, para servicios Web3 o para entornos IoT son tratados en el libro.
El nuevo libro de 0xWord escrito por Elías Grande.

Para ello, Elías Grande va explicando uno a uno entornos concretos y los va diseñando desde un punto de vista de seguridad, como lo haría un Arquitecto de Seguridad, para no deteriorar el servicio pero dotar desde la ingeniería de la robustez necesaria para hacer que el servicio se pueda lanzar y operar de manera segura. 

Los activos más importantes para cualquier organización son sus usuarios y sus datos. Los usuarios son los que consumen los servicios ofrecidos por las aplicaciones de la organización, y son a través de estas aplicaciones por las que fluyen sus datos e información. Debido a esto, es sumamente relevante mejorar la comprensión y entendimiento, desde un punto de vista de seguridad, de las diferentes formas que pueden tomar estas aplicaciones en función de los modelos de negocio, casos de uso e infraestructura tecnológica disponible de cada organización. 
 
En este libro se abordan los diferentes tipos de arquitecturas software más extendidas a día de hoy a nivel industria como son: las arquitecturas orientadas a servicios, las arquitecturas orientadas a eventos, las arquitecturas de microservicios y las arquitecturas en el Internet de las Cosas. Para cada una de dichas arquitecturas, se analizan en detalle sus características así como sus patrones de diseño arquitecturales más relevantes, teniendo en cuenta los diferentes aspectos y componentes de seguridad a considerar al implementar cada uno de ellos. 
 
Este enfoque proporciona a las disciplinas de seguridad ofensiva y defensiva, de auditoría, y de diseño y desarrollo, el conocimiento y herramientas necesarias para aplicar por diseño la seguridad en las aplicaciones 
 
Estas son las palabras con las que Elías Grande describe este libro dedicado a aquellos que quieren dar un paso en su formación 360 de ciberseguridad y conocer cómo hacer para una aplicación o un servicios un Arquitectura de Seguridad utilizando Patrones de Diseño. Aquí tienes el índice completo:

Figura 4: Índice del libro "Arquitectura de Seguridad y Patrones de Diseño".
El nuevo libro de 0xWord escrito por Elías Grande.

Además, Elías Grande no es un escritor nuevo, ya que no sólo tienes todos su papers publicados en la red, sino que además ya fue co-autor del libro de Docker: SecDevOps (& DevSecOps) que va ya por la segunda edición.

Así que, si quieres un libro para formarte como Arquitecto de Seguridad, ya tienes este texto disponible para que te lo puedas comprar, y además, puedes usar tus Tempos de  MyPublicInbox. Para terminar, te recuerdo que tendrás también 100 Tempos de MyPublicInbox por la compra de este libro de "Arquitectura de Seguridad y Patrones de Diseño" y que además, puedes pagar completa o parcialmente este libro con Tempos de MyPublicInbox. Aquí te explico cómo se hace. 

Usar tus Tempos de MyPublicInbox 0xWord para adquirir este libro

La idea es muy sencilla, hemos creado un Buzón Público de 0xWord en MyPublicInbox y tenemos disponible el módulo de transferencias de Tempos entre cuentas siempre que el destinatario sea un Perfil Público de la plataforma. Para que se puedan hacer estas transferencias, primero debe estar el Perfil Público destinatario de la transferencia en la Agenda.

Figura 6: Perfil de 0xWord en MyPublicInbox. Opción de "Añadir a  la Agenda".
https://MyPublicInbox.com/0xWord

Para dar de alta un Perfil Público en tu agenda, solo debes iniciar sesión en MyPublicInbox, y con la sesión iniciada ir a la web del perfil. En este caso, a la URL del perfil público de 0xWord en MyPublicInbox, - https://MyPublicInbox.com/0xWord - donde te aparecerá la opción de "Añadir a la agenda". Cuando acabe este proceso, podrás ir a la opción Agenda de tu buzón de correo en MyPublicInbox y deberías tener el Perfil Público de 0xWord allí.

Figura 7: Cuando lo agregues estará en tu agenda

Una vez que lo tengas en la agenda, ya será tan fácil como irte a tu perfil - se accede haciendo clic en la imagen redonda con tu foto en la parte superior - y entrar en la Zona de Transferencias. Desde allí seleccionas el Buzón Público de 0xWord, el número de Tempos que quieres transferir, y en el concepto debes poner que es para recibir un código descuento para usar en la tienda de 0xWord.


No te preocupes por el texto concreto, porque los procesamos manualmente como los pedidos de se hacen en la tienda. 

Canjear 500 Tempos por un código descuento de 5 €

La última opción es bastante sencilla. Solo debes irte a la sección de Canjear Tempos -> Vales para Tiendas, y "Comprar" por 500 Tempos y código de 5 €. Es lo mismo que enviar la transferencia pero en un paquete de 500 Tempos y de forma totalmente automatizada, así que solo con que le des a comprar recibirás el código descuento y lo podrás utilizar en la tienda de 0xWord.com

Así que, si quieres conseguir nuestros libros de Seguridad Informática & Hacking aprovechando los Tempos de MyPublicInbox podrás hacerlo de forma muy sencilla y mucho, mucho, mucho más barato. Y así apoyas este proyecto tan bonito que es 0xWord.com.

Ser escritor de libros de 0xWord

Además, todos lo que queráis convertiros en escritores y hacer un proyecto de libro con nosotros. Podéis también enviarnos vuestra propuesta a través del buzón de 0xWord en MyPublicInbox, y si sois Perfiles Públicos de la plataforma, podéis entrar en la sección de Mi Perfil -> Servicios para ti y solicitar más información sobre el proceso de escribir un libro en 0xWord.
Nuestro equipo se pondrá en contacto contigo y evaluará tu proyecto de publicación de libro. Ya sabes que principalmente de Seguridad Informática & Hacking, y puede ser técnico, súper-técnico, o divulgación, y si es una novela... podemos estudiarlo también.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

lunes, octubre 21, 2024

Platform Engineering as a Service con Axebow: La encrucijada de la Nube y la ilusión del progreso.

Desde hace más de una década la industria tecnológica ha estado experimentado una evolución constante hacia la computación en la nube, impulsada por las promesas de escalabilidad, flexibilidad y eficiencia en costes. Evolución que ha ido acompañada por el surgimiento de una plétora de herramientas y plataformas, intencionalmente diseñadas para simplificar el desarrollo y la gestión de recursos en la nube. Pero... ¿hemos avanzado lo suficiente en la última década?.
Si nos paramos a analizar la situuación actual, a pesar de estos avances, la complejidad fundamental de aprovisionar y gestionar recursos virtualizados sigue siendo prácticamente la misma. Hemos pasado de escribir scripts personalizados para orquestar nuestra infraestructura a utilizar herramientas más sofisticadas, como por ejemplo Terraform.

Paralelamente, y a un nivel superior, hemos introducido un mayor grado de automatizaciones con orquestadores de contenedores como Kubernetes. Sin duda hemos ido progresando, pero, ¿estamos significativamente mejor que hace diez años a la hora de simplificar la puesta a punto de servicios basados en software?

La Evolución de las Herramientas de Desarrollo Cloud

En los primeros días de la computación en la nube, desarrolladores y administradores de sistemas dependían en gran medida de scripts manuales para gestionar máquinas virtuales y otros recursos. Scripts de shell, Python y otras soluciones ad hoc fueron la norma (aún lo son en algunos casos). Estos scripts a menudo son específicos de la plataforma, carecen de estandarización y son difíciles de mantener. Lo que es peor, en muchos casos son scripts específicos para la puesta en producción de servicios concretos, por lo tanto no generalizables.

La llegada de la aproximación de Infraestructura como Código (IaC, en sus siglas en inglés) y sus herramientas (Terraform, CloudFormation, Ansible, ...), prometió poner orden en el caos. Estas herramientas permiten a los ingenieros definir configuraciones de infraestructura en código, versionarlas y desplegarlas de manera confiable en diferentes entornos. A primera vista, esto parece un avance significativo.

También hemos visto una proliferación de marcos y herramientas que intentan simplificar el desarrollo en la nube, introduciendo nuevas abstracciones que, por desgracia, conllevan curvas de aprendizaje importantes y muchas oportunidades para errar en su uso.
Kubernetes es un excelente ejemplo. Nació de la necesidad de facilitar la orquestación de contenedores, y ha tenido éxito hasta cierto punto. Pero para muchos desarrolladores, la transición a Kubernetes a menudo se siente como intercambiar un conjunto de complejidades (p.e., gestión de servidores) por otro (gestión de manifiestos, clústeres, políticas de red, etc...). El viejo dolor de cabeza de gestionar recursos ha sido reemplazado por nuevas complejidades en la gestión de objetos de Kubernetes.

La Persistencia de la Complejidad

Por lo tanto, a pesar de la adopción de herramientas como las ya expuestas, la complejidad asociada con el desarrollo en la nube no ha disminuido sustancialmente. Podemos enumerar algunas de sus razones:

1. Curvas de Aprendizaje nada despreciables: Herramientas como Terraform (o incluso Kubernetes) introducen sus propios lenguajes específicos de dominio (DSL) (interno, en el caso de Kubernetes, basado en YAML), y conceptos que sus usuarios deben aprender. Comprender las sutilezas de estos lenguajes puede ser tan desafiante como dominar un nuevo lenguaje de programación.

2. Características Específicas de la Plataforma: Aunque las herramientas de IaC intentan ser independientes de la plataforma, la realidad es que proveedores cloud como AWS, Azure, Google Cloud, etc... tienen servicios, configuraciones y peculiaridades únicas. Esto requiere un profundo conocimiento específico del proveedor cloud, lo que va en contra del objetivo de simplificación de las herramientas. Plataformas como Kubernetes tampoco se salvan de tratar con esta especificidad.

3. Servicios en la Nube en Evolución Constante: Los proveedores Cloud lanzan continuamente nuevos servicios y características. Mantenerse al día con estos cambios requiere aprendizaje constante y actualizaciones al código de infraestructura existente, añadiendo una carga adicional de mantenimiento.

4. Complejidad de los Sistemas Distribuidos: Los servicios basados en software son inherentemente aplicaciones distribuidas. Utilizan microservicios (posiblemente basados en contenedores), arquitecturas sin servidor o una combinación de ambas. Gestionar su ciclo de vida en la nube introduce capas adicionales de complejidad que las herramientas de IaC por sí solas no pueden abstraer (ni es su objetivo).

5. Gestión de Estado y Depuración: Manejar el estado de los recursos en la nube es una tarea no trivial. Herramientas como Terraform mantienen archivos de estado que pueden convertirse en fuentes de conflictos, llevando a problemas de despliegue difíciles de depurar.

Caso concreto I: Scripts de Terraform vs. Scripts Tradicionales

Consideremos la transición de scripts tradicionales a scripts de Terraform. Si bien Terraform proporciona una forma estructurada de definir recursos, los scripts pueden volverse extremadamente complejos en infraestructuras grandes. Módulos, variables y gráficos de dependencias intrincados pueden hacer que las configuraciones de Terraform sean tan difíciles de leer y mantener como los scripts que reemplazaron.

Además, errores en las configuraciones de Terraform pueden conducir a despliegues parciales o modificaciones no intencionadas de recursos, requiriendo una planificación cuidadosa y pruebas exhaustivas, prácticas que eran igualmente necesarias con los scripts tradicionales.

Caso concreto II: Kubernetes vs. Métodos de Implementación Tradicionales

Consideremos el auge de Kubernetes como la solución de facto para la orquestación de contenedores. Kubernetes promete simplificar la implementación, escalado y gestión de aplicaciones en contenedores. Sin embargo, esta simplificación aparente viene con su propio conjunto de complejidades.

• Configuraciones Complejas: Kubernetes utiliza archivos YAML para definir recursos como Pods, Servicios y Deployments. Estos archivos pueden volverse extremadamente detallados y difíciles de gestionar, especialmente en aplicaciones grandes con múltiples microservicios.

• Curva de Aprendizaje Pronunciada: Dominar Kubernetes requiere una comprensión profunda de conceptos como namespaces, ingress controllers, volúmenes persistentes y políticas de red. Esto puede ser abrumador para equipos que migran desde entornos tradicionales.

• Infraestructura Adicional: Para ejecutar Kubernetes, a menudo se necesita infraestructura adicional, como sistemas de almacenamiento distribuidos y soluciones de red avanzadas. Esto añade más capas que deben configurarse y mantenerse.

• Herramientas Complementarias Necesarias: La gestión efectiva de un clúster de Kubernetes a menudo requiere herramientas adicionales como Helm para la gestión de paquetes, Prometheus para monitorización y Grafana para visualización, cada una con sus propias complejidades. No sólo esto, configurar un clúster Kubernetes para dotarlo de funciones básicas (ie. ingress, networking, ...) requiere tener que elegir de entre un nutrido elenco de soluciones, cada una con sus pros y sus cons, así como sus propias complejidades de configuración y gestión.

• Depuración y Resolución de Problemas: Cuando algo sale mal en Kubernetes, identificar y resolver el problema puede ser significativamente más difícil debido a la naturaleza distribuida y dinámica del sistema.

En comparación con los métodos de implementación tradicionales, donde las aplicaciones se despliegan en servidores físicos o máquinas virtuales con configuraciones más estáticas, Kubernetes introduce un nivel de abstracción que, si bien es poderoso, también puede ser difícil de manejar sin la experiencia adecuada.

El Problema Subyacente

En el fondo, el problema es la complejidad inherente de los entornos en la nube. Las herramientas sólo pueden abstraer la complejidad hasta cierto punto. Mientras los servicios en la nube sigan siendo tan diversos y complejos como lo son, gestionarlos requerirá un esfuerzo y conocimiento significativos.

La consecuencia es que es necesario un buen grado de especialización para gestionar buena parte de las tareas de gestión de recursos que es preciso tener en cuenta no sólo a la hora de poner servicios en producción, sino también durante el proceso de desarrollo del software, creando un buen número de ineficiencias.

¿Qué Necesitamos Cambiar?

Para responder a esta pregunta, debemos clarificar cuales son (o deberían ser) nuestros objetivos. La IaC y sus herramientas tienen como objetivos simplificar (¿?) el proceso de aprovisionamiento de recursos y servicios en la nube. Sin embargo, podemos argumentar que esto no es realmente el objetivo último. El objetivo último debería ser doble:

1. Por una parte habilitar a los equipos de desarrollo el acceso transparente a aquellos recursos virtualizados que necesitan para apoyar su proceso de desarrollo.

2. Por otra parte, permitir la gestión ágil del ciclo de vida de los servicios basados en el software producido por esos equipos de desarrollo.

Es nuestro punto de vista que atender dichos objetivos sólo va a ser posible elevando el nivel de las abstracciones manejadas por desarrolladores y gestores de servicios de modo que la gestión de los recursos virtualizados se transparente gracias a la automatización que esos niveles de abstracción permiten.


Esta aproximación no es novedosa. Baste ver la evolución de los sistemas operativos modernos: el desarrollador no se preocupa de la gestión de los recursos existentes en el ordenador. Confía en el sistema operativo subyacente, y todos los actores que operan por encima del sistema operativo manejan un conjunto de abstracciones simples y a la vez potentes que les permiten ignorar totalmente la gestión de los recursos necesarios para las tareas de cómputo soportadas.


Esta es también la dirección tomada por sistemas que, como Kubernetes, introducen un alto grado de automatización, aunque en este caso a un precio de complejidad que, en nuestra opinión, genera sus propios problemas.


En conclusión, para lograr un progreso significativo, debemos poner el foco en la simplificación de las plataformas que ponemos a disposición de los equipos de desarrollo. La complejidad debe residir en la implementación de la plataforma, no en su uso, como frecuentemente sucede hoy en día. Solo cuando logremos que el acceso a la tecnología de la nube sea tan transparente como el acceso a la electricidad podremos constatar la dimensión de un auténtico progreso.


Es lo que se ha pretendido con Axebow simplificar el proceso de despliegue reduciendo la complejidad existente y descrita. Podéis probar el servicio SIN COSTE durante ellos meses de octubre y noviembre.

Saludos,

lunes, febrero 26, 2024

Enseñando hacking ético a través del aprendizaje basado en retos

El próximo 5 de marzo impartiré por undécima edición consecutiva un RootedLab en RootedCON. En esta ocasión estaré para dar un taller sobre Hacking Ético, el cual se lleva dando durante dos ediciones con un enfoque basado en retos y escenarios para enseñar técnicas de hacking ético actuales. Un lab intenso donde, después del lab, dispondrás de una semana extra para consultar preguntas y seguir jugando con los escenarios propuestos para tu aprendizaje. Esa semana extra se llevará a cabo a través de una sala de chat en la plataforma de MyPublicInbox.
Además, si quieres venir a RootedCON, te recuerdo que puedes comprar tu entrada de RootedCON 2024 con Tempos, ya que se han puesto 50 entradas a la venta que puedes comprar con 10.000 Tempos, así que solo debes ir a tu cuenta de MyPublicInbox y conseguirlas con este precio especial.


Y ahora, centrándome en el RootedLab de Hacking Ético, hay que remarcar que la finalidad que nos hemos marcado en este lab es el de enseñar Hacking Etico a través de retos que facilitan el entrenamiento y la adopción de metodología de pentesting. Se proporciona un aprendizaje de técnicas del día a día del pentester a través del uso de diferentes escenarios reales y clasificados por las diferentes técnicas y por nivel. 

Los objetivos que tiene este RootedLab es:
  • Aprender metodología para hacer un pentesting práctico y resolver problemas.
  • Enfrentarse a entornos reales.
  • Resolver escenarios a través de un entrenamiento práctico.
Docker como plataforma de pentesting

En el artículo de hoy quiero enseñar cómo es un escenario de hacking a través de plataformas como Docker, el cual es perfecto para disponer de recursos para poder enseñar: enumeración, reconocimiento, escaneos, identificación de vulnerabilidades, explotación, escaladas de privilegios, pivoting, movimientos laterales, etcétera.

En otras palabras, son perfectos para disponer de escenarios reales y poder entrenar a equipos de pentesting. Estos entornos pueden montarse de forma local en una red propia o en los propios equipos de los pentesters.


Es más, se puede montar de forma sencilla un tipo de CTF o Capture The Flag. En este caso, se mostrará cómo con un poco de conocimiento de Docker se puede construir lo necesario para crearse escenarios y poder jugar con todo ello. Ya lo comentaron en este artículo titulado "Cómo montar un entorno de pentesting desde cero con Docker", nuestros compañeros Rafael Troncoso  y Fran Ramírez.

¿Qué cosas tenemos que tener en cuenta? 

A la hora de crear un entorno para entrenamiento de pentesting se debe tener en cuenta lo siguiente:
  • La imagen con las vulnerabilidades y las configuraciones preparadas.
  • El volumen para datos que deben permanecer y mantenerse tras la creación y destrucción de los contenedores.
  • Las redes gestionadas, idealmente, a través de un docker-compose.
  • La gestión de puertos entre entorno físico y contenedores.
La creación paso a paso del docker-compose o de la tecnología que se quiera usar de Docker la dejamos para otro artículo, pero se puede ver en la siguiente imagen lo fácil que puede ser levantar un entorno dónde se dispone de diferentes de máquinas, el cual puede tener diferentes tipos de redes y diferentes tipos de servicios.

Figura 5: Docker compose up

Se puede leer un mensaje que dice “i am kalilinux (pentester machine)”. Se proporciona una máquina al pentester para “jugar” con el reto, aunque también podría darse acceso a su máquina a la red o conjunto de redes. Los escenarios pueden ser lo grandes que se quieran, ya que los diseñamos e implementamos nosotros.

En una formación como el RootedLab de Hacking Ético, cada escenario (y se hacen varios) propone un conjunto de conceptos a estudiar que son técnicas de hacking orientadas a pentesting. Por ejemplo, imaginemos que queremos enseñar pentesting a través de varios escenarios, una de las posibilidades sería:
  • Enseñar primero qué es la fase de reconocimiento, de enumeración, de escaneos. Usar herramientas en varios ejemplos y retar al alumno a llevar a cabo la práctica a través de un escenario dónde se le propone un reto.
  • Se le está retando, es decir, puedes utilizar cualquier herramienta que te permita lograr el objetivo marcado.
  • El objetivo marcado será una flag o una característica que tengas que lograr.
Bien, después se puede montar otro escenario dónde se tenga que identificar diferentes tipos de vulnerabilidades que pueden ir desde una versión de software obsoleta, una mala configuración de un servicio, un proceso de fuerza bruta, una vulnerabilidad web, etcétera. 

Como se puede ver, se hace foco en lo que se pretende enseñar. Se enseña, pero después, vamos a proponer el reto al alumno para que él lo luche. De esta forma el alumno experimentará lo que es el aprendizaje basado en el reto: un camino en el que fallará mucho, pero acabará conociendo muchas cosas y logrará su éxito.

Figura 7: Reto e1

Ciertamente, se puede montar de todo en un entorno con Docker, haciendo un paralelismo con el mundo real. Además, se pueden incluir máquinas virtuales dándoles acceso a algunas de las redes de los escenarios que se quieran montar, por lo que la personalización de los entrenamientos es infinita.

Otros entornos basados en Docker y máquinas virtuales

Hay repositorios en Github, como el de VulHub, que proporcionan imágenes de Docker personalizadas para probar ciertos entornos vulnerables. Es un repositorio muy interesante de cara a poder aprender sobre una vulnerabilidad concreta.


También tenemos a Vulnhub que proporciona máquinas virtuales con vulnerabilidades y son retos interesantes de trabajar. 

Figura 9: Writeup de retos de VulHub

Se pueden encontrar writeup por Internet sobre ellos, los cuales son formas también de aprender cómo otros han resuelto retos.

Recapitulamos sobre el RootedLab

Antes de finalizar el artículo sobre cómo ha evolucionado la enseñanza del Hacking Ético en una formación al uso de entornos o escenarios prácticos que dispongan de realidad y los alumnos puedan usar técnicas reales sobre ellos, vamos a mostrar algunos aspectos sobre el RootedLab de Hacking Ético del día 5 de marzo. El taller se divide en varias partes:
  • Parte I: Se enseñan diferentes técnicas de enumeración de máquinas y redes: En esta primera parte del lab, se resuelven escenarios de enumeración y se muestra el uso de técnicas y herramientas sobre ellos.
  • Parte II: Identificación de vulnerabilidades y explotación de éstas: El alumno recorrerá diferentes escenarios viendo cómo se detectan vulnerabilidades y cómo éstas se pueden explotar (con diferentes herramientas y con técnicas manuales). Esta parte cubre un amplio abanico que puede ir desde la generación de un exploit propio hasta el uso de herramientas automáticas. Todo ello sobre un escenario.
  • Parte III: Post-explotación: En esta parte se tratarán técnicas de escalada de privilegios, pivoting, técnicas de movimiento lateral, extracción de credenciales, etcétera. Todo a través del uso de escenarios reales (a los que un pentester se puede enfrentar en su día a día).
Los escenarios pueden contener diferentes máquinas (GNU/Linux), por lo que el enfoque es más global y real. Se estudiarán escenarios con vulnerabilidades en diferentes entornos, se utilizarán técnicas de post-explotación para poder elevar privilegio o pasar a otra máquina. El objetivo es claro: ¡Conseguir la flag! Por último, dejaremos la agenda con los conceptos que se impartirán:
  • MakeLab: Escenarios de entrenamiento preparados
    • Metodología de Pentesting
    • Mochila del pentester
    • ¿Qué debo tener a mano en un Red Team?
    • ¿Qué debo tener a mano en un pentest?
    • Distros & Tools
  • Fase 1: Enumeración y reconocimiento
    • Escenario: Enumeración
    • Técnicas de enumeración
    • Herramientas
    • Información relevante
    • Existencia de vectores de ataque
    • Escenario propuesto
  • Fase 2: Identificación de vulnerabilidades y explotación
    • Escenario: Identificación y explotación
    • Técnicas para identificar vulnerabilidades
    • Técnicas de explotación vulnerabilidades
    • Bind. Reverse
    • Herramientas
    • Escenario propuesto
  • Fase 3: Post-Explotación
    • Escenario: Post-Explotación
    • Recopilación de información
    • Escalada de privilegios
    • Pivoting
    • Herramientas
    • Escenario propuesto
  • Resolución escenario final
Antes de acabar, añadir que en todo entorno de formación y aprendizaje basado en reto debemos disponer de un dashboard dónde el alumno debe ir validando sus hitos. Contamos con un dashboard para insertar las flags de las máquinas que se van consiguiendo.

Figura 10: El Dashboard para las flags de los retos

Además, estaremos en el evento con charlas sobre Web3 y sobre Inteligencia Artificial. Puedes ver más información en la web del evento. Nos vemos en RootedCON 2024, donde además estará 0xWord con todos nuestros textos de hacking & ciberseguridad y estaré firmando libros. 
Además, con la compra de tu entrada de RootedCON 2024 conseguirás 100 Tempos de MyPublicInbox gratis. Basta con que entres en tu cuenta de MyPublicInbox con el mismo correo electrónico que te registraste en RootedCON 2024 y tendrás tus 100 Tempos una entrada gratuita de OpenExpo Europe 2024: que tendrá lugar en Madrid el 13 de Junio de este año. Y recuerda que con tus Tempos, podrás conseguir los códigos descuentos, y pagar parcial o completamente tus libros de 0xWord, y recogerlos en RootedCON 2024, o hacerlo allí mismo en el momento.
 
Saludos,

Autor: Pablo González Pérezescritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Contactar con Pablo González

jueves, octubre 13, 2022

Testing, Solid, Refactor y Docker: el cuarteto del éxito para la calidad en tus proyectos de desarrollo de software @geeks_academy #HackYourCareer

Es muy común que al adentrarse en el mundo de la programación se tenga la idea simplificada de que simplemente consiste en picar código, y que una vez funcione, ¡listo! Eso está bien al inicio de tu carrera como developer, de hecho, es el primer paso. Pero si quieres llevar tus desarrollos al siguiente nivel (y por supuesto, tu carrera como profesional IT) es indispensable que conozcas e incluyas en tu día a día el concepto de QA Testing.


Un día normal como otro cualquiera te comentan “tienes que añadir una funcionalidad nueva al proyecto,…” parece fácil. Pero cuando abres el fichero y ves más de 1.000 líneas de código, trozos comentados, líneas infinitas… Conclusión: ¡un horror! El código legado forma parte de nuestro día a día, así que debes enfrentarte a él, mejorarlo y que la próxima vez sea todo mucho más sencillo. Un perfil senior no solo escribe código sino que, además, incorpora en su día a día rutinas, trucos y actitudes que le permiten ser más productivo, más creativo y un profesional aún mejor.

¿Qué es QA testing?

QA testing hace referencia al proceso por el cual se asegura la calidad en un proyecto de software. Y es que una aplicación puede ser funcional, pero puede no ser todo lo funcional que podría ser. QA Testing, o calidad del software, pretende generar código reutilizable, más breve, filtrado, limpio y sobre todo que permita la escalabilidad del proyecto en cuestión sin cambiar sus funcionalidades.

¿Y qué prácticas llevar a cabo para ello? Hablemos sobre el cuarteto del éxito: Testing, Solid, Refactoring y Docker serán tus aliados para subir un escalón más como programador o programadora en el sector IT.

Testing, Solid, Refactoring y Docker

Testear, testear y testear.

Para añadir fiabilidad a tus desarrollos es indispensable que pongas en marcha el testing de software. Se trata de un proceso que verifica y valida la funcionalidad de una aplicación con el objetivo de garantizar que esté libre de defectos y coincida con los requisitos esperados para entregar un proyecto de calidad.

Existen dos tipos de testing principales: las pruebas funcionales y las no funcionales. Además puedes llevar a cabo la llamada prueba de mantenimiento.
  • Pruebas funcionales: Verifican cada función de una aplicación o software, su funcionalidad con un conjunto específico de requisitos.
  • Pruebas no funcionales o pruebas de rendimiento: Consideran parámetros como la confiabilidad, la usabilidad y el rendimiento.
Dentro de estas categorías existen múltiples técnicas de testing de software que harán que de tu código un desarrollo más profesional, y sobre todo, fiable.

Aplica los principios Solid

SOLID es un acrónimo introducido por Robert C. Martin a comienzos de la década del 2000. Estos principios vieron la luz por primera vez en el libro Agile Software Development, Principles, Patterns and Practices, y entre otras cosas, en el enuncia los famosos Principios SOLID. La metodología SOLID forma parte de los fundamentos de la arquitectura y desarrollo de software y está formado por 5 principios:

S – Single Responsibility Principle (SRP)
O – Open/Closed Principle (OCP)
L – Liskov Substitution Principle (LSP)
I – Interface Segregation Principle (ISP)
D – Dependency Inversion Principle (DIP)

Otorgan legibilidad y extensibilidad en los desarrollos y permiten eliminar código legado provocando que el programador tenga que refactorizar el código fuente. Los principios SOLID son recomendaciones que conviene aplicar para mejorar la cohesión y mantenibilidad de nuestros sistemas. Estos principios implican un nivel de complejidad y abstracción, así que está en tu mano decidir cuándo aplicarlos, ¡pero debes hacerlo!

Refactoring

El término "factoring" se ha utilizado en la comunidad de Forth desde al menos principios de los años ochenta. El capítulo seis del libro de Leo Brodie Thinking Forth (1984) está dedicado al tema. El primer uso conocido del término "refactorización" fue en un artículo de septiembre de 1990 de William Opdyke y Ralph Johnson. El libro de Martin Fowler Refactorización: Mejorando el diseño del código es la mejor referencia sobre el tema.

¿Qué es el proceso de refactorización?

Es un proceso sistemático donde mejoramos nuestro código sin modificar el comportamiento. Este conjunto de pequeñas técnicas independientes, nos ayudan a mejorar el código que ya existe:
  • Diseño más simple.
  • Más fácil de leer.
  • Más fácil de comprender.
Este es un proceso que se tiene que hacer muy poco a poco, esta práctica es muy conveniente realizarla con ayuda de test y si es posible utilizando el ciclo de vida de TDD. Es muy importante este punto, ya que tenemos que saber, si con nuestros refactors, no hemos roto nada del funcionamiento del código. Existen varias técnicas de refactoring, estas son las más útiles y utilizadas.
  • COMPOSING METHODS
  • MOVING FEATURES BETWEEN OBJECTS
  • ORGANIZING DATA
  • SIMPLIFYING CONDITIONAL EXPRESSIONS
  • MAKING METHOD CALLS SIMPLER
  • DEALING WITH GENERALIZATION
  • BIG REFACTORINGS
Para que entiendas mejor en qué consiste la práctica de refactoring, veamos qué NO es:
  • Solventar un error (bug) en nuestro código: el código ya debe estar funcionando correctamente.
  • Mejorar el rendimiento del programa: no persigue el rendimiento del sistema, sino el rendimiento como programador a la hora de trabajar con su código. Incluso al equipo, ya que la programación es una tarea conjunta en la mayoría de los casos.
  • No es añadir nuevas características: no hay que modificar el comportamiento del sistema ya que el usuario no debería darse cuenta de cambios internos que se hayan realizado.
Tenemos que pensar que gran parte del trabajo delante de código es leer y releer las mismas líneas. Por esta razón tenemos que hacer que este código no nos cueste de entender y sea fácil de mantener. El refactoring nos puede aportar la solución.

Docker

Docker es una plataforma de virtualización a nivel de sistema operativo que permite crear una aplicación y empaquetarla junto con sus dependencias y librerías en un contenedor que será capaz de ejecutarse en cualquier otra máquina. Fue desarrollado en 2013 y está escrito en Go. Actualmente Docker es una estándar en el desarrollo aplicaciones y es el corazón de la metodología DevOps y DevSecOps (SecDevOps).

Rafael Troncoso en 0xWord que puedes conseguir con oferta especial

Básicamente facilita a un equipo poder tener las mismas herramientas, homogeneidad de las tecnologías, versiones, etc. ¿Por qué elegir Docker?
  1. Nos olvidaremos del sistema operativo y las configuraciones manuales
  2. Nos olvidamos de "En mi máquina funciona..."
  3. Mucho más ligero y escalable que una máquina virtual.
  4. Trabajar en equipos de desarrollo.
  5. Concebido para trabajar en la nube. Para realizar los despliegues de una manera segura.
  6. La idea es emular durante el desarrollo lo máximo posible nuestro entorno de producción.
En conclusión…

Para ser un buen programador no basta con crear solo código que funcione, sino que es necesario hacer de este un código de calidad facilitando su legibilidad y escalabilidad para alcanzar un mayor grado de abstracción. No importa que seas un desarrollador solitario, formes parte de un gran equipo técnico o un consultor que trabaja con muchos clientes a la vez. Todas estas herramientas te ayudarán a aumentar la calidad de tu software y harán de ti un mejor profesional del desarrollo.

Figura 4: Módulos de contenido del BootCamp Online de QA Testing

En el Bootcamp Online QA Testing de GeeksHubs Academy se combina Testing, DevOps con Docker, Metodología SOLID y prácticas de Refactoring. Te permite formarte 100% online a tu ritmo recibiendo el apoyo de un tutor especialista, como Victor Bolinches o José Marín que te orientarán para que puedas seguir avanzando con la formación, además de tener Tempos de MyPublicInbox para contactar con cualquier profesional de la plataforma.


Si te interesa ampliar tus conocimientos, con el Código COMUNIDADGEEK20 podrás reservar tu plaza con un 20% de descuento. Pide más información al equipo de GeeksHubs Academy aquí.

Hack Your Career!

Autor: Chaume Sánchez, CEO de GeeksHubs



Entrada destacada

Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment. Nuestro nuevo libro en 0xWord

Pocas veces me ha hecho tanta ilusión que saliera un nuevo libro en 0xWord como con este libro de " Hacking IA: Jailbreak, Prompt Inje...

Entradas populares