Mostrando entradas con la etiqueta AWS. Mostrar todas las entradas
Mostrando entradas con la etiqueta AWS. 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

domingo, abril 13, 2025

Inteligencia Artificial y el negocio de resolver "Capthas Cognitivos" para el Cibercrimen.

Vale, no sólo cibercrimen, también lo hacen para aquellas empresas que hacen WebScrapping, WebScalping, o que directamente quieren indexar contenido... (¿cómo lo harán los spiders de los buscadores hoy en día?). En el mundo de la ciberseguridad también se usan las técnicas de WebScrapping muchas veces, para hacer investigaciones usando técnicas OSINT: Open Source INTelligence, así que el Captcha es un viejo conocido.

Figura 1: Inteligencia Artificial y el negocio de resolver
"Capthas Cognitivos" para el Cibercrimen.

Recientemente, el equipo de Sentinel Labs ha publicado un análisis de la infraestructura y el funcionamiento del Bot Akira, que es un framework que se utiliza para campañas de distribución masiva por medio de redes, spam e-mail, comentarios, y redes sociales, incluidos canales de Telegram. El análisis completo del bot lo tenéis en su web, pero hoy quería centrarme en el uso que hace la Inteligencia Artificial para su funcionamiento.
Si leéis el artículo del análisis veréis que el bot lleva hardcoeadas APIs Keys de OpenAI para hacer uso de las funciones de GPT para construir los mensajes de Spam, los comentarios, etcétera. Esto no es algo nuevo, y ya vimos varios artículos sobre cómo utiliza el cibercrimen las herramientas de GenAI, así como el mundo de la desinformación y la propaganda.
Pero quería pararme en la otra parte, en la parte de los Captchas, donde, para hacer sus funciones de forma masiva, distribuida, y automatizada, debe lidiar con la resolución de Captchas, y ahí utiliza varias plataformas para resolver esto. Estas son APIs comerciales de empresas que te permiten resolver de manera automatizada diferentes modelos de Captchas.

Figura 4: Tipos de Captcha Solver Ofrecidos por una empresa

Estas empresas tienen un negocio muy interesante, ya que si lo pueden automatizar lo automatizan, pero en sus orígenes hay empresas que lo hacían - y lo siguen haciendo para algunos Captchas - de manera manual, aunque ya menos. 

Figura 5: Precios para resolver diferentes versiones de reCaptcha

Si vamos a ver las empresas, vemos que utilizan, vemos que los costes son bastante bajos para Captchas sencillos que se pueden automatizar con modelos en IA en local, como son las diferentes versiones de ReCaptchaV2, ReCaptchaV2 Enterprise, ReCaptchaV3 y ReCaptchaMobile.
Hay que recordar que ReCaptchaV2 se puede resolver con Cognitive Services de reconocimiento de audio - como hicimos nosotros en el año 2017 -, o usando Cognitive Services de reconocimiento de imágenes, algo que está bastante automatizado como podéis ver en este vídeo, donde además resuelven también hCaptcha.

Figura 7: Resolviendo ReCaptcha & hCaptcha

También, según el informe, podía saltarse otros tipos de Captcha, como hCaptcha, visto en el vídeo anterior, pero también FunCaptcha, uno de los que desde que entramos en el mundo de los Multi-Modal LLMs he estado jugando con ellos. 

Figura 8: Doce Retos diferentes de FunCaptcha

FunCaptcha utiliza retos visuales cogntivios para detectar a los humanos, y aunque al principio eran complejos de automatizar, desde la llegada de MM-LLMs ha sido un juego. Yo he estado jugando con ellos, ya que los utilizan HBO Max, Linkedin, Twitter/X, etcétera, y os he ido dejando artículos para que pudierais ver cómo funcionan:
Resolver los FunCaptcha, cada día es más sencillo, ya que cada vez funcionan mejor los MM-LLMs. En este ejemplo con ChatGPT-4o se puede ver cómo a la primera resuelve el reto de los datos de la imagen anterior.

Figura 9: Resolución del FunCaptcha de los dados con ChatGPT

Pero si lo que queremos es automatizar esto, pues no queremos tanta floritura en la respuesta, que los tiempos de latencia son cruciales, así que le pedimos el número del cuadrante que hay que pulsar y listo. En este caso con el reto de la galaxia en espiral.

