Contenedores

Fuente: What even is a container: namespaces and cgroups

Fuente: Cgroups, namespaces, and beyond: what are containers made from?

Fuente: Twitter de Sergio López (@slpnix)

Como Docker ejecuta un contenedor

Un cliente (p.e. Docker CLI) llama al servicio Dockerd usando la API de Docker

Dockerd realiza la gestión de la API, orquestación y comunicaciones, delegando las funciones del ciclo de vida de contenedores a Containerd

Containerd realiza las funciones de gestión de volumenes, red, imágenes y ciclo de vida de los contenedores

Por último RunC ejecuta el contenedor

Fuente: Docker components explained

Como Kubernetes ejecuta un contenedor

Un cliente llama al servicio ApiServer usando la API de Kubernetes

Kubernetes decide sobre que nodo va a ejecutar el POD y llama al agente que se ejecuta en el mismo, el Kubelet

El Kubelet utiliza Container Runtime Interfaz para comunicarse con el gestor de ciclo de vida de los contenedores

Como Kubernetes ejecuta un contenedor y 2

Containerd Shim v2 es una capa de traducción entre CRI y Containerd, actualmente existe CRI-Containerd que soporta CRI directamente

Existen otras implementaciones compativles con CRI como CRI-O usada en Openshift

Por último RunC ejecuta el contenedor

Fuente: Containerd Plugin for Kubernetes Container Runtime Interface

Fuente: Open Container Initiative-based implementation of Kubernetes Container Runtime Interface

Estándares de contenedores a tener en cuenta para las MicroVMs

CRI (Container Runtime Interface): Un interfaz unificado de acceso de Kubelet a los "Container Runtime"

Fuente: Container Runtime Interface (CRI)

Fuente: High performance, open-source universal RPC framework

Fuente: Language-neutral, platform-neutral extensible mechanism for serializing structured data

Estándares de contenedores a tener en cuenta para las MicroVMs y 2

Fuente: Open Container Initiative

Fuente: Configuration, execution environment, and lifecycle of a container

Fuente: Image Format Specification

Máquinas Virtuales

¿Que es una máquina virtual?

En Informática, la virtualización es la creación a través de software de una versión virtual de algún recurso tecnológico

Un Hipervisor es un gestor y monitor de dichos recursos virtualizados

Una máquina virtual es un recurso virtualizado formado por un hardware virtual y un sistema operativo

Fuente: Virtualización

Rendimiento y Seguridad

¿Porque debemos usar contenedores?

El mercado tiende a usar contenedores por su menor tiempo en desplegarse al no necesitar la capa de aislamiento y SO de una MV

No requerire intervención de departamento de infraestructura, aunque dicho proceso se reduce con la introducción de herramientas de gestión de la configuración

No se requiere entrar en el SO para instalar

¿Porque debemos usar máquinas virtuales?

Un atacante malicioso puede utilizar una vulnerabilidad en runC o/y en el kernel para acceder a la información que existe en otros contenedores

Para grandes proveedores de servicio esto es un gran problema porque deben asegurar que la información de cualquier empresa este aislada del resto

Por ello necesitan sistemas que mejoren la seguridad por aislamiento

Modelo de amenazas STRIDE

Opciones para mejorar la seguridad de los contenedores

Existen básicamente dos propuestas para reducir el problema de seguridad de los contenedores

La primera se basa en reducir la superficie vulnerable de los contenedores.

Filtrando las llamadas al sistema que realizan los contenedores con soluciones como gVisor.

O aplicando modulos de seguridad del kernel de linux como SeLinux

Sin embargo vamos a hablar de una segunda opción: Aislamiento fuerte con MicroVMs

Fuente: OWASP Container Security Verification Standard

Fuente: How to stop worrying about Application Container Security

Soluciones MicroVMs OpenSource

Los UniKernels son Kernels especializados que disponen de las librerías mínimas para realizar la función para las que son creados

Existen Unikernels desde hace más de cinco años como MirageOs basado en Ocaml, Unik que pese a ser experimental tiene una importante actividad.

Si a dicho Unikernel que creamos le asignamos como función ejecutar los driver de virtualización, un agente para el hipervisor o gestor y la capacidadd de levantar un contenedor obtenemos una MicroVM

Las MicroVMs al ser especializadas y no de uso general pueden reducir los drivers y librerías para ajustarse al hipervisor donde van a ser ejecutados, reduciendo de manera importante su tamaño y los tiempos de despliegue

Fuente: Unikernels: The Rise of the Virtual Library Operating System

Fuente: MirageOS is a library operating system that constructs unikernels

Fuente: The Unikernel & MicroVM Compilation and Deployment Platform

Fuente: Unik Slides

Kata Containers viene de la unión de dos productos: Clear Containers de Intel e Hyper.sh

Actualmente Kata Containers es un proyecto dentro del paraguas de la OpenStack Foundation

Kata Containers es un "Container Runtime" compatible con OCI runtime specification por lo que puede trabajar con Docker o Kubernetes vía CRI con CRI-O o CRI-Containerd

Kata Containers crea una máquina virtual con QEMU/KVM por cada contenedor o pod

Para obtener mejores resultados desarrollan una versión de QEMU reducida llamada qemu-lite para tener una capa de hypervisor mínima ajustada al kernel

Fuente: Intel® Clear Containers: Now part of Kata Containers

Fuente: Kata Containers

Kata Containers pasa al hipervisor un kernel para iniciar la MV con los servicios mínimos para ejecutar un contenedor

El Hypervisor inicia un con una imagen de SO mínima usando el Kernel indicado

Systemd ejecuta kata-agent y este ejecutará una nuevo contexto donde ejecutar el comando

Para ello kata-agent hace uso de libcontainer (funciona como si fuese runC)

Kata Containers se integra en OpenStack dentro del marco OpenStack Zun Katacontainers para mostrar los contenedores como MVs de Openstack y aprovecharse de las capacidades de la plataforma como SDS (Software Defined Storage) y SDN (Software Defined Network) entro otras muchas

Fuente: Kata Containers Architecture

Fuente: A Go package for building hardware virtualized container runtimes

Fuente: Kata Containers guest OS building scripts

Firecracker es un proyecto de Amazon AWS recientemente liberado como software libre para la creación de entornos multitenant seguros de contenedores

Firecracker es un hipervisor mínimo que funciona sobre KVM (al estilo de qemu-lite) utilizado en las soluciones de AWS: Fargate (CaaS) y Lambda (FaaS)

Su modelos de dispositivos es incluso menor que la de qemu-lite y la imagen SO mínima utiliza vsock para la comunicación del firecracker-agent, para levantar los contenedores utiliza runC

Fuente: Firecracker

Fuente: virtio-vsock

vSphere Integrated Container es un compendio de múltiples componentes opensource bajo licencia Apache 2. Dichos componentes se integran en un único producto (vic-product)

Es un motor de contenedores compatible con docker (versiones cliente 1.13 y API 1.25), se integra directamente en los hipervisores vSphere creando los contenedores como máquinas virtuales

Esto le permite utilizar los recursos de almacenamiento (datastores, vSAN) y red (dVswitch, NSX) de la plataforma VMware

Fuente: vSphere Integrated Containers Engine

La solución integra un Registro de Contenedores (Harbor)

Una portal multitenant (Admiral)

Un conector para gestionar los VCH desde vCenter (vSphere plugin)

Unos terminadores que hablan docker (VCH) o unas máquinas virtuales (Photon OS) con docker preinstalado

Fuente: Harbor

Fuente:

Fuente: Admiral

Fuente: Photon OS