LXC, Docker & Stuff

Indagando sobre la composición de los contenedores en general

Transcript

1. LXC, Docker & Stuff Luis M. Ibarra @clvx
2. ¿Qué es un contenedor? Virtualización por sistema operativo donde un proceso obtiene sus propios recursos globales del sistema de manera aislada sobre un mismo kernel. Ventaja: Menor uso de recursos que la virtualización convencional
3. Tipos de Contenedores System container: • Root tree – lectura y escritura. • Networking: NAT, veth, macvlan, phys, etc. • Muchos procesos por contenedor. • Tienden a persistir como una máquina virtual completa. • LXC/LXD, OpenVZ. Application container: • Root tree – solo lectura (teóricamente). • Networking – NAT solamente(hasta ahora). • 1 proceso por contenedor. • “Efímeros”. • Docker, Rocket.
4. Componentes de un Contenedor • Namespaces • Cgroups • Linux capabilities • LSM(AppArmor/SELinux) • Seccomp • Networking
5. Namespaces: Mount • Aplicado pasando el flag CLONE_NEWNS en la llamada clone() o unshare(). • Cada proceso en diferentes espacios de nombres de montaje, tienen una vista particular del sistema de archivo • La vista del sistema de archivos del proceso es idéntica a la del proceso padre en el momento de la creación; sin embargo, cualquier modificación posterior en el montaje no se propaga al proceso padre y viceversa. • Se puede variar la visibilidad utilizando los operadores de mount: bind, make-shared, make-slave, make-private, make- unbindable
6. Namespaces: PID • Aplicado pasando el flag CLONE_NEWPID en la llamada clone() o unshare(). • Permite que procesos en diferentes espacios de nombre PID pueden tener un número de identificador de proceso(PID) diferentes para cada espacio de nombre. • Utilizado para implementar contenedores que puedan ser migrados a otros hosts manteniendo el mismo PID.
7. Namespaces: PID • El espacio de nombre PID es jerárquico. Cuando un nuevo espacio de nombre PID es creado, los procesos en ese espacio de nombre son visibles por el espacio de nombre PID del proceso que creo el nuevo espacio de nombre PID. Los procesos del espacio de nombre PID creado no tienen visibilidad del espacio de nombre PID del padre. La existencia de una jerarquía de espacios de nombre significa que cada proceso puede tener multiples PID's, uno para cada espacio de nombre en el cual es visible.
8. Namespaces: UTS • Aplicado pasando el flag CLONE_NEWUTS en la llamada clone() o unshare(). • 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. • Nodename se utiliza para inicializar ciertos servicios de red que necesitan el nombre de la máquina.
9. Namespaces: Network • Aplicado pasando el flag CLONE_NEWNET en la llamada clone() o unshare(). • 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, • Es posible utilizar puentes para crear túneles por medio de interfaces virtuales entre espacios de nombre de red
10. Namespaces: Network • Tipos de red: – VETH – LXC – MACVLAN – LXC – VLAN – LXC – PHYS – LXC – EMPTY – LXC – NAT – LXC/Docker/Rocket Mayor info: http://containerops.org/2013/11/19/lxc-networking/
11. 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. • Aplicado por: – Proceso. – Archivo.
12. Namespaces: User • Aplicado pasando el flag CLONE_NEWUSER en la llamada clone() o unshare(). • 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.
13. Namespaces: User Cuando se crea un espacio de nombre de usuario utilizando llamadas a clone() o unshare() se brinda un nuevo conjunto de capacidades con todos los bits habilitados en el mapa de bits para el nuevo proceso en el nuevo espacio de nombre de usuario, el nuevo proceso es propietario del nuevo espacio de nombre de usuario; sin embargo, se eliminan todo el conjunto de capacidades del nuevo proceso en el espacio de nombre del proceso padre. Además, cualquier llamada a execve() desde el proceso hijo a un archivo ejecutable tendrá como resultado la pérdida de las capacidades ya que el nuevo espacio nombre de usuario se crea con los securebits deshabilitados
14. 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.
15. 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.
16. 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 3: 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().
17. Cgroups: Subsistemas • Cpuset • Blkio • Cpuacct • Devices • Freezer • Hugetlb • Memory • net_cls • net_prio • Cpu • perf_event
18. 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 sistem
19. LSM(AppArmor/SELinux) • 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. – Su politica por defecta es permitir.
20. 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: Filtrar llamadas al sistema utilizando un filtro de paquetes Berkey(BPF) donde se envía el número de la llamada de sistema y los argumentos de la llamada. Si el filtro permite la ejecución de las llamadas fork() o clone(), cualquier proceso hijo obtiene los filtros de su proceso padre.
21. Usos de Contenedores System containers: • “Reemplazo” de una máquina virtual. • Diferentes topologías de red(Quagga). • Crear DMZ's. • Balanceadores. • CI. Application containers: • Balanceador. • Testing. • Balanceadores. • CI.
22. Seguridad • Mientras que no brindes una consola pública de tu contenedor, eres libre de ponerlo en producción. De otra manera es posible: – ssh forwarding. – spam de correo. – minar bitcoins. – proxy/VPN tunneling. – Escalar privilegios(LXC/Docker se encuentra en fuerte desarrollo aún). • En el caso de docker, un solo bridge donde se conectan todos los contenedores. • Evita los puntos de montaje compartido entre el host y los contenedores. • Limita los accesos a través de apparmor, linux capabilities y seccomp. • Crea tus propias imágenes. EVITA UTILIZAR IMAGENES DE DOCKERHUB EN PRODUCCIÓN. • Utiliza contenedores sin privilegio(Para el siguiente meetup).
23. Bibliografía • man 7 namespaces • man 7 pid_namespaces • man 7 apparmor • man 7 capabilities • man lxc.container.conf • http://containerops.org/2013/11/19/lxc-networki ng/ • https://access.redhat.com/documentation/en- US/Red_Hat_Enterprise_Linux/6/html/Resource _Management_Guide/ch01.html