Figura 10: Resolución del FunCaptcha de la galaxia en espiral con ChatGPT

Al final son retos de reconocimiento visual, razonamiento, etcétera, que cada vez están más superados por esta industria. Sin embargo, se puede ver diferentes precios para este tipo de retos. Aquí, esta empresa está cobrando entre 2.99USD y 50 USD por resolver 1.000 FunCaptchas.

Figura 11: Coste de resolución de 1.000 FunCapchas

Esto puede significar que están pagando un API muy grande, o que lo están resolviendo manualmente aún, porque te puedes encontrar "empresas" como esta China que por entre 5  15 Yuanes te los resuelven igualmente. Eso puede ser que estén usando una infraestructura de botnet para resolverla, o incluso APIs robadas de servicios de GenAI, o... vete tú a saber, porque el precio es brutal. Es algo así como entre 0.7 y 2 USD.

Figura 12: Coste de resolución de 1.000 FunCaptcha.

Y la infraestructura que tienen soporta resoluciones de millones de Captchas Cognitivos al mes, como podemos ver en los planes comerciales para todo tipo de tamaño de compañía, donde por menos de 100 USD tienes un servicio de más de 6M de Captchas al mes, de imágenes o audios, para que lo puedas automatizar a lo grande. Y si necesitas más, pues doblas la cuentas.

Figura 13: Planes empresariales para resolución
de Captchas Cognitivos vía API

Además de estos Captchas Cognitivos, también tienen estas empresas soluciones para CloudFlare TurnSite y AWS Captcha. TurnSite es el famoso Captcha de CloudFlare que tanto bien ha hecho, pero estas empresas ya empiezan a ponerlo en sus capacidades, y AkiraBot hacía uso de una de estas empresas para saltárselo.

Figura 14: Planes con TurnSite y AWS Captcha

Es por eso que la empresa CloudFlare ha innovado y creado AI Labyrnth para cuando un sitio es atacado por uno de estos servicios, quede atrapado en un HoneyPot que le genere con GenAI información "useless" de lo que iba buscando.

Además, si os fijáis, el AWS Captcha, ya lo tienen en camino. De momento la oferta te permite reconocerlo, lo que te ayuda a reenviarlo a un equipo de personas humanas que lo resuelvan, pero "están trabajando" en tenerlo listo. Es la innovación en el otro lado.

Figura 16: Puzzles de AWS Captcha

Al final, la disrupción de la aceleración en el mundo de la Inteligencia Artificial se va a ver en todas partes, así que vemos como el juego del gato y el ratón entre buenos y malos - o malos y buenos -, sigue siendo una de las líneas de investigación más interesantes en Ciberseguridad.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


jueves, enero 02, 2025

Infra as Code vs. Platform Engineering: Una Mirada Técnica a la Tendencia Actual

En los últimos años, la gestión y automatización de infraestructuras tecnológicas ha experimentado un cambio significativo. Dos enfoques han surgido como protagonistas: el uso de herramientas de Infra as Code (IaC), y el movimiento hacia la ingeniería de plataformas (Platform Engineering) respaldado por soluciones como Axebow, de la que ya os habló nuestro compañero José Bernabéu-Auban en su artículo: "Platform Engineering as a Service: La encrucijada de la Nube y la ilusión del progreso."

Figura 1: Infra as Code vs. Platform Engineering.
Una Mirada Técnica a la Tendencia Actual

Este artículo explora ambas tendencias, haciendo especial énfasis en la complejidad y el nivel de conocimiento necesario para implementar IaC en entornos multicloud.

Infra as Code: Automatización Granular y Flexible

Infra as Code (IaC) ha sido una revolución para los equipos de DevOps y operaciones. Herramientas como Terraform, Ansible y Pulumi permiten definir y gestionar la infraestructura utilizando código, lo que garantiza consistencia, auditabilidad y capacidad de replicación. 
Sin embargo, trabajar con ib en entornos multicloud, como AWS, Google Cloud y Azure, agrega capas de complejidad que exigen un nivel avanzado de conocimiento técnico y organización.

Ventajas del Enfoque IaC

