Co myślę o: Docker

Docker to zarządca kontenerów. Działa w oparciu o LXC (Linux Containers) oraz jest wspomagany przez szereg innych bibliotek i aplikacji. Chcesz tego używać na produkcji? Dla swoich Klientów? Przemyśl 2 razy czy aby na pewno to wygodne rozwiązanie jest dokładnie tym czego potrzebujesz.

Kontener nie jest tak bezpieczny jak np.: maszyny wirtualne VMware.

Przykład:

Kontener:
proces w VPS <-> kernel host’a

Maszyna wirtualna:
proces w VPS <-> kernel VPS <-> zarządca wirtualizacji <-> kernel host’a.

Więc jeśli chcesz uruchamiać różne (obce) usługi w takich VPS, to z punktu widzenia bezpieczeństwa o wiele lepszym rozwiązaniem jest zastosowanie maszyny wirtualnej. Zyskujemy 2 dodatkowe poziomy izolacji w stosunku do kontenera w którym każdy proces w VPS gada z kernel’em host’a. Docker to JEST fajny pomysł, rzeczywiście ułatwia deploy aplikacji w różnych środowiskach.. ale to NIE jest rozwiązanie, które zastosowałbym produkcyjnie; nie dałbym publicznie dostępnego Dockera do deployu softu dla nie wiadomo kogo.

Z tego co już się rozeznałem w kwestii Dockera i całego tego szumu wokół niego, to można się wspomóc używając SELinux’a do oznaczania procesów i plików wewnątrz kontenera, Namespace’ów do separacji procesów (mapowanie id procesów; proces w kontenerze ma id=0, poza kontenerem ma np. id=3000), cgroup, Apparmor’a, ograniczania capabilities, libseccomp.. ale to nadal będzie (niezaufany!) proces w VPS, który gada z jądrem gospodarza.

Czemu tak to powtarzam? Bo atak na kernel przeprowadzamy odwołując się do syscalls (jak sys_mlock czy sys_signal). Dla 64-bitowych kompilacji jest ich obecnie ponad 600. Sporo. Dziura w kernel’u może zezwolić na nieautoryzowane działania, mające wpływ na sam kontener lub całą ich resztę działających na tym hoście.