Docker – zrób to dobrze i bezpiecznie cz. 2

Dzisiaj kontynuujemy temat dobrych praktyk w zakresie konteneryzacji z użyciem oprogramowania Docker. Jeśli nie czytaliście jeszcze poprzednich części o samym Dockerze czy o praktykach, to na dole strony umieszczamy linki do artykułów na te tematy. 

Dobre praktyki – ciąg dalszy

Istnieje jeszcze wiele czynności, które można wykonać, aby podnieść jakość swoich obrazów, a także ich bezpieczeństwo. Jednym z nich może być unikanie uruchamiania aplikacji w Dockerfile z poziomu root’a. Domyślnie, jeśli piszemy coś w pliku Dockerfile, to wykonujemy wszystkie komendy z poziomu administratora. Jest to jak najbardziej pożądane w momencie w którym konfigurujemy obraz w tzw. “build time”. Często musimy doinstalować jakąś paczkę i wykonanie takiej komendy zwyczajnie wymaga uprawnień administratora. Jednak przed wykonaniem komendy CMD lub ENTRYPOINT w Dockerfile (czyli komend, które będą wykonywać się w runtime) dobrą praktyką jest zmiana użytkownika, na takiego z ograniczonymi uprawnieniami (principle of least privilege).  Niektóre obrazy takie jak np. node, dostarczają specjalnego użytkownika z odpowiednio ograniczonymi uprawnieniami.

Rysunek 1 – Dockerfile obrazu bazowego node w wersji 18, źródło: github, docker-node

Aby zmienić użytkownika, którego wykorzystujemy w Dockerfile należy użyć komendy ‘USER’.

Rysunek 2 – zmiana użytkownika w Dockerfile

Używaj narzędzia do skanowania obrazów pod kątem podatności – docker scout – mogliście spotkać podobne narzędzie pod nazwą docker scan. Jest ono jednak przestarzałe. Polecenie ‘scout’ służy do analizy obrazów pod kątem zbieranych w bazach podatności. Przykładem może być baza ‘Common Vulnerabilities and Exposures’, dzięki której analizując dany obraz będziemy mogli zweryfikować jak poważne są podatności w naszym obrazie i czy stanowią one bezpośrednie zagrożenie dla danych, które przetwarzamy w ramach naszej aplikacji.

Rysunek 3 – Skan podaności z użyciem komendy docker scout cves

Takie skanowanie może być także częścią procesu DevOps (polecamy nasz poprzedni artykuł w tym temacie). Istnieje wiele zewnętrznych skanerów takich jak Trivy, które mogą stać się częścią procesu CI/CD i dzięki temu zwiększyć bezpieczeństwo naszego kodu. Warto także wspomnieć, że skorzystanie z niebezpiecznej wersji obrazu może wpływać także na bezpieczeństwo hosta i innych kontenerów (np. exploit dirtycow).

Inną cenną poradą, którą warto wziąć pod uwagę budując własne obrazy jest to, aby używać userns-remap. Jest to funkcjonalność polegająca na remapowaniu parametrów UID oraz GUID z hosta do kontenera. Jeśli musimy wystartować daną aplikację jako root i ma ona podmontowany wolumen z hosta (bind-mount), to domyślnie UID root’a z komputera hosta mapowany jest na ten sam UID z kontenera. Może to w pewnych przypadkach prowadzić do niebezpiecznych sytuacji. Jeśli dany użytkownik jest w stanie uruchomić kontener na hoście i zamontować do kontenera plik do którego nie ma dostępu, to brak remapowania może sprawić, że będzie miał dostęp do tego pliku mimo braku uprawnień na hoście (root hoście będzie równy temu w kontenerze, ze względu na UID). Istnieje jednak prosty sposób aby temu zaradzić. Należy edytować plik daemon.json w następujący sposób:

{

  „userns-remap”: „default”

}

a następnie zresetować daemona Dockerowego. Polecamy w tym temacie artykuł firmy Dreamlab.

