Conceptos

Fundamentos de virtualización: hipervisores, contenedores y Kubernetes

#cloud#defense

La virtualización es el concepto de encapsular las capacidades de una máquina física en un entorno virtual llamado máquina virtual (VM). En términos prácticos, se crea una capa de…

Definición

La virtualización es el concepto de encapsular las capacidades de una máquina física en un entorno virtual llamado máquina virtual (VM). En términos prácticos, se crea una capa de abstracción sobre el hardware para presentar recursos lógicos (CPU/RAM/almacenamiento/red virtual) que se asignan a uno o más entornos.

En el RAW se presentan tres “familias” relacionadas:

  • Hipervisores (virtualización de VMs).
  • Contenedores (virtualización a nivel de sistema operativo/motor de contenedores).
  • Orquestación (p.ej., Kubernetes) para operar contenedores a escala.

Contexto

La virtualización aparece como respuesta a necesidades comunes (según RAW):

  • Reducir gastos: menos hardware físico para más cargas.
  • Escalabilidad: delegar recursos a instancias según demanda (muy ligado a prácticas DevOps).
  • Eficiencia: ajustar recursos hacia arriba/abajo según uso.

En seguridad, la virtualización también habilita:

  • Laboratorios reproducibles (investigación, pruebas atómicas, desarrollo).
  • Aislamiento (entornos separados para reducir impacto de fallos o malware, con límites claros).
  • Portabilidad (plantillas, snapshots, imágenes maestras para volver a un estado conocido).

Desarrollo (MIT-style)

1) Cómo “funciona” a alto nivel: capa de abstracción, host vs guest

El modelo mental base del RAW:

  • Un motor crea la capa de abstracción y asigna recursos.
  • Encima se instala un sistema operativo o aplicación.

Términos clave:

  • SO host: sistema operativo donde corre el motor (o el propio hipervisor, según tipo).
  • SO invitado (guest): sistema operativo dentro de la VM.

2) Hipervisores

Un hipervisor crea la capa de abstracción entre hardware y software y suele incluir componentes de gestión para crear/operar VMs.

Hipervisores tipo 1 (bare-metal)

Del RAW:

  • Capa de abstracción directamente sobre el hardware (sin un OS “común” por debajo).
  • Orientados a escala y a ejecutar muchas VMs.
  • Muy ligeros para dedicar recursos a las VMs.
  • Gestión frecuentemente vía portal remoto.

Ejemplos mencionados (RAW): VMware ESXi, Proxmox, vSphere, Xen, KVM.

Hipervisores tipo 2 (hosted)

Del RAW:

  • Son una aplicación sobre un OS preexistente.
  • Gestión típica mediante GUI.
  • Enfoque: usuarios finales/desarrolladores, no tanto “escala enterprise”.

Ejemplos mencionados (RAW): VMware Workstation/Fusion, VirtualBox, Parallels, QEMU.

3) Contenedores (por qué existen y qué cambian)

El RAW motiva contenedores por problemas de escalar cargas ligeras (microservicios) con muchas VMs “pesadas”.

Definición práctica (RAW):

  • Se parecen a las VMs (filesystem, parte de CPU/RAM, espacio de procesos), pero no están completamente aislados del OS host: comparten propiedades con el host.
  • Son ligeros, portátiles y robustos “porque no están completamente abstraídos”.

Implicación clave (seguridad/operación):

  • VM: aislamiento fuerte a nivel de hardware/hipervisor.
  • Contenedor: aislamiento depende del kernel/engine y de la configuración (namespaces/cgroups/capabilities, etc.). No es “la misma clase” de frontera de seguridad.

Definición ampliada (RAW):

  • La contenedorización empaqueta la aplicación y sus dependencias en un contenedor para ejecutarla de forma portátil y consistente.
  • Este aislamiento es de entorno (no necesariamente de seguridad); se apoya en características del kernel.

Cómo funciona a bajo nivel (RAW):

  • Los contenedores usan espacios de nombres (namespaces) del kernel para separar procesos/archivos/memoria.
  • Cada proceso tiene un PID y un namespace; solo “ve” procesos dentro de su namespace.
  • Si un contenedor comparte namespaces con el host o se configura de forma insegura, aumenta el riesgo de escape.

4) Docker (motor y plataforma de contenedores)