1. Granularidad y Control: Las herramientas IaC ofrecen control detallado sobre los recursos. Por ejemplo, con Terraform, se puede definir cada componente de una infraestructura cloud, desde redes hasta bases de datos.

2. Compatibilidad multicloud: Aunque IaC puede implementarse en entornos multicloud, utilizar distribuciones de Kubernetes nativas de los proveedores cloud tipo (EKS, GKE, AKS) puede limitar la portabilidad y la interoperabilidad entre plataformas, lo que puede generar dependencias que dificultan una verdadera estrategia multicloud. 
 
3. Madurez Tecnológica: Muchas herramientas IaC están bien documentadas y cuentan con una comunidad activa, lo que facilita su adopción.

Desafíos del Enfoque IaC

Complejidad en Entornos Multicloud: Gestionar IaC en una nube ya es complejo; al incorporar múltiples proveedores como AWS, Google Cloud y Azure, se deben manejar diferencias en APIs, servicios y configuraciones. Esto incrementa los riesgos de errores y la necesidad de conocimientos especializados para unificar estrategias.

• Curva de Aprendizaje Pronunciada: Configurar y mantener IaC en un entorno multicloud requiere habilidades avanzadas, lo que implica un costo significativo en términos de formación y tiempo. Los equipos deben dominar lenguajes de configuración, comprender arquitecturas de cada proveedor y desarrollar experiencia en integración. 
 
Esta curva de aprendizaje puede traducirse en retrasos en la implementación y mayores gastos operativos, ya que el tiempo necesario para alcanzar la plena competencia puede ser considerable. Además, los errores derivados de una capacitación insuficiente pueden aumentar los costos asociados al re-trabajo y a la resolución de problemas.

• Escalabilidad Limitada sin Buenas Prácticas: Sin una estrategia bien definida, las configuraciones de IaC pueden volverse inmanejables a medida que crecen las implementaciones.

• Fragmentación Operativa: La falta de estandarización entre nubes puede resultar en implementaciones inconsistentes y más difíciles de mantener.

Platform Engineering: Abstracción y Estandarización

La Ingeniería de Plataformas o Platform Engineering  se posiciona como un enfoque holístico para gestionar infraestructuras y herramientas de desarrollo. Soluciones conocidas como plataformas de ingeniería, entre las que se encuentra Axebow, buscan crear una capa unificada que abstraiga la complejidad técnica y proporcione a los equipos de desarrollo y operaciones una experiencia optimizada.


Beneficios del Enfoque de Platform Engineering


1. Abstracción de Complejidad: Estas plataformas permiten a los equipos trabajar en un entorno preconfigurado que automatiza las configuraciones comunes, reduciendo la necesidad de conocimientos especializados.


2. Control y Optimización de Costes: La ingeniería de plataformas facilita la supervisión y gestión eficiente de los recursos, permitiendo identificar y eliminar ineficiencias en el uso de la infraestructura. Esto es particularmente relevante en entornos multicloud, donde los costos pueden escalar rápidamente si no se controlan adecuadamente. Poder optimizar el coste es un factor fundamental.
3. Productividad Mejorada: Con una plataforma estandarizada, los desarrolladores pueden enfocarse en construir aplicaciones en lugar de preocuparse por los detalles de la infraestructura.
4. Escalabilidad Organizacional: La ingeniería de plataformas promueve la coherencia y facilita la escalabilidad al ofrecer una base uniforme para todas las aplicaciones.

5. Seguridad y Gobernanza: La centralización de la gestión reduce los riesgos de configuraciones inseguras o incoherentes.


Desafíos del Platform Engineering

• Costos Iniciales: Implementar este tipo de plataformas requiere una inversión significativa en tiempo y recursos.

• Menor Flexibilidad Inicial: Aunque la abstracción reduce la complejidad, también puede limitar la capacidad de personalización para casos excepcionales.

• Resistencia al Cambio: Los equipos acostumbrados a trabajar con IaC y scripting pueden ser reticentes a adoptar un enfoque centralizado.

Ambos enfoques tienen su lugar en las estrategias modernas de infraestructura. En muchas organizaciones, la convergencia entre ambas filosofías está generando híbridos donde IaC establece las bases de la infraestructura, mientras que la ingeniería de plataformas ofrece una experiencia optimizada para los desarrolladores.

