Od ostatniego wpisu upłynęły ponad dwa miesiące. Cóż to się zadziało. Ano, zadziało się tyle, że wziąłem się za naukę programowania w JS, a konkretnie full-stack w express-ie, w dodatku jakimś tam MongoDB jeszcze. “Bleee” - mrukną niektórzy - “interpreter”. No tak, ale nie chciałem się rzucać od razu z motyką na Angulara. Aby nauczyć się pisać testy jednostkowe (ang. unit tests) w jest (dżestsie?!), czy akceptacyjne w Cypress-ie, muszę mieć jakąś aplikację której kod rozumiem. Więc wyszło mi tak, że musiałem ją sobie napisać sam.
Bardzo pomógł mi w tym dziele ten oto kurs: Learn Javascript: Full-stack from scratch. Brad - autor i prowadzący, jest wyśmienitym wykładowcą i podchodzi do tematu systematycznie, logicznie i całościowo. Jeśli mamy na tapecie logowanie użytkownika, to za chwilę jedziemy z tematem, jak zrobić to bezpiecznie. Jeśli mamy integrację z MongoDB, to wjeżdżają dobre praktyki NIE przechowywania danych uwierzytelniających w kodzie.Jeśli przerabiamy logikę zależną od informacji w ciastkach sesji, to upewniamy się, że nie ma w nich “przecieków”, np. ID użytkownika Ok, ale po co nazwa loginu. Pilnuje też dobrej praktyki nie duplikowania takich samych części w kodzie aplikacji. I tak dalej.
No, ale do rzeczy. Gdzie jestem z moim projektem? Przypomnnę obrazek z ostatniego wpisu, nieco już zazieleniony (wszak wiosna idzie!).
Co zostało zrobione?
- Aplikacja czyli “codebase” jest, ukończona w 80%, po prostu nie ma jeszcze wszystkich funkcjonalności. Po commit-cie, lecą następujące akcje:
- Githubowy CodeQL security check (z powiadomieniami mailowymi),
- GitGuardian scan (w poszukiwaniu danych uwierzytelniających w kodzie) - zewnętrzna usługa SaaS zintegrowana z GH,
- Sonarqube scan i meldunek do SonarQube-a, na razie - bugi, code smells i security issues,
- raz na tydzień skan zależności przez Dependabota (z powiadomieniami),
- Dockerowe obrazy bazowe - po zbudowaniu, a przed deploymentem, sprawdzane skanerem Trivy.
- Ubuntu 20.04 + nodejs 14,
- Fedora 35 + nodejs 16,
- Trivy,
- Hadolint,
- Docker registry v2,
- MongoDB,
- PostgresQL + Sonarqube
- Sama platforma Nomad z uwierzytelnianiem deploymentu w Vaulcie i Consulem działa i update-y jej nie straszne.
MongoDB, trivy-server i rejestr dockerowy wiszą sobie dzielnie na Nomadzie jako usługi. Sonarqube z postgresem, też miałem jednak zamiar wrzucić Nomadowi do zarządzania, ale mam jeszcze problemy z persistent-storage (może opiszę to w osobnym wpisie). Z tego powodu, Sonarqube - przyznam, z niejakim wstydem - wisi sobie na tej nomadowej VM-mce, ale odpalony przez docker-compose.
Self-hosted Github runner
Wydaje się, że rozwiązanie z runnerem Githubowym jest najlepszą opcją dla domowego labu, szczególnie w przypadku, gdzie całe środowisko CD mam u siebie. Jednakże, takie rozwiązanie implikuje pewne ograniczenia opisane tutaj. Nakłada też dodatkową robotę związaną z budowaniem własnych obrazów dokerowych pod akcje githubowe, które mają zainstalowane moje wewnętrzne certyfikaty TLS niezbędne do wewnętrznej komunikacji. Prócz tego, wszystkie repozytoria muszą być “prywatne” aby uniknąć zagrożenia, że ktoś sobie wyforkuje moje repo i spróbuje zapuścić coś na moim domowym serwerze przez akcję na runnerze.
Podsumowanie
Wg taksonomii DevSecOps-a i narzędzi pracowicie wymienionych (i aktualizowanych) przez Marka Šottla moje domowe środowisko zapewnia aplikacji następujące mechanizmy ochrony:
- Secrets management - GitGuardian,
- OSS and Dependency management - Dependabot,
- Containers security - Trivy, Hadolint (HAskell DOcker LINTer)
- Static Application Security Testing - Sonarqube
(CodeQL-a jeszcze nie liczę, bo jest w fazie eksperymentalnej). Co jest ciekawe, GitHub jako platforma CI/troche-CD, sama “oferuje” CodeQLa, proponując docelowy kod w /.github/workflows, tak samo Dependabot i GitGuardian. Natomiast Trivy i Hadolinta trzeba już skonfigurować samodzielnie. Sonarqube w wersji 9.3.0 też podpowiada co wpisać do GH workflows.
Lekkim utrudnieniem jest stosowanie domowego GitHub runnera, ponieważ odwołania do dostępnych publicznie na GitHubie akcji nie zadziałają jeśli odwołujemy się w różnych URLach do DNSowych nazw wewnętrznych.
Wyżej wymienione obszary bezpieczeństwa i mechanizmy, chronią moją fantastyczną aplikację, przed następującymi zagrożeniami:
- wycieki danych uwierzytelniających,
- redukcja możliwości ataków poprzez “łańcuch dostaw”- moduły i biblioteki oprogramowania,
- redukcja możliwości ataków na już pracujące kontenery, z których np. nie można “wyskoczyć” do gospodarza z “rootem”,
- redukcja możliwości ataków samej aplikacji, dzięki statycznej analizie kodu.
Nie jest to jeszcze wszystko. Zautomatyzowane testy to z jednej strony jakość samej aplikacji, ale z drugiej, też pozwolą wyłapać czy obsługa błędów nie jest dziurawa. Na deser będzie DAST - czyli ZAP, czyli analiza dynamiczna, zachowania kodu aplikacji i jego odpowiedzi na różne dane wejściowe wrzucane aplikacji przez ZAP-a.
Sonarqubowa krytyka po ostatnim commit-cie
