Stworzyłeś plik Dockerfile, przetestowałeś swój kontener lokalnie, czekasz aż przejdzie przez CI/CD. Ostatecznie kontener „śmiga” na PRE-PROD, testy integracyjne przeszły, a testerzy manualni nie zgłaszają żadnych uwag.
I co teraz? Upragniony deploy na PROD-a 🙂 Nie tak szybko.
Dziedziczenie warstw
Ogólnie mówiąc, każdy plik lub artefakt dodany w Dockerfile powoduje utworzenie kolejnych warstw obrazu.
Ta sama zasada obowiązuje podczas tworzenia Dockerfile. W większości przypadków korzystamy z obrazów bazowych, używając dyrektywy „FROM”. Twój końcowy obraz będzie zawierał skondensowane warstwy obrazu bazowego oraz warstwy utworzone na podstawie Twojego Dockerfile.
A co gdy twój obraz bazowy używa innego obrazu bazowego, który jako obraz bazowy korzysta z oficjalnego obrazu np. Ubuntu? Spójrz na poniższy obrazek.
Mam nadzieję, że rozumiesz do czego to zmierza?
Finalnie Twój obraz może dziedziczyć wiele warstw zawierających pliki wykonywalne, o których nigdy nie wiedziałeś.
Co gdy w którejś z warstw obrazu bazowego występuje podatność bezpieczeństwa (ang. security vulnerability)? Jak sobie z tym poradzić?
Co to jest CVE?
CVE czyli Common Vulnerabilities and Exposures standard skupiający listę publicznie dostępnych i już wcześniej zidentyfikowanych podatności bezpieczeństwa.
I nie chodzi tutaj tylko o podatności dotyczące Dockera 🙂 Po więcej szczegółów odsyłam na oficjalną stronę CVE.
To tyle tytułem wstępu – przechodzimy do narzędzi!
1. Clair
„Clair is an open source project for the static analysis of vulnerabilities in appc and docker containers.”
Clair został stworzony przez firmę CoreOS. Jest statycznym analizatorem podatności. Jest on wykorzystywany min. w Quay.io, publicznym Docker Registry, które jest alternatywą dla Docker Hub.
Clair == REST API
Clair sam sobie nie posiada interfejsu UI ani CLI. Jedyna opcja komunikacji to REST API. Istnieją jednak dodatkowe rozszerzenia takie jak np. Klar, który wprowadza komunikację z Clairem za pomocą CLI.
Clair ma obszerną bazę danych która jest pobierana min. z źródeł (CVE) takich jak:
- Debian Security Bug Tracker,
- Ubuntu CVE Tracker
- Red Hat Security Data.
Z związku z tym, że Clair korzysta z tak wielu baz danych, jego audyt jest dość obszerny.
Clair może być zintegrowany z pipelinem CI/CD. W momencie gdy tworzony jest Docker image, kolejnym krokiem może być uruchmienie Clair’a i wykonanie skanowania na nowo utworzonym Docker image.
Clair – real case
Osobiście, jakiś czas temu w procesie CI / CD korzystałem z Clair’a oraz plugina Klar. Jako, że Clair opiera się o REST API, obraz po zbudowaniu był publikowany do Docker Registry. W tym celu zostało utworzone repozytorium do którego trafiały obrazy „do skanowania”. Oprócz tego, gdy wszystkie kroki z procesu CI / CD (w tym skanowanie obrazu) przeszły pomyślnie, obraz został dodawany do oddzielnego, „produkcyjnego” Docker Registry.
Krokiem w procesie CI / CD było uruchomienie następującego skryptu z parametrami. Tak wyglądał cały skrypt.
#!/bin/bash export DOCKER_USER=$1 export DOCKER_PASSWORD=$2 export CLAIR_ADDR=$3 export CLAIR_OUTPUT=$4 export CLAIR_THRESHOLD=$5 klar $6:$7
Parametr $1 oraz $2 to odpowiednio użytkownik oraz hasło do Docker Registry. Parametry $3, $4 oraz $5 dotyczą konfiguracji Claira. Parametr $6 oznacza nazwę obrazu (wraz z registry), a parametr $7 tag obrazu.
Przykładowo gdy jako parametr $6 przekażemy „dnaprawaregistry.azurecr.io/hello-world” a jako parametr $7 „v1”, polecenie wyglądałoby następująco.
$ klar dnaprawaregistry.azurecr.io/hello-world:v1
Pomimo, że proces działał, przyznam szczerze, że teraz zrobiłbym to zupełnie inaczej 🙂
Clair jest bardzo elastyczny pod kątem konfiguracji i integracji z innymi narzędziami. Aby umożliwić developerom rozszerzanie funckjonalności Clair’a, zostały wprowadzone driver’y. Implementacja własnego drivera nie powinna sprawić problemu programistom, którzy mieli styczność z językiem Go.
2. Anchore
„A tool for inspecting container security using CVE data and user-defined policies „
Anchore Engine oprócz możliwości skanowania obrazu pod kątem podatności posiada możliwość dodania własnych polityk bezpieczeństwa (user-defined policy). Podobnie jak Clair, Anchore korzysta z zewnętrznych źródeł (CVE) do pobierania podatności. Dzięki temu, podczas skanowania obrazów otrzymujemy całkiem niezłe rezultaty.
Oczywiście Anchore może być zintegrowany z istniejącym już procesem CI / CD. Co ważne, istnieje plugin do integracji Anchore dla Jenkinsa.
W wersji open-source, Anchore może być używany za pomocą RESTful API oraz Anchore CLI. Istnieje Anchore UI, jednak jest on częścią Anchore Enterprise, która jak można się domyślić na podstawie słówka 'Enterprise’ jest płatna.
Anchore został spakowany i udostępniony jako Docker image, dzięki czemu może zostać użyty na wielu środowiskach developerskich, czy to jako dockerowy kontener lub bardziej rozbudowanej platformy opartej o Kubernetes.
Dzięki Anchore CLI za pomocą jednej komendy jesteśmy w stanie przeskanować dowolny obraz. Przykładowo będzie to moje ulubione – ubuntu :).
$ anchore-cli image vuln docker.io/library/ubuntu:latest os
3. OpenSCAP
„An environment for creating and maintaining security policies for various platforms”
OpenSCAP nie jest tylko narzędziem do skanowania obrazów dockerowych.
OpenSCAP można określić jako ekosystem przeznaczony dla administratorów oraz specjalistów ds. bezpieczeństwa, zawierający zbiór predefiniowanych polityk bezpieczeństwa, metryk, baz danych CVE oraz narzędzi open-source.
Jednym z narzędzi, jest oscap-docker CLI, służący do skanowania obrazów Dockera pod kątem podatności.
Narzędzie to oprócz skanowania CVE, pozwala również na tworzenia własnych polityk bezpieczeństwa.
Przykładowo, aby przeskanować obraz rhel7 należy użyć następującej komendy:
$ oscap-docker image-cve rhel7
OpenSCAP w 2014 roku został nagrodzony przez NIST (National Institute of Standards and Technology) certyfikatem Security Content Automation Protocol (SCAP).
Ponieważ OpenSCAP jest czymś „większym” niż pozostałe wspomniane w artykule narzędzie, może być dobrym wyborem w przypadku implementacji polityk bezpieczeństwa nie tylko kwestii Dockera, ale dla całego zarządzanego przez nas ekosystemu.
Podsumowanie
Oprogramowanie jest (nadal) tworzone przez ludzi i ludzie popełniają błędy. Nie pozwól, aby takie błędy prześladowały Twoje obrazy Dockera. Skorzystaj z narzędzi do skanowania podatności i uchroń się przed już wykrytymi problemami bezpieczeństwa. Zintegruj skanowanie obrazów jako część procesu CI / CD oraz zablokuj wdrażanie aplikacji, gdy podatności bezpieczeństwa zostaną wykryte.