Del RAW:

  • Docker ejecuta imágenes como contenedores.
  • Una imagen suele partir de una imagen base (Alpine/Ubuntu).
  • Un Dockerfile define base y comandos para construir la imagen.
  • Docker Hub actúa como repositorio remoto de imágenes.
  • El Docker Engine es una API en el host que media el acceso a CPU/RAM/red/disco.
  • Permite conectar contenedores, importar/exportar imágenes y transferir archivos.
  • En el ecosistema Docker se usan archivos declarativos para construir/orquestar (p. ej., Compose en YAML).

Por qué Docker es popular (RAW, datos 04/2022):

  • 13 millones de desarrolladores usan Docker.
  • ~7 millones de aplicaciones listas en Docker.
  • ~13 mil millones de descargas mensuales (repositorio oficial). Fuente: DockerHub/Docker.com (04/2022).

Comandos base del RAW:

Terminal window
docker pull <user>/<image>
docker run <user>/<image>
docker ps

Ejemplo práctico (RAW): correr una app Flask y exponer puerto 5000:

Terminal window
docker run -p 5000:5000 -d cryillic/thm_example_app

Notas operativas:

  • -d desacopla el contenedor de la terminal (background).
  • -p host:container publica el puerto del contenedor hacia el host.

Beneficios clave (RAW):

  • Gratis y open source (con planes enterprise).
  • Compatible con Linux/macOS/Windows.
  • Eficiente y minimalista vs VMs (no OS completo por contenedor).
  • Facil de empezar (documentación amplia).
  • Portabilidad: imágenes se comparten y ejecutan igual.
  • Menor coste operativo en cloud frente a VMs.

Ejemplo de tamaño (RAW, Ubuntu):

  • Imagen mínima ~100 MB vs imagen de servidor ~1 GB.
  • docker image ls muestra tamaños reales de imágenes locales.

5) Kubernetes (K8s): orquestación

El RAW presenta Kubernetes como plataforma de orquestación que se integra con Docker y amplía capacidades para operar a escala.

Capacidades destacadas (RAW):

  • Escalamiento horizontal (añadir instancias/máquinas en vez de solo más CPU/RAM).
  • Extensibilidad del clúster.
  • Autocuración (reiniciar/reemplazar/reprogramar).
  • Implementaciones y reversiones automatizadas con control de estado.

Tooling mencionado (RAW): kubectl (cheatsheet oficial enlazado).

6) Arquitectura de Kubernetes (alto nivel)

Clúster = conjunto de nodos. Dos tipos:

  • Plano de control: gestiona el clúster.
  • Nodos de trabajo: ejecutan los pods.

Componentes del plano de control:

  • kube-apiserver: expone la API de Kubernetes (escalable).
  • etcd: almacén clave‑valor con el estado del clúster.
  • kube-scheduler: asigna pods a nodos según recursos.
  • kube-controller-manager: ejecuta controladores (nodos, despliegues, etc.).
  • cloud-controller-manager: integración con APIs de nube.

Componentes del nodo de trabajo:

  • kubelet: garantiza que los contenedores del pod se ejecuten.
  • kube-proxy: reglas de red y balanceo hacia pods.
  • runtime de contenedores: Docker, containerd, rkt, runC, etc.

7) Paisaje de Kubernetes (recursos comunes)

  • Namespaces: aislamiento lógico de recursos dentro del clúster.
  • Pods: unidad de ejecución (uno o varios contenedores + red/almacenamiento compartidos).
  • ReplicaSets: mantienen N pods idénticos disponibles.
  • Deployments: definen estado deseado (y gestionan ReplicaSets).
  • StatefulSets: para apps con estado; pods con IDs persistentes.
  • Services: IP estable y balanceo hacia pods (ClusterIP, NodePort, LoadBalancer, ExternalName).
  • Ingress: enrutamiento HTTP/HTTPS hacia servicios.

8) kubectl básico (operación diaria)

Comandos base:

  • kubectl get pods -A (listar pods en todos los namespaces).
  • kubectl apply -f file.yaml (aplicar manifiesto).
  • kubectl describe <recurso> (detalles).
  • kubectl logs <pod> / kubectl exec -it <pod> -- /bin/sh (diagnóstico).
  • kubectl port-forward service/<svc> 8090:8080 (exponer servicio local).
  • kubectl auth can-i ... (verificar permisos RBAC).

9) Seguridad y hardening en K8s (resumen)

