Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


26.10.2020

Nowa wersja nVision

Można już pobierać nową wersję nVision
26.10.2020

Monitorowanie infrastruktury

Vertiv Environet Alert
23.10.2020

Telefonia w chmurze

NFON Cloudya
23.10.2020

Nowości w EDR

Bitdefender GravityZone
23.10.2020

Wykrywanie anomalii

Flowmon ADS11
23.10.2020

Mobilny monitor

AOC 16T2
22.10.2020

HP Pavilion

HP zaprezentowało nowe laptopy z linii Pavilion.
22.10.2020

Inteligentny monitoring

WD Purple SC QD101
22.10.2020

Przełącznik 2,5GbE

QNAP QSW-1105-5T

Docker – pięćdziesiąt twarzy bezpieczeństwa

Data publikacji: 19-04-2018 Autor: Maciej Lelusz
PROCES ZARZĄDZANIA...

W numerze 3/2018 „IT Professional” przedstawiliśmy podstawowe zasady tworzenia bezpiecznego środowiska do konteneryzacji, skupiając się na zabezpieczaniu pojedynczych kontenerów. Dziś ciąg dalszy dobrych praktyk, więcej uwagi poświęcamy jednak całemu środowisku i metodologii pracy z nim.

Może i tytuł tego artykułu brzmi trochę śmiesznie, ale z pewnością znajdziemy w nim odrobinę prawdy. Każdy z nas bowiem inaczej rzeczone bezpieczeństwo interpretuje i rozumie. Jedni będą wierzyć, że bezpieczeństwo zapewnią nam ograniczenia, polityki i audyty. Dla innych liczy się tylko warstwa kontroli i nieprzerwanych testów środowiska. Natomiast ktoś może też wierzyć, że jedyną drogą jest kuloodporna architektura. Poniekąd wszyscy mają trochę racji i chyba właśnie w całym tym zamieszaniu chodzi o to, aby osiągnąć równowagę pomiędzy ograniczeniami, kontrolą i architekturą. Przesadzenie w którymkolwiek ze wspomnianych aspektów rodzi sytuacje patologiczne, a ktoś posiadający mniejszą lub większą wiedzę w tym zakresie i tak będzie w stanie ominąć wprowadzone restrykcje.

Poprzednia część cyklu mówiła o tym, jak podejść do zabezpieczenia kontenera jako pojedynczego bytu, a nie całego środowiska. To ważne, aby zrozumieć, że bezpieczeństwo zależy od szczegółów. Małe problemy i ich trywialne zabezpieczenia to cegiełki, które budują podstawy bezpiecznego środowiska. Co jednak począć, gdy „rośniemy”? Gdy nasza mała piaskownica zmienia się w pustynię, a kontenerów zaczynamy mieć tyle, ile ziarenek piasku?

Na początek przypomnijmy słowniczek pojęć, aby mówić tym samym językiem. Host to dla nas serwer fizyczny lub maszyna wirtualna, generalnie nie ma to znaczenia, liczy się system operacyjny w kontekście konteneryzacji i nazywany jest on Hardware Land, w nim uruchamiany jest program nazywany Docker Engine lub Docker Daemon. Silnik ten umożliwia uruchamianie Docker Images – obrazów zawierających aplikacje, które, gdy się już uruchomią, nazywane są kontenerami. Zestaw Docker Engine działających w grupie nazywamy klastrem.

> PODSTAWOWE ZASADY

Zacznijmy od tego, że różowe lata siedemdziesiąte bezpowrotnie minęły i wiadomo, że jak nie stworzymy dekalogu zasad dla naszej infrastruktury, to po krótkim czasie przerodzi się ona ze sformalizowanego, chodzącego jak kałasznikow środowiska, w smerfną wioskę. Będzie się tam działo wszystko naraz i bez kontroli. Dodatkowo wdrożony system CI/CD (Continuous Integration / Continuous Delivery) tylko podkręci hipisowską atmosferę. Jak się bronić przed tą eskalacją hardcoru? Otóż sprawa jest relatywnie prosta – należy wdrożyć wspomniane zasady już na samym początku.
 
Po pierwsze – brak dostępu do komendy docker na węźle Docker Engine. Takie odcięcie pępowiny pozwoli nam na zachowanie porządku. Wówczas jedynym sposobem na uruchamianie kontenerów będzie ścieżka zaprojektowana przez nas w procesie CI/CD. Pętla tego procesu będzie zapewne inicjowana przez aktualizację którejś z gałęzi naszego repozytorium, co finalnie stworzy zestaw kontenerów na infrastrukturze. Jest to jedyna droga. Każda inna to półśrodek i wystawianie się na potencjalne problemy. Warto bowiem zauważyć, co implikuje taki ruch – nikt poza zdefiniowanymi, wyznaczonymi osobami nie będzie miał dostępu do klastra. W takiej sytuacji dostęp ten można porządnie zabezpieczyć – 2FA, klucze (być może nawet sprzętowe), dedykowane podsieci znajdujące się za VPN/ Firewall. Sposobów jest wiele, a co ważne, można je zaimplementować w harmonii, nie powodując paraliżu działu deweloperskiego, który nieświadomy tego kręci pętlami CI/CD, wymieniając wersje aplikacji. Nikt tego dostępu tak naprawdę nie potrzebuje, jednak osoby które mogłyby z niego korzystać, nie powinny nawet o tym myśleć. Należy postawić sprawy kategorycznie i już na samym początku odciąć wszystkim dostęp do klastra, pozostawiając ścieżkę CI/CD.

> DOCKERFILE

Kolejną zasadą ograniczającą buszowanie po infrastrukturze jest postawienie wszystkich dostawców aplikacji w kontenerach przed faktem, że obraz kontenera tzw. Docker Image budowany jest wewnętrznie, a ich zadaniem jest jedynie dostarczyć Dockerfile. Plik ten musi się znaleźć w repozytorium, gdzie będzie podlegał wersjonowaniu i opiniowaniu. Dzięki Dockerfile jesteśmy w stanie zbudować kontener. Plik ten zawiera w sobie szereg reguł, które pozwolą nam na stworzenie bazowego kontenera, który może działać wszędzie, ale również nie będzie działać nigdzie bez odpowiedniego pliku konfiguracyjnego (o tym za chwilę). Oto przykładowy Dockerfile:

FROM alpine

LABEL MAINTAINER="XYZ <xyz@cmnrtplsk>"
LABEL APP="mysql v. XYZ"
ENV TIMEZONE Europe/CET
ENV MYSQL_ROOT_PASSWORD root
ENV MYSQL_DATABASE app
ENV MYSQL_USER app
ENV MYSQL_PASSWORD app

RUN apk add --no-cache mysql
RUN addgroup mysql mysql

WORKDIR /entry-scripts
COPY entry-scripts/init.sh init.sh

EXPOSE 3306

ENTRYPOINT [ "./init.sh" ]

[...]

Bloger i niezależny konsultant z wieloletnim doświadczeniem w branży IT, specjalizujący się w wirtualizacji i cloud computingu. Posiada tytuły MCP, MCTS, VCP oraz VMware vExpert.

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"