Dlaczego GitOps jest niezbędny dla DevSecOps
Opublikowany: 2022-02-24Korzyści z DevOps w zakresie automatyzacji, identyfikowalności, a w szczególności współpracy między wcześniej wyodrębnionymi grupami i interesariuszami są bardzo akceptowane. Ale ponieważ grupy DevOps mają duże zadanie polegające na przenoszeniu operacji do skonteneryzowanych środowisk Kubernetes, długie próby i testowane taktyki DevOps mogą się skrócić. Problemy z bezpieczeństwem — i pułapki — przejawiają się również w unikalnych metodach.
Fantastyczną informacją jest to, że GitOps służy do wypełnienia wybranych luk w DevOps w celu zapewnienia stabilności środowisk rozproszonych. Wynika to z faktu, że procesy GitOps bardzo sprzyjają DevSecOps, zdefiniowanym tutaj jako najskuteczniejsze taktyki bezpieczeństwa, które mają zastosowanie do całego cyklu życia oprogramowania.
W tym artykule przyjrzymy się, w jaki sposób GitOps oferuje niezbędną strukturę dla DevSecOps, dla kontroli bezpieczeństwa, które zwiększają się dzięki CI/CD, a także w fazach zapisu i wdrażania w administrowaniu aplikacjami w klastrach Kubernetes.
Samotny, niezmienny zasób rzeczywistości
GitOps można opisać jako:
Funkcjonalny projekt dla Kubernetes i innych systemów rodzimych dla chmury, dostarczający zestaw najlepszych procedur, które ujednolicają wdrażanie Git, zarządzanie i monitorowanie dla skonteneryzowanych klastrów i celów.
Ścieżka w kierunku praktycznego doświadczenia programisty w zakresie zajmowania się programami dokładnie tam, gdzie potoki CI/CD i przepływy pracy Git są wykorzystywane do każdej operacji i rozwoju.
Git jest samotnym źródłem prawdziwej prawdy, ponieważ upragniona konfiguracja jest zadeklarowana właśnie tutaj. W Kubernetes działa agent GitOps, który regularnie porównuje rzeczywisty punkt w Kubernetes z poszukiwanym punktem zapisanym w Git. Wszelkie nowe odmiany połączone z monitorowanym działem w Git są natychmiast stosowane do Kubernetes. I odwrotnie, wszelkie odmiany podręcznika używane w Kubernetes są automatycznie przywracane do stanu idealnego zadeklarowanego w Git. Wyeliminowano dryf konfiguracji.
Git jest zwykle trafnie opisywany jako jedyny zasób prawdziwej prawdy, ponieważ ma zastosowanie do GitOps, dzięki jego niezmiennej kompozycji. Pomoże to między innymi w utrzymaniu granicy — nie w przeciwieństwie do zapory — która oddziela problemy między CI i CD. W ten sposób szereg sposobów zaangażowanych w rozwój aplikacji jako część CI — pull requesty, screening, commits i tak dalej. — trzymaj się osobno na Git.
W przypadku programisty tworzącego żądanie ściągnięcia żądanie ściągnięcia, w czasie sprawdzania i dopuszczenia, jest scalane i rutynowo używane w klastrze w nadchodzącym uzgodnieniu — co zwykle wymaga 15 minut.
Domyślnie proces jest dwukierunkowy — oznacza to, że modyfikacja wytworzona bezpośrednio w Kubernetes jest odwzajemniana w Git, gdy uruchomiona zostanie przyszła pętla uzgadniania (zazwyczaj co 15 minut). Mimo to ten stan rzeczy jest znacznie mniej niż najlepszy, gdy członek zespołu DevOps lub, co gorsza, intruz działający negatywnie, natychmiast dokona zmian w klastrach. Te różnice bezpośrednio w klastrze nie zostały odpowiednio zweryfikowane za pomocą żądań i zatwierdzeń scalających, w wyniku czego naruszają teorię GitOps Git służącą jako niezmienne źródło prawdy w sprawie, gdy występuje dryf.
Jako alternatywę, aby umożliwić złagodzenie występowania dryftu, zasób sprawdzania GitOps może wysyłać alerty, jeśli w klastrze są wytwarzane zmiany, które nie były używane w usłudze Git. W takim przypadku, dzięki ścieżce audytu, kod oprogramowania na Git może następnie zamienić wadliwe modyfikacje zaprojektowane dla klastrów za pośrednictwem kontrolerów we wdrożonym punkcie w naturalnym środowisku wykonawczym.
I odwrotnie, gdy nie zostanie osiągnięta niezmienność, może nastąpić dryf. Może się to zmaterializować podczas ataku na sieć lub gdy członek personelu DevOps nieumyślnie zmieni konfigurację klastra, tak aby różniła się od tego, co jest na Git. Niezgodność jest oznaczana, gdy tak się dzieje — poprzez użycie odpowiedniego sprzętu GitOps — symbolizując w ten sposób kwintesencję DevSecOps, która jest obecna w procesach GitOps.
Odpowiednie aplikacje automatyzują system bieżącego sprawdzania, aby upewnić się, że żądany punkt konfiguracji w repozytorium Git jest zgodny z rzeczywistym stanem w klastrze Kubernetes. Służy również do uzgadniania i sumowania wdrożeń, gdy tylko zostaną one skutecznie dedykowane w zadeklarowanym stanie repozytorium.
Zarządzanie audytem
Funkcje audytu, które przedstawia GitOps, są również kluczowe dla pomocy DevSecOps. Pozostając w repozytorium Git jako jedyne źródło faktów, wszystkie aplikacje, kod i konfiguracje są wersjonowane i zachowują całą ścieżkę audytu, co jest główną koniecznością dla każdego chronionego środowiska naturalnego. Ta ścieżka audytu jest zwykle oferowana zarówno programistom, jak i członkom personelu operacyjnego, w celu zauważenia, co działa w klastrze (większość użytkowników jest ograniczona do dostępu do konfiguracji klastra tylko do przeglądania).
Deweloper może nie zawsze wymagać polegania na ścieżkach audytu w takim stopniu, jak funkcje i klienci personelu DevSecOps, ale może skorzystać z możliwości zrozumienia, jakie zmiany zaszły i co spowodowało zmiany w repozytorium, które się wydarzyły . Krótko mówiąc, dla programisty — jak również dla wszystkich pracowników DevOps — każda rzecz to tylko wylogowanie z Git.
Ścieżki audytu w Git są również dostępne i bardzo proste dla konstruktorów, aby pojawiały się w razie potrzeby. Wynika to z faktu, że końcowe dziedzictwo procesu jest ujęte w programie raportu Git, co rozumieją twórcy.
Dzięki dostępności ścieżki audytu możliwe jest również szybkie wycofanie korekt w aplikacjach, które spowodowały trudności. Jest to szczególnie korzystne, gdy klastry zostały naruszone lub źle skonfigurowane. W tym przypadku, jako alternatywę posiadania odbudowania klastra od podstaw, ścieżka audytu składa się z poszukiwanego punktu w repozytorium. Konfiguracja klastra i programy z żądanym punktem ze ścieżki audytu są następnie wdrażane, a procedura odbudowy jest automatyczna.
Liczba „kluczy do królestwa”
Konstruktorzy zwykle polegają na Jenkins, serwerze automatyzacji, aby opracowywać, sprawdzać i pomagać CI/CD dla potoków produkcyjnych w środowiskach Kubernetes. Pozbawieni GitOps programiści mogliby w każdym innym przypadku uzyskać natychmiastowy dostęp do klastrów Kubernetes, ponieważ bezpośrednio wdrażają swój kod. Innymi słowy i wyrażenia, budowniczowie — bez względu na to, czy są częścią organizacji, czy są wykonawcami działającymi zdalnie — mieliby natychmiastowy dostęp do otoczenia wyjściowego i mieliby „klucze do królestwa”, aby rozmawiać. Rzadko jest to idealna okoliczność bezpieczeństwa.
Wszystko, co wybrałoby we wcześniej wspomnianym przypadku, to dla niewłaściwego użytkownika — lub, co gorsza, intruza — aby mieć dostęp do poleceń KubeConfig lub Kubectl dla klastrów w produkcji, które mógłby uruchomić ze swojego notebooka. Jeśli na przykład osoba atakująca złamała proces CI i ustanowione poświadczenia, może również uzyskać dostęp do dowolnego klastra, do którego ma dostęp system CI.
Prosty fakt, że GitOps pomaga powstrzymać użytkowników — lub atakujących — przed modyfikowaniem konfiguracji klastrów bez pozostawiania żadnych śladów, jest przede wszystkim niezbędny dla zespołów operacyjnych i bezpieczeństwa — oprócz wspierania minimalizacji obciążenia umysłowego programisty. Uzyskując zarządzanie, na przykład, programista zasadniczo nie musi mieć bezpośredniego dostępu do węzłów Kubernetes i/lub wierszy poleceń kubectl. GitOps uzgadnia prawie wszystko, co twórcy nakreślają w Git, ale nie pozwala na ręczny dostęp do klastrów Kubernetes lub środowisk produkcyjnych, z wyjątkiem przypadku, gdy twórcy mają unikalne uprawnienia kontroli dostępu.
Funkcja DevSecOps GitOps jest sposobem na udaremnienie tej sytuacji z wektorami ataku dla CD, chroniąc w ten sposób „klucze do królestwa”. Gdy operatorzy GitOps, tacy jak Open Source Flux — więcej o tym poniżej — działają wewnątrz Kubernetes i w konsekwencji mają dostęp do klastrów, uzyskiwanie kontroli nadal znajduje się w ramach bezpieczeństwa Kubernetes. Dostępność konsumenta jest ustalana przez przypisanie uprawnień do przestrzeni nazw wyróżniających się grup i członków grupy.
Jako przykład tego, jak DevSecOps i GitOps wyjątkowo sprzyjają innej osobie, Departament Obrony USA (DoD), Nicolas Chaillan, główny oficer oprogramowania komputerowego US Air Power, niedawno opisał, jak DevSecOps i GitOps — z Flux — odegraj istotną rolę w rozwoju swojego oprogramowania, które obsługuje całe spektrum sił bezpieczeństwa USA.
„Bezpieczeństwo i ochrona nie podlegają negocjacjom, ale chcemy również, aby firma deweloperska zwiększyła wydajność i szybkość” – powiedział Chaillan.
Na przykład GitOps jest „kluczem do naszych osiągnięć w tworzeniu i wdrażaniu Platform Just one przez cały DoD”, twierdzi DoD. Według DoD, System Just one to „asortyment dozwolonych, utwardzonych, zgodnych z Cloud Indigenous Computing Foundation (CNCF) dystrybucji Kubernetes, infrastruktury w postaci podręczników kodu i wzmocnionych kontenerów” z wbudowanymi potokami bezpieczeństwa.
czeki i salda
Procedury DevSecOps łączą się z kontrolami i bilansami dostaw GitOps. W ten sposób polecenie ułatwień dostępu, które daje, pomaga uniemożliwić programiście — lub intruzowi — dostęp do repozytorium kodu dostaw w celu wprowadzenia, na przykład, backdoora, zero-day lub jeszcze innej formy podatności na czas trwania CI procedura. Dzieje się tak po prostu dlatego, że wszystkie żądania ściągnięcia są recenzowane.
Dzięki DevSecOps wspierającemu system CI, kontrole i salda używane przed kodem są dedykowane na Git i wdrażane w klastrze. Deweloper zwykle publikuje modyfikację jako żądanie ściągnięcia, które jest recenzowane. Po sprawdzeniu i autoryzacji kod jest scalany w Git, a plik YAML żądanego stanu jest następnie odpowiednio zmieniany.
Żądany warunek zostanie natychmiast zastosowany do klastra Kubernetes. Jak wspomniano wcześniej, poprawny sprzęt GitOps z funkcjami DevSecOps stale śledzi dokładny stan w procesie celu, aby mieć pewność, że odwzajemnia się to, co zostało zadeklarowane w Git. W przypadku jakichkolwiek odchyleń generowany jest alert, aby można było podjąć ruch naprawczy.
DevSecOps uparty
Wiele instrumentów GitOps wspomaga DevSecOps. Open Supply Flux, na przykład, pomaga utrzymać repozytorium Git jako jedyne niezmienne źródło prawdziwej prawdy. Możliwości Fluxa wydłużają się również w zakresie regulacji dostępności dla kontroli i równowagi podczas CI/CD dla kodu, który jest dedykowany i wdrożony.
Aby uzyskać znacznie bardziej optymistyczne spotkanie Flux, Open Source Weave GitOps Main upraszcza pierwsze sposoby włączenia automatyzacji CI/CD w wielu klastrach. System umieszczania metody GitOps i DevSecOps z Weave GitOps Main obejmuje kilka nieskomplikowanych poleceń na konsoli.
Firma Weave GitOps pojawiła się jako pierwsza platforma GitOps, która automatyzuje stałą wysyłkę aplikacji i automatyczne zarządzanie operacyjne dla Kubernetes w dowolnej skali w architekturze chmury hybrydowej, wielochmurowej i brzegowej.
Wszystkie kilka narzędzi pomaga zautomatyzować monitorowanie, aby zagwarantować, że konfiguracja klastra zwykle odpowiada temu, co jest na Git, aby uniknąć dryfowania. Kompletna i dostępna ścieżka audytu pozwala na tworzenie cofnięć aplikacji i konfiguracji klastra na podstawowym fundamencie — bez konieczności przebudowywania klastra od zera.
Podsumowując, GitOps oznacza ewolucję DevOps dla rozproszonych środowisk Kubernetes, chociaż DevSecOps pojawił się jako ważny sposób na utrzymanie stabilności CI/CD dla GitOps przez cały cykl życia aplikacji.
Steve Waterworth jest kierownikiem ds. marketingu technicznego w firmie Weaveworks .