Dywagacje na temat bezpieczeństwa.txt

	Kontenery dockera są całkiem bezpieczne w swojej naturze, tym bardziej gdy uruchomi się je w trybie z ograniczonymi zabezpieczeniami. Już w domyślnej konfiguracji, przy zwykłym uruchomieniu „docker run” uprawnienia z jakimi uruchamia się kontener, czyli root różni się od standardowego root'a poprzez ograniczenie większości funkcji, z których raczej się nie korzysta w przypadku kontenera. Można to zmienić za pomocą dyrektywy „--privileged” w „docker run”, ale naraża nas to na wykorzystanie przez kontener luk w zabezpieczeniach i w konsekwencji częściowym lub całkowitym dostępem do roota w systemie hosta (w najgorszym przypadku). Np. poprzez nadpisanie runC binary (powinien z założenia być tylko do odczytu), przerobienie operacji cp do przenoszenia plików na systemie hosta itp. (https://www.cvedetails.com/vulnerability-list/vendor_id-13534/product_id-28125/Docker-Docker.html)
	Żeby jednak to miało miejsce często spełnione muszą być też dodatkowe warunki jak zainfekowany obraz kontenera albo taki, który wykorzystuje kolizję nazw by się podszyć pod kogoś kim nie jest. Ten z kolei problem można wyeliminować, dzięki funkcji dockera porównującej obrazy na podstawie wyników funkcji kryptograficznej, można również wykorzystać wbudowaną w docker funkcję do korzystania jedynie z podpisanych cyfrowo obrazów. Wówczas również należy podać root key, wg którego będziemy decydować o poprawności takiego podpisu.
	Dobrym pomysłem jest ograniczenie uprawnień kontenera do absolutnego minimum dla wykorzystywanych dla niego funkcji, na co pozwala sam docker poprzez możliwość nadawania i odbierania uprawnień dla roota kontenera. W ten sposób również możemy się uchronić przed niepożądanym wykorzystanie zasobów i wieloma rodzajami ataków, których jeszcze nie sklasyfikowano. Można też wykorzystać programy firm trzecich jak Apparmor, seccomp itd. a domyślnego roota kontenera uznać jako standardowego użytkownika (non uid-0 user).
	Jedynym miejscem, gdzie wykorzystanie prawdziwego roota jest potrzebne to procesy uruchamiające i zarządzające samego dockera. Nawet w tym przypadku istnieje coś takiego jak rootless mode, który, mimo utraty części funkcjonalności, ma tą zaletę, że obecność roota może być wyeliminowana ze wszystkich procesów dockera.
	Najbardziej problematyczne może się ukazać udostępnianie możliwości tworzenia kontenerów przez HTML. Szczególnie wówczas trzeba zadbać by zapobiec wstrzykiwania niepożądanych ustawień, a konkretniej o wykorzystaniu folderu współdzielonego z hostem (podobnie jak to jest w VM) i ustawieniu go np. na „/”. Sam docker nie ma z tym żadnych problemów; taki kontener będzie miał pełny dostęp do wszystkich plików hosta.
	Jak sobie z tymi problemami radzić? W skrócie: ograniczać uprawnienia (wbudowana funckja dockera lub programy firm trzecich, np. Apparmor), wykorzystywać obrazy kontenerów jedynie z zaufanych źródeł (wiele kompromitacji dockera polega na tym, że obraz przy buildowaniu wykonuje niepożądane operacje), ograniczanie zasobów do wykorzystania przez kontener dockera (funckja dockera, tzw. control groups), a na koniec - sprawdzanie co jakiś czas logów czy nie dzieje się coś dziwnego na co powinniśmy zareagować (takie trzymanie ręki na pulsie :) ).