Jakie najlepsze i kompleksowe praktyki należy wziąć pod uwagę podczas uruchamiania dokera w produkcji?

Wreszcie, jesteś tak bardzo zakochany w Docker, że chcesz przenieść swoje krytyczne pod względem biznesowym systemy produkcyjne online z wrażliwymi danymi klientów do Docker Swarm. Niektórzy nawet już to zrobili. Innej organizacji nie stać na to z powodu polityki zabraniającej procesów produkcyjnych działających w trybie root.

Jaka może być lista kontrolna elementów składowych do rozważenia w środowisku produkcyjnym Docker? Nie potrzeba ich wszystkich, ale wszystkie powinny być ważne do oceny.

Oświadczenie: Wiem, że istnieje polityka SE, aby unikać „dużych niekończących się list”, ale myślę, że ta lista kontrolna nie może być bardzo duża ... i nieskończona noway.

Więc - czym są te bloki budynków?

1. Jeśli jeszcze nie został wdrożony, rozważ uruchomienie systemu hosta Linux z zaawansowanymi ustawieniami bezpieczeństwa - wzmocnione jądro, SELinux itp.
2. Zastanów się nad użyciem małego obrazu podstawowego Docker, takiego jak alpejski, busybox, a nawet zadrapania, np. Zacznij od pustego obrazu podstawowego
3. Użyj ustawienia USER innego niż root
4. Ostrożnie oceń, aby jeszcze bardziej zmniejszyć i tak już zmniejszony zestaw możliwości jądra przyznanych kontenerowi
5. Rozważ użycie tylko jednego pliku binarnego na kontener do uruchomienia procesu, idealnie powiązanego statycznie
6. Ci, którzy chcą złamać system, aby uzyskać dostęp do powłoki, mogą się zastanawiać, czy dowiedzieli się, że w twoim kontenerze zostały wyłączone wszystkie powłoki
7. Montuj woluminy tylko do odczytu tam, gdzie to możliwe

Pytanie: co jeszcze?

Host, na którym działają kontenery

Uruchom ławkę zabezpieczeń dokera na każdym węźle, który uruchamia kontenery dokowania https://github.com/docker/docker-bench-security

Uruchom następujące polecenie w węźle, który obsługuje kontenery dokerów:

docker run -it --net host --pid host --cap-add audit_control \
    -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
    -v /var/lib:/var/lib \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v /usr/lib/systemd:/usr/lib/systemd \
    -v /etc:/etc --label docker_bench_security \
    docker/docker-bench-security

zwraca listę kontroli:

[INFO] 1 - Host Configuration

[WARN] 1.1  - Ensure a separate partition for containers has been created

[NOTE] 4.2  - Ensure that containers use trusted base images

[PASS] 4.6  - Ensure HEALTHCHECK instructions have been added to the container image

Cytat z repozytorium README:

Docker Bench for Security to skrypt sprawdzający dziesiątki popularnych najlepszych praktyk dotyczących wdrażania kontenerów Docker w środowisku produkcyjnym. Wszystkie testy są zautomatyzowane i są inspirowane przez CIS Docker Community Edition Benchmark v1.1.0 .

Niektóre problemy zgłoszone przez ławkę bezpieczeństwa można rozwiązać, czytając oficjalny artykuł dotyczący bezpieczeństwa dokera i porównując go z punktorami zdefiniowanymi w pytaniu, ważne są również następujące rzeczy:

• chroń gniazdo demona dokera, implementując ssl
• zaufanie treści przy użyciu notariusza i DOCKER_CONTENT_TRUSTzmiennej

Docker jest wciąż w fazie rozwoju.

Ponieważ przy każdym innym oprogramowaniu pojawią się błędy, mogą zostać dodane niepewne funkcje, mogą wystąpić wady architektoniczne prowadzące do naruszenia bezpieczeństwa. Nie lekceważ tego! Twój system może być dziś całkowicie bezpieczny, ale dzięki łatce z następnego tygodnia ktoś znajdzie błąd, napisze exploita i nagle twój system jest szeroko otwarty.

Jeśli nie musisz, nie aktualizuj do najnowszej wersji. Zamiast tego użyj najnowszej sprawdzonej wersji.

Docker to nie wirtualizacja

Jeśli ktoś ucieknie z kontenera Docker, atakujący jest natychmiast na prawdziwej maszynie. Nie ma drugiej bramki, takiej jak wirtualizacja, która zapobiegałaby naruszeniu.

Traktuj kontener Docker jak każdy inny program. Uruchom z możliwie najniższymi uprawnieniami użytkownika, zablokuj cały niepotrzebny ruch sieciowy, zwirtualizuj cały host Dockera, jeśli pozwala na to wydajność.

Doker nie stanowi ochrony

