Domowy lab - dodatek

Dominik Miklaszewski
by Dominik Miklaszewski

Categories

Tags

Popełniając wpis na temat rejestru dockerowego, zrobiłem sobie przegląd poprzednich wpisów. Dotarło do mnie, że w sumie, przedstawiając mój pomysł na lab, nie przedstawiłem go do końca. Zabrakło obrazka jak widzę całość rozwiązania, chociażby z lotu wróbelka. Po drugie, primo - w tzw. międzyczasie, zmieniłem plany co do GitLaba-CE. Skoro od dłuższego czasu korzystam z GitHuba, to czas najwyższy zacząć używać ostatnio wdrożone funkcjonalności, jak: skanowanie kodu, mechanizm analizy zależności Dependabot i last, but not least.. GitHub Actions na lokalnie zainstalowanym GitHub runnerze.

W ten sposób, platforma GitHuba zapewni mi niemal kompletny CI, poza linterami, SonarQubem, trivy i ZAProxy. Te będę miał u siebie, tak samo jak CD - klaster trio Hashicorpowego - Nomad, Consul, Vault. Natomiast, “lokalność” githubowego runnera zapewni mi pełną dostępność do lokalnych komponentów przy pomocy kodu GitHub Actions.

Obrazek całości wygląda więc tak:

center-aligned-image

Proszę o jeszcze 3 minuty uwagi, postaram się zwięźle objaśnić ten makaron powyżej.

Założenia

Założenia do konstrukcji tego labu, są następujące:

  1. Budowa i deployment webowych aplikacji skonteneryzowanych;
  2. Bezpieczeństwo badane jest wielowarstwowo:
    • kod i zależności,
    • docker i OS,
    • logika biznesowa aplikacji (poprzez UI),
  3. W miarę modułowa budowa labu, tak aby można było szybko uruchomić potok wytwórczy (ang. pipeline) dokładając do niego kolejne elementy i komplikując życie pracującemu nad kodem.
  4. Platforma CD wolna od komponentów CI - tzn. aby się nie zapętlić i nie zacząć walczyć o zasoby, komponenty CI - są albo w GitHubie albo instalowane na VMkach lokalnie. (Wyjątkiem jest rejestr dockerowy, dla którego osobna VMka to spory overkill)
  5. Szczupłość zasobów powoduje, że platforma CD to tylko jeden klaster - a nie co najmniej, dwa - dev/test i prod.

No to lecimy..

  1. Na początku było słowo, a więc kod.. leci commit do GitHuba.
  2. Zdefiniowane w YAMLu post-commit-checks sprawdzają składnię, poprawność, w drobnym zakresie nawet bezpieczeństwo, są to głównie lintery: Hadolint dla dockera, Pylint dla pythona, ESlint dla JS/TS, może shellcheck.
  3. Kolejny YAML GH Action-a zabiera się za wykonanie testów jednostkowych na zrealizowanej zmianie w kodzie i melduje wyniki do SonarQuba.
  4. Jeśli jest jest Ok, zabieramy się za budowanie aplikacji.
  5. Zbudowane obrazy aplikacji czy dowolne inne są skanowane przez (AquaSecurity) Trivy odpalanego na zawołanie z kontenera trivy-cli. Sam skaner będzie zainstalowany jako osobna VMka albo usługa na już istniejącej.
  6. Jeszcze nie przyjrzałem się jak to się robi, ale jeśli będzie można - to - jeśli wykryte zostaną podatności HIGH+, budowa zakończy się niepowodzeniem i stosownym komunikatem.
  7. Obraz “czysty” pobierany jest przez stosowną automatykę GH, do testowego deploymentu na Nomadzie. Tu wydarzy się testowanie UI-a skryptami cypressowymi, a na koniec jako pen-smoke-test wjedzie ZAProxy. Scenariusze testowe cypressa, jak i polityki skanowania ZAPem, będą częścią tego samego repozytorium.
  8. I ten ostatni krok właściwie - deployment produkcyjny, na początku zrobiłbym ręcznie (proszę mnie nie bić!). A to dlatego, że właściwie, to jeszcze nie wiem czego się spodziewać po testach cypressowych i ZAPowych i jakie kryteria przyjąć.

I to tyle, czas pokaże - czy dość, czy nie-dość to ambitne. Pozostaje mi jeszcze wcisnąć gdzieś Grafanę/Loki, a póki co wystarczą natywne logi i UI Nomada, Consula i tryb audit vaulta.