Staraj się korzystać z docker’owego cache’a jak najlepiej – jeśli piszesz plik Dockerfile, to komendy, które są niezmienne dla danego obrazu umieszczaj maksymalnie na górze, a te które powodują częste zmiany (jak np. COPY . . nowego kodu) na dole pliku. W ten sposób optymalizujesz używanie cache’a i sprawiasz, że niektóre warstwy nie muszą być odtwarzane przy każdej zmianie kodu.

Nie zakładaj, że pliki umieszczone wewnątrz obrazu Docker są bezpieczne – obraz nie jest dobrym miejscem na umieszczenie sekretów. Powinny one zostać dostarczone do kontenera na etapie jego uruchomienia przez takie oprogramowanie jak np. Secrets.

Używaj pliku .dockerignore, aby mieć pewność, że tajne pliki nie będą umieszczone w obrazie – plik /dockerignore jest odpowiednikiem .gitignore dla Dockera. Pozwala na wyspecyfikowanie plików, które nie powinny znaleźć się w obrazie takich jak np. klucze prywatne.

Monitoruj to co dzieje się w kontenerze – monitorowanie twojej aplikacji jest ważnym elementem zabezpieczeń. Dzięki temu możesz na wczesnym etapie wykryć niepokojące metryki aplikacji i zobaczyć, czy nie miał na to wpływu atakujący Twoją aplikację. W przypadku użycia orkiestratora np. Kubernetes często używa się takich narzędzi jak Prometheus czy Grafana, aby dostarczyć osobom zajmującym się IT informacji na temat działającego w kontenerze systemu.

Ograniczaj zasoby jakie może używać dany kontener – w środowisku produkcyjnym w którym działa wiele kontenerów należy zadbać o to, żeby jeden z nich nie pochłonął wszystkich zasobów dla reszty aplikacji, które np. działają w ramach klastra. Zarówno z poziomu Docker’a jak i Kubernetes’a można manipulować ograniczeniami dotyczącymi procesora oraz pamięci operacyjnej.

Pamiętaj o zabezpieczeniu systemu host’a – hardening systemu Linux, to temat na który można napisać wiele artykułów. Wspomnimy tylko o tym, że warto robić backupy niezbędnych plików, monitorować zachowanie serwera, dobrze strzec swoich sekretów (SSH czy hasła), a także poprawnie ustawiać uprawnienia w systemie. Dla zainteresowanych polecamy zapoznanie z takimi tematami jak SELinux czy Apparmor.

Miej plan działania na wypadek incydentu – jeśli zdarzy się incydent bezpieczeństwa czy inny incydent, który wpływa na klientów, należy mieć gotowy plan działania i według niego postępować. Jeśli sytuacja jest stresująca, decyzje na poczekaniu mogą negatywnie wpłynąć na całą infrastrukturę i w efekcie – na biznes. Plan działania czy odtwarzania infrastruktury w przypadku awarii jest niezbędny dla prowadzenia biznesu o wysokiej jakości usług.

Podsumowanie

Mamy nadzieję, że nasza krótka seria o Dockerze i dobrych praktykach przyczyni się do wzrostu bezpieczeństwa i jakości Waszych usług. Jeśli jesteście głodni głębszej wiedzy na temat bezpieczeństwa kontenerów, to poniżej zostawiamy Wam parę linków z którymi możecie się zapoznać. Zapraszamy do lektury za tydzień!

• https://docs.docker.com/engine/security/userns-remap/
• https://docs.docker.com/scout/quickstart/
• https://blog.aquasec.com/dirty-cow-vulnerability-impact-on-containers
• https://docs.docker.com/config/containers/resource_constraints/
• https://blog.aquasec.com/docker-security-best-practices#Scan-and-Verify
• https://medium.com/@mccode/dont-embed-configuration-or-secrets-in-docker-images-7b2e0f916fdd
• https://www.innokrea.pl/blog/wirtualizacja-konteneryzacja-i-zasady-projektowe-dotyczace-kontenerow-wedlug-redhat/
• https://www.innokrea.pl/blog/docker-konteryzacja-wirtualizacja/
• https://www.youtube.com/watch?v=KINjI1tlo2w&list=PLBf0hzazHTGNv0-GVWZoveC49pIDHEHbn&index=1

Skorzystaj z naszego doświadczenia i umów się na darmowe konsultacje dotyczące Docker’a! Kliknij tutaj.