GitOps zalety i zagrożenia CyberSec

GitOps to nowoczesne podejście do zarządzania infrastrukturą i aplikacjami za pomocą systemu kontroli wersji Git. Polega na wykorzystaniu repozytorium Git jako jedynego źródła prawdy dla całej infrastruktury i kodu aplikacji. Zmiany wprowadza się poprzez zatwierdzanie commitów, a narzędzia CI/CD (Continuous Integration/Continuous Deployment) automatycznie wdrażają te zmiany na odpowiednie środowisko zaczynając od testowego kończąc na produkcyjnym. GitOps integruje zarządzanie infrastrukturą z praktykami deweloperskimi, co pozwala na osiągnięcie większej przejrzystości, automatyzacji i spójności w procesach wdrożeniowych. Należy pamiętać jeszcze, że oprócz dużej liczby zalet każdy model operacyjny, który zostanie niepoprawnie zaimplementowany może za sobą nieść wiele zagrożeń, w tym zagrożeń związanych z CyberSec.

Dlaczego GitOps zyskuje na popularności?

GitOps staje się coraz bardziej popularny, zwłaszcza w zespołach korzystających z chmury publicznej. Korzyści wynikające z tego podejścia obejmują:

• Automatyzacja: Procesy CI/CD pozwalają na automatyczne wdrażanie zmian, co zwiększa efektywność i skraca czas wprowadzania nowych funkcji. Dzięki temu zespoły mogą szybciej reagować na zmieniające się wymagania biznesowe i błyskawicznie wdrażać poprawki oraz nowe funkcje.
• Spójność: Wszystkie zmiany są zarządzane przez Git, co zapewnia, że każda zmiana jest zapisywana i można ją łatwo odtworzyć lub cofnąć. Umożliwia to utrzymanie spójnej wersji infrastruktury oraz aplikacji na różnych etapach rozwoju.
• Transparentność: Cała historia zmian jest dostępna w repozytorium, co umożliwia śledzenie wprowadzonych modyfikacji i ich autorów. Przejrzystość tych zmian pozwala na lepsze zrozumienie ewolucji systemu oraz łatwiejsze identyfikowanie przyczyn ewentualnych problemów.
• Zwiększona kontrola: Dzięki GitOps, każda zmiana w infrastrukturze jest ściśle kontrolowana i zatwierdzana przez system kontroli wersji. Umożliwia to bardziej restrykcyjne podejście do zarządzania dostępem oraz zgodnością z politykami bezpieczeństwa.
• Łatwiejsza skalowalność: Automatyzacja procesów wdrażania i zarządzania infrastrukturą umożliwia łatwiejsze skalowanie systemów w odpowiedzi na rosnące zapotrzebowanie.

Mimo licznych zalet, GitOps nie jest pozbawiony problemów. W praktyce, często okazuje się, że wdrażanie tego podejścia napotyka na różnorodne trudności.

Problemy związane z GitOps

• Niejasne commit messages: Słabe opisy commitów, takie jak “Test”, “.”, “debug”, nie dostarczają żadnych informacji o wprowadzonych zmianach. Brak zrozumienia, co dokładnie zostało zmienione, może prowadzić do trudności w analizie kodu i identyfikacji źródeł błędów.
• Brak szablonów i procedur: Procedury mergowania przekazywane ustnie, brak standardowych szablonów commitów czy pull requestów. Brak formalizacji tych procesów może prowadzić do niekonsekwencji i błędów podczas integracji zmian.
• Chaos w repozytorium: Losowe pliki i nazwy zasobów, brak czytelnej struktury kodu IaC (Infrastructure as Code). Taka organizacja plików utrudnia zarządzanie i zrozumienie struktury projektu, co jest szczególnie problematyczne w dużych zespołach.
• Brak dokumentacji: Brak plików README.md lub ich niekompletna zawartość typu “todo”. Bez odpowiedniej dokumentacji, nowe osoby w zespole mają trudności ze zrozumieniem architektury projektu oraz procesów wdrożeniowych.

W efekcie, przy przeglądzie kodu w celu analizy bezpieczeństwa, na pytanie “pokażcie nam jak wygląda architektura infrastruktury” często otrzymujemy link do repozytorium z chaotycznie nazwanymi plikami i zasobami. Brak spójności i przejrzystości w repozytorium utrudnia ocenę bezpieczeństwa systemu oraz identyfikację potencjalnych luk.

Standardy w projektach open source

W projektach open source, które są aktywnie rozwijane przez społeczność, istnieją ścisłe reguły dotyczące jakości commitów. Commit messages muszą być informacyjne i spełniać określone standardy. Przykładowo, commity z niejasnymi opisami są automatycznie odrzucane, nawet jeśli zawierają implementację ważnych funkcji. Wysokie standardy jakości commitów w projektach open source są kluczowe, ponieważ:

• Zwiększają przejrzystość: Każda zmiana jest dokładnie opisana, co ułatwia śledzenie historii projektu i zrozumienie wprowadzonych modyfikacji.
• Umożliwiają efektywną współpracę: Jasne i zrozumiałe commit messages pozwalają innym deweloperom szybko zrozumieć, co zostało zmienione i dlaczego.
• Zapewniają spójność: Stosowanie standardowych szablonów i procedur commitowania minimalizuje ryzyko błędów i nieporozumień.

Przykłady dobrych praktyk w projektach open source obejmują:

• Stosowanie opisowych commit messages, które jasno wskazują, co zostało zmienione i dlaczego.
• Używanie szablonów pull requestów, które zawierają szczegółowe instrukcje dotyczące weryfikacji i testowania zmian.
• Regularne przeglądy kodu przez członków społeczności, co pomaga w utrzymaniu wysokiej jakości projektu.

Standardy w Twoich projektach

Analizując wiele projektów biznesowych i rozmawiając z zespołami projektowymi (w wielu obszarach, nie tylko telco 🙂 ) można odnieść wrażenie, że rozwój aplikacji i rozwiązań biznesowych nie przystaje do standardów, które starają się śrubować społeczności OpenSource.

Z czego to wynika? Czy krytyczność i ważność projektów korporacyjnych ma mniejsze znaczenie aniżeli projekty, które są rozwijane przez entuzjastów na GitHubie? Pewnie sprawa dyskusyjna a punkt widzenia zależy od punktu siedzenia 🙂

Nie mniej jednak częsta rotacja, natłok pracy i ilości ticketów do obsłużenia oraz ściganie się aby konkurencja nie wdrożyła zmiany przed nami prowadzi do problemów takich jak:

• Brak formalnych procedur: Brak standardowych procedur zarządzania zmianami i integracją, co prowadzi do niekonsekwencji i błędów w procesie wdrożeniowym.
• Niedostateczna dokumentacja: Brak pełnej dokumentacji procesów i architektury, co utrudnia zrozumienie i zarządzanie projektem.
• Słabe commit messages: Niejasne opisy commitów, które nie dostarczają wystarczających informacji o wprowadzonych zmianach.

a to już jest bardzo duże zagrożenie dla procesu GitOps, przez które w dłuższym okresie czasu możemy obserwować więcej negatywnych skutków niż tych pozytywnych.

A czy wiesz, że dobra praktyka jest posiadanie pliku SECURITY.md?

Plik SECURITY.md jest coraz częściej uznawany za dobrą praktykę w projektach zarówno open source, jak i korporacyjnych. Służy on do dokumentowania polityk i procedur związanych z bezpieczeństwem projektu. Oto kilka powodów, dla których warto go mieć:

• Zwiększa świadomość bezpieczeństwa: Posiadanie pliku SECURITY.md pomaga zespołowi być bardziej świadomym zagadnień związanych z bezpieczeństwem i promuje najlepsze praktyki.
• Jasne wytyczne dla zespołu: W projektach open source, plik ten dostarcza społeczności informacji na temat zgłaszania podatności oraz procedur bezpieczeństwa, co ułatwia zarządzanie incydentami.
• Ułatwia współpracę: Dokumentując polityki bezpieczeństwa, organizacje mogą łatwiej współpracować z innymi podmiotami, zapewniając spójność i przejrzystość działań.
• Buduje zaufanie: Przejrzystość w zakresie polityk bezpieczeństwa buduje zaufanie użytkowników i partnerów do projektu.

Przykładowa zawartość pliku SECURITY.md może obejmować:

• Informacje kontaktowe dla zgłaszania luk bezpieczeństwa.
• Procedury postępowania w przypadku wykrycia podatności.
• Zasady dotyczące audytów bezpieczeństwa.
• Wytyczne dotyczące bezpiecznego kodowania i konfiguracji.

Podsumowując, GitOps to potężne narzędzie (lub model operacyjny, kto jak woli), które może znacznie usprawnić procesy wdrażania i zarządzania infrastrukturą. Jednak aby w pełni wykorzystać jego potencjał, niezbędne jest przestrzeganie odpowiednich praktyk i standardów, w tym dbałość o dokumentację, jasne commit messages i spójność w repozytorium. Dodatkowo, wprowadzenie pliku SECURITY.md może znacząco poprawić zarządzanie bezpieczeństwem projektu, zapewniając przejrzystość i spójność w podejściu do kwestii bezpieczeństwa.