Consideraciones Finales

La elección entre Infra as Code & Scripting vs. Platform Engineering no es excluyente. Las organizaciones deben evaluar sus necesidades específicas, madurez técnica y objetivos a largo plazo. Mientras que IaC es ideal para entornos donde se requiere un control fino y personalización, la ingeniería de plataformas sobresale en contextos donde la escalabilidad y la eficiencia del equipo son prioritarias.

Figura 8: Comparación y Convergencia

En última instancia, herramientas como Axebow representan una evolución hacia un enfoque más colaborativo y orientado a la experiencia del usuario, marcando el camino hacia el futuro de la automatización de infraestructuras. Si quieres probar un servicio líder como el de Axebow solo entra en nuestra web.

Un saludo,


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,

miércoles, febrero 07, 2024

Amazon Web Services (AWS): Hardening de Infraestructuras Cloud Computing en @0xWord

Comienza el año, y comienza al mismo tiempo la publicación de los nuevos títulos de este año, donde antes de RootedCON esperamos lanzar cuatro (4) nuevos títulos para que podáis hacer más grande vuestra biblioteca. Para que tengáis la colección completa. Y el primero de este año es "Amazon Web Services (AWS): Hardening de Infraestructuras Cloud Computing", escrito por Abraham Romero.
Ya lo tenéis ya disponible en la web de 0xWord, desde donde lo podéis comprar para tener lo antes posible 24-48 horas dependiendo de lo lejos que sea, en vuestras manos, y sobre una temática fundamental hoy en día, la fortificación de las infraestructuras en el Cloud de AWS.


El libro tiene 220 páginas, y cuenta en seis capítulos desde los principios iniciales de la suscripción que afectan a la seguridad, hasta los ataques que pueden significar grandes costes solo por un problema de seguridad, pasando por los temas más técnicos de fortificación de redes, fortificación de servicios, y fortificación de plataformas. El índice del libro completo os lo he subido a mi cuenta de SlideShare.

Como podéis ver, toca temas claves como el cifrado de datos, la seguridad de las cuentas privilegiadas de administración el despliegue y configuración de los servicios de firewalling de red y de aplicaciones, los controles de acceso, y la monitorización y gestión del alarmado de toda la plataforma cloud, algo fundamental hoy en día.


Figura 3: Índice del libro "Amazon Web Services (AWS):
 Hardening de Infraestructuras Cloud Computing"

El libro lo que lo ha escrito Abraham Romero Cid, es una especialización en seguridad para AWS, que es una de las plataformas de computación en la nube más utilizadas en todo el mundo a día de hoy. Ha revolucionado el mercado con la gran cantidad de servicios disponibles que ofrece, haciendo posible que las empresas y usuarios de todo el mundo puedan construir sus propias infraestructuras, productos y aplicaciones de forma rápida, sencilla y abaratando costes.

Este libro se ha escrito desde la perspectiva de una certificación de AWS para introducirse en el entorno cloud: AWS Certified Cloud Practitioner. Es por esto que el libro es el punto de partida ideal para aquellas personas que quieran adentrarse en esta tecnología, o pretendan afrontar dicho examen.
De esta forma, se cubrirán los conceptos más básicos y ventajas de la nube frente al modelo tradicional, su sistema de precios, se revisarán los principales servicios de AWS en términos de computación, redes, almacenamiento y bases de datos, y finalmente la seguridad en la nube, donde se analizarán los diferentes mecanismos de protección frente ataques, control de acceso, monitorización, conformidad etcétera.

Usar tus Tempos de MyPublicInbox 0xWord para adquirir este libro

Para terminar, te recuerdo que tendrás también 100 Tempos de MyPublicInbox por la compra de este libro de "Amazon Web Services (AWS): Hardening de Infraestructuras Cloud Computing" y que además, puedes pagar completa o parcialmente este libro con Tempos de MyPublicInbox. Aquí te explico cómo se hace.

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 5: 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 6: 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)  

Entrada destacada

+300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial

Hace un mes comencé a recuperar en un post mi interés en los últimos años, donde he publicado muchos artículos en este blog , y he dejado mu...

Entradas populares