LXD Internals

Diapositivas de LXD Internals del UbuCon LA 2015.

1. LXD Internals Luis M. Ibarra @clvx http://ubicando.pe
2. LXD • Contenedor de sistema. • Muchos procesos por contenedor. • Evolución de LXC-TOOLS. • Contenedores en modo no privilegiado por defecto. • La configuración se almacena en sqlite3. • Tienden a persistir como una máquina virtual completa.
3. Componentes Inicia la comunicación con el server LXD Escrito en GO LXD Cliente Server API REST Gestor de imágenes Migración Autenticación Kernel >= 3.12 Escrito en GO Utiliza liblxd
4. Archivos Importantes • ~/.config/lxc/ • Mantiene los certificados y configuración del cliente LXD. • /var/lib/lxd • devlxd/sock, api rest socket de comunicación con los contenedores. • images/, mantiene las imágenes que gestiona el servidor. • lxc/, mantiene el rootfs de los contenedores. • lxd.db, base de datos sqlite con las configuraciones. • unix.socket, api rest socket. • server.crt, server.key; certificados del server. • /var/log/lxd/ • Logs por contenedor.
5. Contenedor LXD • Compuesto de un: • Rootfs. • Archivo de configuración: • Configura los recursos, dispositivos, seguridad, etc. • JSON, basado en clave/valor. • Perfiles para agrupar varios contenedores por un tipo de configuración. • Los perfiles se pueden encadenar. • El último parámetro definido en un perfil es el que tiene validez.
6. Instalación • sudo add-apt-repository ppa:ubuntu-lxc/lxd-git-master && sudo apt-get update • sudo apt-get install lxd • Sugiero instalarlo en vivid(15.04).
7. Comandos
8. Componentes de un Contenedor • Namespaces • Cgroups • Linux capabilities • LSM(AppArmor/SELinux) • Seccomp • Networking
9. Namespaces: Mount • Es el conjunto de montajes del sistema de archivos que son visibles por un proceso. • La vista los montajes de un namespace difiere de los otros namespace. • Aplicado pasando el flag CLONE_NEWNS en la llamada clone() o unshare().
10. Namespaces: PID • Permite que procesos en diferentes PID namespaces pueden tener un número de identificador de proceso(PID) diferentes para cada namespace. • Utilizado para implementar contenedores que puedan ser migrados a otros hosts manteniendo el mismo PID. • Aplicado pasando el flag CLONE_NEWPID en la llamada clone() o unshare(). • El espacio de nombre PID es jerárquico.
11. Namespaces: UTS • Cada proceso en cada espacio de nombre tenga su propio identificador nodename, y domainname. • Los valores de la arquitectura, kernel, y otros no se modifican. • Aplicado pasando el flag CLONE_NEWUTS en la llamada clone() o unshare().
12. Namespaces: Network • Cada espacio de nombre de red tiene su propia tabla de enrutamiento, pilas IPv4 e IPv6, firewalls, archivos de dispositivos de red, directorio /proc/net, directorio /sys/class/net, sockets de red. • Un dispositivo de red física puede existir solo en un espacio de nombre de red. • Aplicado pasando el flag CLONE_NEWNET en la llamada clone() o unshare().
13. Namespaces: Network Tipos de red: • VETH. • MACVLAN. • VLAN. • PHYS. • EMPTY. Mayor info: http://containerops.org/2013/11/19/lxc-networking/
14. Linux Capabilities • Las capacidades son un conjunto de bitmaps utilizados por un proceso para probar si tiene permitido realizar una operación privilegiada sobre los recursos del sistema operativo. • Aplicados a procesos creados con execve() o a archivos ejecutables solamente. • /proc/PID/status, para verificar las capacidades de un proceso. • Aplicado por: • Proceso. • Archivo.
15. Linux Capabilities P'(permitido) = (P(heredable) & F(heredable)) |F(permitido) P'(efectivo) = F(efectivo) ? P'(permitido) : 0 P'(heredable) = P(heredable).
16. Namespaces: User • Permiten mapear UID y GID entre espacios de nombres. • Aíslan identificadores y atributos relacionados con seguridad; en particular, UID's y GID's, el directorio root, llaves del kernel y las capacidades. • Aplicado pasando el flag CLONE_NEWUSER en la llamada clone() o unshare().
17. Cgroups • Cgroup: Asocia un conjunto de tareas con un conjunto de parámetros para uno o más subsistemas. • Subsistema: Representa un recurso del sistema al cual se le aplican límites a través de los cgroups. • Jerarquía de cgroups: Conjunto de cgroups organizados en un árbol de directorios donde cada tarea pertenece a exactamente a un cgroup para un subsitema definido.
18. Regla 1: Una jerarquía puede tener más de un subsistema. Regla 2: Cualquier subsistema no puede ser adjuntado a una o varias jerarquías que ya tengan otro subsistema adjuntado.
19. Regla 3: Para cada cgroup que se crea, una tarea solo puede ser miembro de exactamente un solo cgroup en esa jerarquía, pero puede pertenecer a muchos cgroups en diferentes jerarquías. Regla 4: Cualquier proceso hijo automáticamente hereda el cgroup del proceso padre; no obstante, puede ser movido a cualquier otro cgroup, ya que el proceso hijo es totalmente independiente del proceso padre luego de la llamada a fork().
20. Cgroups: Subsistemas • Cpuset • Blkio • Cpuacct • Devices • Freezer • Hugetlb • Memory • net_cls • net_prio • Cpu • perf_event
21. LSM(AppArmor/SELinux) • Limita las capacidades de los usuarios incluyendo al usuario root en realizar operaciones que puedan afectar al host. • Sin LSM, la política de seguridad a ejecutar por defecto son las capacidades de Linux. • AppArmor: • Confina programas a un conjunto limitado de recursos a través de perfiles que son cargados al kernel para realizar un control a nivel de programas sobre usuarios • Los perfiles son aplicados a los procesos en la llamada de sistema exec(), incluso a los procesos root. • No se puede confinar para procesos que ya están corriendo en el sistema.
22. Seccomp • Permite restringir llamadas al sistema de un proceso reduciendo la exposición de las interfaces del kernel. • 2 tipos de restricción: Estricta: solo se permiten las llamadas de sistema a read(), write(), exit(), sigreturn() de lo contrario resulta en la terminación del proceso. Filtro: Filtra llamadas al sistema enviando el número de la llamada de sistema y los argumentos de la llamada. Cualquier proceso hijo luego de clone() o fork() obtiene los filtros de su proceso padre.
23. Recomendaciones • En la configuración por defecto, un solo bridge donde se conectan todos los contenedores. • Múltiples asignaciones de UID/GID. • Evita que otros contenedores sean afectados si algún contenedor ocupa todos los descriptores de archivos. • Si se escapa del contenedor no afecta a los otros contenedores. • Evita los puntos de montaje compartido entre el host y los contenedores.
24. Recomendaciones • Limita los accesos a través de apparmor, linux capabilities y seccomp. • Crea tus propias imágenes. • Utiliza contenedores sin privilegio.
25. Bibliografía • man 7 namespaces • man 7 pid_namespaces • man 7 apparmor • man 7 capabilities • man lxc.container.conf • https://github.com/lxc/lxd#lxd- • https://insights.ubuntu.com/2015/04/28/getting-started-with-lxd-the-container-lightervisor/ • https://www.flockport.com/lxc-and-lxd-support-across-distributions/ • https://github.com/lxc/lxd/tree/master/specs • http://containerops.org/2013/11/19/lxc-networking/ • https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_G uide/ch01.html • http://www.opencloudblog.com/wp-content/uploads/2013/09/linuxswitch-veth.png