Jakikolwiek kod jest uruchamiany w kontenerach Docker, jest uruchamiany bez pytania z Docker. Każdy atakujący może po prostu zainstalować swoje oprogramowanie w kontenerze, a Docker uruchomiłby go tak jak każdy inny kod.

Oprócz rzeczy wymienionych w pytaniu, rozważ użycie metryk i alertów, aby otrzymywać powiadomienia, jeśli jakikolwiek obraz Dockera robi dziwne rzeczy. Czy występuje nagły, ciągły skok procesora? Czy program nagle skanuje porty sieciowe? Czy istnieje podejrzany dostęp do dysku? Powinieneś otrzymać powiadomienie, jeśli coś takiego się wydarzy. Istnieje wiele narzędzi do pomiaru tych rzeczy, powinieneś ich użyć.

Sam obraz dokera

Dodatkową opcją jest użycie Clair .

Clair to projekt typu open source do statycznej analizy luk w kontenery aplikacji (obecnie w tym appc i docker).

W regularnych odstępach czasu Clair pobiera metadane podatności na zagrożenia ze skonfigurowanego zestawu źródeł i przechowuje je w bazie danych.

Klienci używają Clair API do indeksowania swoich obrazów kontenerów; tworzy to listę funkcji obecnych na obrazie i przechowuje je w bazie danych.

Klienci używają Clair API do przeszukiwania bazy danych w poszukiwaniu luk w zabezpieczeniach określonego obrazu; dla każdego żądania wykonuje się korelowanie podatności i funkcji, unikając konieczności ponownego skanowania obrazów.

Gdy pojawią się aktualizacje metadanych podatności, można wysłać powiadomienie do systemów alarmowych o wystąpieniu zmiany.

Naszym celem jest zapewnienie bardziej przejrzystego obrazu bezpieczeństwa infrastruktury opartej na kontenerach. Tak więc projekt otrzymał nazwę Clair od francuskiego terminu, co przekłada się na jasne, jasne, przejrzyste.

Oprócz punktów w tym wątku; moje zalecenie byłoby następujące:

• Przejmij kontrolę nad Dockerem PID1 za pomocą głupiego-init
  • ref: Problem zbierania PID1 i Zombie
• Nie uruchamiaj dokera w produkcji bez systemu aranżacji kontenerów
  • Wybierz spośród Kubernetes, Mesos, Swarm itp.
• Użyj gosu do kontroli użytkownika wewnątrz obrazu dokera
• Postępuj zgodnie z paradygmatem aplikacji 12-czynnikowej, jeśli korzystasz z aplikacji stanowych w kontenerach, zmień ją.
  • Jeśli naprawdę potrzebujesz uruchamiać aplikacje stanowe (mysql, zookeeper, elasticsearch) w kontenerach, wykorzystaj paradygmaty orkiestratora, takie jak Kubernetes Statefulsets
• Wykonuj niezawodne zarządzanie tajnymi / konfiguracyjnymi za pomocą narzędzi takich jak hashicorp vault / consul
• Wyślij ten sam kontener zbudowany przez deweloperów, aby przepychać się przez rurociąg CI, który przeprowadzi go dokładnie przez etapowe testy integracyjne.
• Twórz powiadomienia wokół CVE i łatek, wyzwalaj kompilacje na powiadomieniach o łatkach
• Posiadaj obszerne logowanie, aby uzyskać wgląd w działający kontener, nie chcesz zapewniać deweloperom SSH dostępu ani do hosta, ani do kontenerów
  • zalecenie: płynnie
• Mieć zarówno dane kontenera, jak i hosta
  • zalecenie: prometheus + eksporter węzłów

Jeśli wypełniasz punkt wejścia dokera sedpoleceniami, rozważ tę praktykę:

• Użyj narzędzia, takiego jak confd, aby zarządzać plikami konfiguracyjnymi obrazów dokera i aktualizować je

Confd odczyta dane z wielu obsługiwanych magazynów klucz-wartość i dynamicznie wyświetli szablony konfiguracji.

Można użyć A2D do upieczenia aplikacji na obrazie dokera, biorąc pod uwagę pewne rzeczy, np. Inne niż root, uprawnienia, lokalizacja aplikacji:

docker run -v $PWD:/projectName utrecht/a2d:1.0.0 \
       -projectName someProjectName -dockerfile /projectName/Dockerfile

zwroty:

FROM golang:1.12.4-alpine as builder
COPY . ./someProjectName/
WORKDIR someProjectName
RUN adduser -D -g '' someProjectName && \
    apk add git && \
    CGO_ENABLED=0 go build && \
    cp someProjectName /someProjectName && \
    chmod 100 /someProjectName

FROM scratch
COPY --from=builder /etc/group /etc/group
COPY --from=builder /etc/passwd /etc/passwd
COPY --from=builder --chown=someProjectName:someProjectName /someProjectName /usr/local/someProjectName
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
USER someProjectName
ENTRYPOINT ["/usr/local/someProjectName"]