Buenas prácticas clave (RAW):

  • Pods: evitar root, FS inmutable cuando sea posible, imágenes escaneadas, evitar contenedores privilegiados.
  • Red: segmentación, TLS entre componentes del plano de control, políticas “deny by default”.
  • AuthN/AuthZ: deshabilitar acceso anónimo; usar RBAC con mínimo privilegio.
  • Secrets: no almacenar en texto plano; cifrado en reposo y acceso mínimo.
  • Observabilidad: auditoría habilitada + monitoreo y alertas.
  • Mantenimiento: parches rápidos, escaneo periódico y eliminación de componentes obsoletos.

PSA/PSS:

  • PSS define niveles (privilegiado, baseline, restringido).
  • PSA aplica esas políticas en el API server.
  • PSP fue deprecado/removido en Kubernetes v1.25.

Ejemplos

Ejemplo 1 — Elección de hipervisor según caso de uso

  • Tipo 1: datacenter/infra, muchas VMs, foco en eficiencia/escala.
  • Tipo 2: workstation de un dev, labs locales, GUI y facilidad.

Ejemplo 2 — Lab reproducible con VMs y snapshots

Usar snapshots/plantillas para volver a un estado inicial tras:

  • una prueba fallida,
  • un fallo del sistema,
  • una investigación de malware que “rompe” el entorno.

Ejemplo 3 — Docker para desplegar una app de forma aislada

El RAW muestra un flujo típico: descargar/ejecutar una imagen y publicar un puerto para probar un servicio web (p.ej., Flask en 5000).

Pitfalls / Errores comunes

  • Asumir que contenedor = VM (el aislamiento depende del kernel y la configuración).
  • Compartir namespaces/privilegios de forma insegura y facilitar escape de contenedor.
  • Construir imágenes “infladas” con paquetes innecesarios (más superficie de ataque).
  • Tratar dependencias del contenedor como si no requirieran parcheo.
  • Sprawl de VMs/containers: proliferación sin inventario/ownership (coste, riesgo y deuda operativa).
  • Snapshots como “backup”: útiles para rollback, pero no sustituyen un plan de backups/DR.
  • Exposición involuntaria: publicar puertos (-p) sin controles de red/ACL puede abrir servicios.
  • Orquestación sin gobernanza: Kubernetes sin límites claros (RBAC, namespaces, políticas) aumenta superficie de ataque.

Diagrama

De hardware a VMs/containers (vista simplificada)

flowchart TB
  HW[Hardware físico] --> H1[Hipervisor tipo 1]
  H1 --> VM1[VM + SO invitado + apps]
  H1 --> VM2[VM + SO invitado + apps]

  OS[SO host] --> H2[Hipervisor tipo 2]
  H2 --> VM3[VM + SO invitado + apps]

  OS --> CE[Motor de contenedores (Docker)]
  CE --> C1[Contenedor (app + libs)]
  CE --> C2[Contenedor (app + libs)]

Kubernetes como capa de orquestación (alto nivel)

flowchart TB
  K[Kubernetes / K8s] --> N1[Nodo Worker]
  K --> N2[Nodo Worker]
  N1 --> P1[Pod(s)/Contenedores]
  N2 --> P2[Pod(s)/Contenedores]

Referencias

  1. TryHackMe — Introducción a Docker: https://tryhackme.com/room/introtodockerk8pdqk
  2. Kubernetes — kubectl cheatsheet: https://kubernetes.io/docs/reference/kubectl/cheatsheet/
  3. Docker Docs: https://docs.docker.com/
  4. Docker Hub: https://dockerhub.com/
  5. Docker.com: https://www.docker.com/
  6. Kubernetes — Architecture: https://kubernetes.io/docs/concepts/architecture/
  7. Kubernetes — Pods: https://kubernetes.io/docs/concepts/workloads/pods/
  8. Kubernetes — Deployments: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
  9. Kubernetes — StatefulSets: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
  10. Kubernetes — Services: https://kubernetes.io/docs/concepts/services-networking/service/
  11. Kubernetes — Ingress: https://kubernetes.io/docs/concepts/services-networking/ingress/
  12. Kubernetes — RBAC: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
  13. Kubernetes — Pod Security Standards: https://kubernetes.io/docs/concepts/security/pod-security-standards/
  14. Kubernetes — Pod Security Admission: https://kubernetes.io/docs/concepts/security/pod-security-admission/
  15. Kubernetes — Secrets: https://kubernetes.io/docs/concepts/configuration/secret/
Título original en mis apuntes: Virtualization Fundamentals - Hypervisors, Containers, Kubernetes