Co myślę o: Docker

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.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.