{"id":608,"date":"2021-02-01T07:31:00","date_gmt":"2021-02-01T07:31:00","guid":{"rendered":"https:\/\/oktawave.com\/blog\/?p=608"},"modified":"2022-11-14T15:07:55","modified_gmt":"2022-11-14T15:07:55","slug":"jak-skutecznie-podejsc-do-infrastructure-as-a-code","status":"publish","type":"post","link":"https:\/\/oktawave.com\/pl\/blog\/technologia\/jak-skutecznie-podejsc-do-infrastructure-as-a-code\/","title":{"rendered":"Jak skutecznie podej\u015b\u0107 do „infrastructure as a code”?"},"content":{"rendered":"\n

Spos\u00f3b zarz\u0105dzania infrastruktur\u0105 przez zespo\u0142y IT zmienia si\u0119 wraz z migracj\u0105 ca\u0142o\u015bci lub cz\u0119\u015bci \u015brodowisk do modelu chmurowego. Zamiast zamawia\u0107 i instalowa\u0107 sprz\u0119t, in\u017cynierowie wybieraj\u0105 opcje maszyn wirtualnych w panelu dostawcy i maszyny s\u0105 natychmiast tworzone. To samo dotyczy zwalniania zasob\u00f3w. Ale to nie wystarczy, kiedy infrastruktura i stos aplikacji szybko ewoluuj\u0105.<\/strong><\/p>\n\n\n\n\n\n\n\n

Wyzwania przed jakimi stoj\u0105 wsp\u00f3\u0142cze\u015bnie architekci i administratorzy infrastruktury IT w \u015brodowiskach chmurowych i hybrydowych s\u0105 determinowane przez wci\u0105\u017c te same oczekiwania biznesowe: wi\u0119cej, szybciej, taniej. Prze\u0142o\u017cy\u0107 te oczekiwania w pewnym uproszczeniu mo\u017cna na: wi\u0119cej funkcjonalno\u015bci aplikacji, cz\u0119\u015bciej dostarczanych i weryfikowanych (z rynkiem, klientami), przy zachowaniu koszt\u00f3w pod kontrol\u0105.<\/p>\n\n\n\n

Powoduje to, \u017ce oczekiwania stawiane przed liderami technologii w organizacjach przechodz\u0105 szybk\u0105 \u015bcie\u017ck\u0119 ewolucji. Gartner w swoich prognozach na 2021 rok wyr\u00f3\u017cnia 6 trend\u00f3w, kt\u00f3re maj\u0105 mie\u0107 kluczowy wp\u0142yw na obszar infrastruktury i operacji (I&O). W\u015br\u00f3d nich znalaz\u0142y si\u0119: optymalizacja infrastruktury, zachowanie ci\u0105g\u0142o\u015bci operacyjnej i zarz\u0105dzanie rozproszonymi operacjami.<\/p>\n\n\n\n

Zdaniem ekspert\u00f3w firmy badawczej, praca zdalna i przej\u015bcie do chmury b\u0119d\u0105 nadal g\u0142\u00f3wn\u0105 si\u0142\u0105 nap\u0119dow\u0105 w infrastrukturze w ci\u0105gu najbli\u017cszych 12 do 18 miesi\u0119cy. Do ko\u0144ca 2023 r. ponad 90 proc. departament\u00f3w I&O w organizacjach b\u0119dzie obs\u0142ugiwa\u0142o prac\u0119 zdaln\u0105 wi\u0119kszo\u015bci swoich pracownik\u00f3w. COVID-19 by\u0107 mo\u017ce przyspieszy\u0142 ten trend, ale jest to r\u00f3wnie\u017c rezultat zmieniaj\u0105cego si\u0119 charakteru infrastruktury, spowodowanego przej\u015bciem do chmury.<\/p>\n\n\n\n

\u2013 Trendy takie jak rozproszone operacje (anywhere operations) czy modernizacja podstawowej infrastruktury (core modernization) od lat wysuwaj\u0105 si\u0119 na czo\u0142o priorytet\u00f3w I&O w organizacjach, ale pandemia przyspieszy\u0142a je do tego stopnia, \u017ce w niedalekiej przysz\u0142o\u015bci b\u0119d\u0105 mia\u0142y wp\u0142yw transformacyjny \u2013 m\u00f3wi Jeffrey Hewitt, wiceprezes ds. bada\u0144, Gartner.<\/p>\n\n\n\n

Spos\u00f3b dostarczania i zarz\u0105dzania infrastruktur\u0105 w organizacjach czeka przyspieszona ewolucja, pozwalaj\u0105ca na skok efektywno\u015bci. Kluczow\u0105 role odegraj\u0105 tutaj tak wa\u017cne elementy kultury IT w firmie jak DevOps, ci\u0105g\u0142e dostarczanie (continuous delivery) oraz infrastruktura zarz\u0105dzana poprzez kod.<\/p>\n\n\n\n

INFRASTRUKTURA W KODZIE<\/h2>\n\n\n\n

Przez lata zarz\u0105dzanie jednym b\u0105d\u017a kilkoma serwerami by\u0142o prac\u0105 na pe\u0142ny etat. Administratorzy starannie opiekowali si\u0119 swoimi krytycznymi systemami i zapewniali sprawne funkcjonowanie firmy poprzez ich utrzymanie, aktualizacj\u0119 i zabezpieczenie.<\/p>\n\n\n\n

Ostatnie 10 lat zrewolucjonizowa\u0142o spos\u00f3b, w jaki przedsi\u0119biorstwa zarz\u0105dzaj\u0105 swoj\u0105 krytyczn\u0105 infrastruktur\u0105. Serwery nie s\u0105 ju\u017c czym\u015b, co trzyma si\u0119 w ciemnym, zimnym pomieszczeniu w piwnicy. Obecnie dostawcy us\u0142ug w chmurze zarz\u0105dzaj\u0105 krytyczn\u0105 infrastruktur\u0105 biznesow\u0105 dla setek, a nawet tysi\u0119cy klient\u00f3w, utrzymuj\u0105c rozleg\u0142e sieci centr\u00f3w danych.<\/p>\n\n\n\n

Rozw\u00f3j kolokacji, a przede wszystkim chmury \u2013 publicznej i prywatnej \u2013 zmieni\u0142 spos\u00f3b, w jaki in\u017cynierowie zarz\u0105dzaj\u0105 infrastruktur\u0105. Min\u0119\u0142y ju\u017c czasy, gdy administrator systemu by\u0142 odpowiedzialny za jeden czy kilka serwer\u00f3w. Obecnie \u2013 wspieraj\u0105c osi\u0105ganie krytycznych cel\u00f3w biznesowych \u2013 in\u017cynierowie operacji IT zarz\u0105dzaj\u0105 kilkudziesi\u0119cioma serwerami, a w najwi\u0119kszych organizacjach cz\u0119sto kilkuset.<\/p>\n\n\n\n

Ta zmiana skali zmienia r\u00f3wnie\u017c spos\u00f3b, w jaki specjali\u015bci I&O zapewniaj\u0105 prawid\u0142ow\u0105 konfiguracj\u0119 swoich system\u00f3w. Je\u015bli spotkali\u015bcie si\u0119 ju\u017c z w praktyce z metodykami zarz\u0105dzania \u015brodowiskami IT takimi jak DevOps czy SRE (Site Reliability Engineering), to infrastruktura zarz\u0105dzana poprzez kod jest podstaw\u0105 ich funkcjonowania, i jest wykorzystywana przez wszystkich cz\u0142onk\u00f3w zespo\u0142\u00f3w.<\/p>\n\n\n\n

Infrastructure as Code<\/em> (IaC) czyli infrastruktura jako kod<\/strong> to podej\u015bcie do zarz\u0105dzanie infrastruktur\u0105 (sieciami, maszynami wirtualnymi, systemami r\u00f3wnowa\u017cenia obci\u0105\u017cenia czy topologi\u0105 po\u0142\u0105cze\u0144 w chmurze wirtualnej) z wykorzystaniem modelu opisowego, przy u\u017cyciu tych samych narz\u0119dzi do kontroli wersji, kt\u00f3rych zesp\u00f3\u0142 DevOps u\u017cywa do zarz\u0105dzania kodem \u017ar\u00f3d\u0142owym aplikacji.<\/p>\n\n\n\n

Analogicznie do zasady, \u017ce ten sam kod \u017ar\u00f3d\u0142owy generuje ten sam kod binarny, model opisany w szablonie IaC generuje to samo \u015brodowisko za ka\u017cdym razem, gdy jest uruchamiany. Dzi\u0119ki temu, \u017ce pozwala administratorom system\u00f3w zautomatyzowa\u0107 proces tworzenia, uruchamiania i konfiguracji maszyny wirtualnej za pomoc\u0105 kodu, zapewnia szybk\u0105 i powtarzaln\u0105 procedur\u0119 replikowania ca\u0142ego procesu.<\/p>\n\n\n\n

Oznacza to, \u017ce np. po zbudowaniu \u015brodowiska wirtualnego z wykorzystaniem skryptu pozwalaj\u0105cego uruchomi\u0107 i przetestowa\u0107 aplikacj\u0119, nad kt\u00f3r\u0105 pracujemy, mo\u017cna powt\u00f3rzy\u0107 proces tworzenia wymaganego \u015brodowiska na etapie wdro\u017cenia, uruchamiaj\u0105c ten sam kod. W por\u00f3wnaniu z np. skryptami pow\u0142oki (r\u00f3wnie\u017c istotnym narz\u0119dziem automatyzacji proces\u00f3w IT), IaC oferuje wi\u0119ksz\u0105 elastyczno\u015b\u0107 dla bardziej z\u0142o\u017conych proces\u00f3w powo\u0142ywania infrastruktury.<\/p>\n\n\n\n

AUTOMATYZACJA I IDEMPOTENCJA<\/h2>\n\n\n\n

W wielu pozycjach literatury profesjonalnej podej\u015bcie IaC jest cz\u0119sto zaw\u0119\u017cane do aspektu automatyzacji, poniewa\u017c jego praktyki obejmuj\u0105 inteligentne wykorzystanie skrypt\u00f3w i szablon\u00f3w, pozwalaj\u0105cych na automatyzacj\u0119 proces\u00f3w manualnych. Jednak infrastruktura jako kod jest koncepcj\u0105, kt\u00f3ra zdecydowanie wykracza poza ramy prostej automatyzacji dostarczania infrastruktury i jest integraln\u0105 cz\u0119\u015bci\u0105 praktyk DevOps.<\/p>\n\n\n\n

Dzi\u0119ki konfiguracji infrastruktury jako kodu, mo\u017ce ona przej\u015b\u0107 przez t\u0119 sam\u0105 kontrol\u0119 wersji, zautomatyzowane testy oraz inne kroki procesu ci\u0105g\u0142ej integracji i ci\u0105g\u0142ego dostarczania (CI\/CD), wykorzystywanego przez developer\u00f3w do kontroli kodu aplikacji.<\/p>\n\n\n\n

Id\u0105c dalej, liderzy IT mog\u0105 zdecydowa\u0107 o po\u0142\u0105czeniu podej\u015bcia IaC z konteneryzacj\u0105 aplikacji, dzi\u0119ki czemu aplikacja zostaje odseparowana od infrastruktury na poziomie systemu operacyjnego. Obie technologie okazuj\u0105 si\u0119 komplementarne dla p\u0142ynnego zarz\u0105dzania r\u00f3\u017cnymi fazami wdro\u017ceniowymi od developmentu do produkcji. Zdaniem praktyk\u00f3w, zarz\u0105dzanie infrastruktur\u0105 poprzez kod oferuje wiele korzy\u015bci, nie tylko w por\u00f3wnaniu z manualnym tworzeniem i konfiguracj\u0105.<\/p>\n\n\n\n

Najwa\u017cniejsze korzy\u015bci zarz\u0105dzania infrastruktur\u0105 poprzez kod:<\/p>\n\n\n\n

    \n
  • Samoobs\u0142uga \u2013 poniewa\u017c infrastruktura jest zdefiniowana jako kod, ca\u0142y proces wdra\u017cania jest zautomatyzowany przez co mo\u017ce by\u0107 uruchamiany przez ka\u017cdego cz\u0142onka zespo\u0142u DevOps samodzielnie. U\u017cytkownicy otrzymuj\u0105 w rezultacie zasoby, kt\u00f3rych potrzebuj\u0105 i kiedy ich potrzebuj\u0105.<\/li>\n\n\n\n
  • Idempotencja (z ang. idempotency, t\u0142umaczone r\u00f3wnie\u017c jako idempotentno\u015b\u0107) \u2013 jedna z kluczowych cech podej\u015bcia IaC. Oznacza definiowanie po\u017c\u0105danego wyniku ko\u0144cowego \/ stanu docelowego infrastruktury. Wykonanie skryptu powoduje sprawdzenie stanu aktualnego, por\u00f3wnanie z docelowym i wykonanie operacji, kt\u00f3re s\u0105 niezb\u0119dne do osi\u0105gni\u0119cia zdefiniowanej konfiguracji infrastruktury. Niezale\u017cnie od tego, ile razy uruchomimy skrypt powo\u0142uj\u0105cy infrastruktur\u0119, rezultat b\u0119dzie zawsze ten sam. W przypadku skomplikowanych konfiguracji, osi\u0105gni\u0119cie analogicznego efektu (np. za pomoc\u0105 skrypt\u00f3w pow\u0142oki) mo\u017ce by\u0107 bardzo trudne, natomiast narz\u0119dzia takie jak Ansible czy Terraform maj\u0105 wbudowan\u0105 tak\u0105 funkcjonalno\u015b\u0107.<\/li>\n\n\n\n
  • Obni\u017cone koszty \u2013 skr\u00f3cenie czasu i nak\u0142adu pracy specjalist\u00f3w wymaganych do zapewnienia zdefiniowanej infrastruktury w por\u00f3wnaniu z procesem manualnym.<\/li>\n\n\n\n
  • Szybsze dostarczanie oprogramowania \u2013 szybkie, zautomatyzowane zapewnienie infrastruktury do rozwoju, testowania i wdra\u017cania aplikacji wp\u0142ywa na przyspieszenie procesu dostarczania oprogramowania. Poniewa\u017c proces wdra\u017cania jest zautomatyzowany, jest on r\u00f3wnie\u017c sp\u00f3jny i powtarzalny.<\/li>\n\n\n\n
  • \u0141atwa dokumentacja \u2013 stan infrastruktury jest okre\u015blony w kodzie szablonu i mo\u017ce mie\u0107 r\u00f3\u017cn\u0105 posta\u0107 w zale\u017cno\u015bci od narz\u0119dzia. Jednak z regu\u0142y jest to notacja analogiczna do pliku JSON, kt\u00f3ry jest \u0142atwy do odczytania przez ka\u017cdego cz\u0142onka zespo\u0142u czy wdra\u017caj\u0105cego si\u0119 specjalist\u0119. Kiedy skrypty opisuj\u0105 bardzo rozbudowan\u0105 infrastruktur\u0119 mo\u017ce zachodzi\u0107 konieczno\u015b\u0107 dodatkowego dokumentowania kodu, jednak s\u0142u\u017cy to lepszej orientacji i utrzymaniu kodu.<\/li>\n\n\n\n
  • Kontrola wersji \u2013 infrastruktura jako kod zmniejsza wysi\u0142ek i ryzyko zwi\u0105zane z wprowadzaniem zmian w infrastrukturze, poniewa\u017c mo\u017cna zastosowa\u0107 sprawdzone procesy i narz\u0119dzia zarz\u0105dzania kodem. Maj\u0105c pliki \u017ar\u00f3d\u0142owe umieszczone w kontroli wersji mo\u017cemy \u015bledzi\u0107 wszystkie zmiany dokonane w infrastrukturze i w wi\u0119kszo\u015bci wypadk\u00f3w powr\u00f3ci\u0107 do poprzedniej wersji.<\/li>\n\n\n\n
  • Walidacja i testowanie \u2013 infrastruktura jako kod umo\u017cliwia cz\u0119ste testowanie i stosowanie ma\u0142ych zmian. Poniewa\u017c mamy do czynienia z kodem, mo\u017cna sprawdza\u0107 b\u0142\u0119dy za pomoc\u0105 analizy statycznej i test\u00f3w automatycznych.<\/li>\n\n\n\n
  • Zwi\u0119kszone bezpiecze\u0144stwo \u2013 IaC umo\u017cliwia statyczna analiz\u0119 bezpiecze\u0144stwa i osadzenie zabezpiecze\u0144 od samego pocz\u0105tku (jako element procesu DevSecOps), oraz zarz\u0105dzanie zmianami przy zredukowanym ryzyku pojawienia si\u0119 luki w bezpiecze\u0144stwie.<\/li>\n<\/ul>\n\n\n\n

    R\u00d3\u017bNE NARZ\u0118DZIA DLA R\u00d3\u017bNYCH PODEJ\u015a\u0106<\/h2>\n\n\n\n

    Pomimo swoich jednoznacznych zalet IaC stwarza\u0107 mo\u017ce te\u017c wyzwania, kt\u00f3rym zesp\u00f3\u0142 DevOps musi stawi\u0107 czo\u0142a. Przede wszystkim wymaga stosowania narz\u0119dzi do zarz\u0105dzania konfiguracj\u0105 oraz zarz\u0105dzania orkiestracj\u0105, co stwarza potencjalnie przestrze\u0144 na b\u0142\u0119dy i powinno zosta\u0107 wsparte odpowiednimi kompetencjami zespo\u0142u. Nawet najmniejsze b\u0142\u0119dy mog\u0105 si\u0119 szybko rozprzestrzenia\u0107 szczeg\u00f3lnie tam, gdzie istnieje rozleg\u0142a automatyzacja infrastruktury. Z tego powodu niezb\u0119dna jest \u015bcis\u0142a kontrola wersji i przeprowadzanie kompleksowych test\u00f3w przed wydaniem.<\/p>\n\n\n\n

    Je\u015bli z kolei zdarzy si\u0119, \u017ce administratorzy zmieni\u0105 konfiguracj\u0119 serwera poza ustalonym szablonem IaC, istnieje zagro\u017cenie tzw. dryfu konfiguracji (configuration drift) poza zakres kontrolowany za pomoc\u0105 narz\u0119dzi do zarz\u0105dzania konfiguracjami. Wa\u017cne jest, aby w pe\u0142ni zintegrowa\u0107 podej\u015bcie IaC z administracj\u0105 system\u00f3w, operacjami IT i praktykami DevOps za pomoc\u0105 dobrze udokumentowanych polityk i procedur.<\/p>\n\n\n\n

    ORKIESTRACJA I KONFIGURACJA<\/h3>\n\n\n\n

    Narz\u0119dzia do zarz\u0105dzania konfiguracj\u0105 s\u0105 przeznaczone do administracji, zarz\u0105dzania u\u017cytkownikami, instalowania, aktualizacji i zarz\u0105dzania oprogramowaniem czy narz\u0119dziami na istniej\u0105cych serwerach. Do najcz\u0119\u015bciej u\u017cywanych narz\u0119dzi konfiguracyjnych nale\u017c\u0105 Chef, Puppet, Ansible i SaltStack.<\/p>\n\n\n\n

    Z kolei narz\u0119dzia takie jak Terraform, AWS CloudFormation, Azure Resource Manager (ARM) czy Google Cloud Deployment Manager s\u0142u\u017c\u0105 do orkiestracji infrastruktury, tzn. powo\u0142ywania instancji serwer\u00f3w, tworzenia baz danych, system\u00f3w r\u00f3wnowa\u017cenia obci\u0105\u017cenia, podsieci, firewalli i wszystkich innych element\u00f3w infrastruktury. Narz\u0119dzia te komunikuj\u0105 si\u0119 poprzez API dostawc\u00f3w.<\/p>\n\n\n\n

    Typow\u0105 praktyk\u0105 jest wykorzystanie dw\u00f3ch narz\u0119dzi dedykowanych do ka\u017cdego z zada\u0144. Na przyk\u0142ad, mo\u017cna wykorzysta\u0107 Terraform do powo\u0142ania infrastruktury VPC, podsieci, maszyn wirtualnych itp., a nast\u0119pnie u\u017cy\u0107 Ansible do konfiguracji i wdro\u017cenia us\u0142ug na utworzonych instancjach.<\/p>\n\n\n\n

    PODEJ\u015aCIE IMPERATYWNE A DEKLARATYWNE<\/h3>\n\n\n\n

    Deklaratywne podej\u015bcie do programowania nakre\u015bla po\u017c\u0105dany, zamierzony stan infrastruktury, ale nie wymienia wyra\u017anie krok\u00f3w prowadz\u0105cych do osi\u0105gni\u0119cia tego stanu. Przyk\u0142adem takiego podej\u015bcia s\u0105 szablony AWS CloudFormation napisane w\u0142a\u015bnie w modelu deklaratywnym. Do narz\u0119dzi deklaratywnych nale\u017c\u0105 r\u00f3wnie\u017c Terraform, Puppet czy SaltStack.<\/p>\n\n\n\n

    Natomiast podej\u015bcie imperatywne mo\u017cna por\u00f3wna\u0107 do dzia\u0142ania skrypt\u00f3w pow\u0142oki i polega na wykonaniu sekwencji polece\u0144, kt\u00f3re umo\u017cliwiaj\u0105 powo\u0142anie infrastruktury o za\u0142o\u017conych parametrach. Z narz\u0119dzi np. Chef czy Ansible mog\u0105 by\u0107 u\u017cywane w spos\u00f3b deklaratywny i imperatywny, w zale\u017cno\u015bci od potrzeb.<\/p>\n\n\n\n

    W obu podej\u015bciach kod powo\u0142uj\u0105cy infrastruktur\u0119 jest konfigurowany w szablonie, w kt\u00f3rym u\u017cytkownik okre\u015bla zasoby potrzebne dla ka\u017cdego serwera w infrastrukturze.<\/p>\n\n\n\n

    INFRASTRUKTURA ZMIENNA I NIEZMIENNA<\/h3>\n\n\n\n

    Infrastruktur\u0105 mo\u017cna zarz\u0105dza\u0107 dopuszczaj\u0105c zmiany jej konfiguracji po udost\u0119pnieniu b\u0105d\u017a zak\u0142adaj\u0105c jej niezmienno\u015b\u0107. W pierwszym przypadku wykorzystuje si\u0119 narz\u0119dzia automatyzacji jak Chef, Ansible, Puppet czy SaltStack, przeznaczone do instalacji i aktualizacji oprogramowania na istniej\u0105cych instancjach serwer\u00f3w czy innych element\u00f3w infrastruktury.<\/p>\n\n\n\n

    Konieczno\u015b\u0107 ingerencji w ich konfiguracj\u0119 mo\u017ce mie\u0107 miejsce wielokrotnie w ci\u0105gu ca\u0142ego cyklu u\u017cytkowania serwera prowadz\u0105c do r\u00f3\u017cnic pomi\u0119dzy serwerami powo\u0142ywanymi w poszczeg\u00f3lnych fazach projektu i powoduj\u0105c wspomniany ju\u017c wcze\u015bniej dryf konfiguracji. Nie zawsze prowadzi to do powa\u017cnych problem\u00f3w, zw\u0142aszcza je\u015bli zarz\u0105dzanie zmian\u0105 jest pod kontrol\u0105 narz\u0119dzi monitoruj\u0105cych. Jednak w skrajnych przypadkach mo\u017ce prowadzi\u0107 do sytuacji, kiedy np. aplikacja przetestowana w \u015brodowisku testowym nie uruchamia si\u0119 prawid\u0142owo na niekt\u00f3rych maszynach w \u015brodowisku produkcyjnym.<\/p>\n\n\n\n

    Alternatyw\u0105 jest podej\u015bcie oparte na koncepcji niezmienno\u015bci infrastruktury, przy wsparciu wspomnianych ju\u017c narz\u0119dzi takich jak Terraform czy AWS CloudFormation. Nowa instancja serwera z obrazu maszyny lub obrazu kontenera jest tworzona za ka\u017cdym razem, kiedy nast\u0119puje modyfikacja. Innymi s\u0142owy – je\u015bli instancje maszyn wymagaj\u0105 aktualizacji, zast\u0119pujemy je nowymi instancjami. Kiedy nowe maszyny s\u0105 gotowe, mo\u017cna wy\u0142\u0105czy\u0107 poprzednie instancje i uwolni\u0107 zasoby. Oczywi\u015bcie takie podej\u015bcie mo\u017ce mie\u0107 r\u00f3wnie\u017c swoje wady, np. kiedy modyfikacje maj\u0105 miejsce cz\u0119sto (codziennie), a infrastruktura obejmuje setki instancji \u2013 w\u00f3wczas powo\u0142ywanie i zwalnianie instancji b\u0119dzie czasoch\u0142onne.<\/p>\n\n\n\n

    DOBRE PRAKTYKI KODOWANIA INFRASTRUKTURY<\/h2>\n\n\n\n

    Wdra\u017canie i zarz\u0105dzanie infrastruktur\u0105 chmury poprzez IaC z wykorzystaniem takich narz\u0119dzi jak Terraform, AWS Cloud Formation czy Azure Resource Manager, umo\u017cliwia organizacji osi\u0105gni\u0119cie kolejnego etapu zwinno\u015bci (agility). Pozwala te\u017c na osadzenie zasad bezpiecze\u0144stwa we wcze\u015bniejszym etapie cyklu rozwoju aplikacji i ich weryfikacj\u0119 przed wdro\u017ceniem infrastruktury. Przyjrzyjmy si\u0119 typowym zagro\u017ceniom zwi\u0105zanym z IaC w praktyce – poni\u017cej wybrane, cho\u0107 nie jedyne, problemy i dobre praktyki pozwalaj\u0105ce ich unikn\u0105\u0107 b\u0105d\u017a zminimalizowa\u0107 skutki.<\/p>\n\n\n\n

    NAJWI\u0118KSZE WYZWANIA I REKOMENDACJE DLA IAC<\/h2>\n\n\n\n
    PROBLEM<\/td>NA CZYM POLEGA<\/td>ZALECENIA<\/td><\/tr>
    Udost\u0119pnianie kluczy w kodzie
    <\/td>    		 Zakodowane dane uwierzytelniaj\u0105ce to jedna z bardzo powszechnych praktyk. Polega na umieszczeniu w kodzie \u017ar\u00f3d\u0142owym danych uwierzytelniaj\u0105cych takich jak klucze SSH lub has\u0142a do kont, zwyk\u0142ym tekstem. Ryzyko jest bardzo powa\u017cne, od nieautoryzowanych uprawnie\u0144 po wyciek danych. Niestety, IaC u\u0142atwia stosowanie tej praktyki.
    Skanowanie kodu skrypt\u00f3w pod k\u0105tem zakodowanych kluczy przed ich uruchomieniem na infrastrukturze chmurowej. <\/td>    		 Skanowanie kodu skrypt\u00f3w pod k\u0105tem zakodowanych kluczy przed ich uruchomieniem na infrastrukturze chmurowej. <\/td><\/tr>
    Dryf konfiguracji
    <\/td>    		 Je\u015bli nag\u0142a sytuacja zmusza zesp\u00f3\u0142 operacji IT do zmiany konfiguracji w infrastrukturze chmury poza kodem skryptu \u0142amie tym samym zasad\u0119 niezmienno\u015bci infrastruktury po jej wdro\u017ceniu. Powoduje to ryzyko utraty integralno\u015bci infrastruktury i ewentualnych b\u0142\u0119d\u00f3w np. w dzia\u0142aniu aplikacji testowanych na innej konfiguracji. <\/td> Wprowadzanie zmian w infrastrukturze tylko poprzez skrypty IaC i wdro\u017cenie nowej konfiguracji z kodu. Monitorowanie r\u00f3\u017cnic mi\u0119dzy konfiguracj\u0105 infrastruktury a kodem szablonu IaC. <\/td><\/tr>
    Eskalacja uprawnie\u0144<\/td>IaC jest u\u017cywany do zapewnienia pe\u0142nych \u015brodowisk w chmurze tj. obejmuj\u0105cych r\u00f3wnie\u017c kontenery i mikrous\u0142ugi. Ryzyko tzw. eskalacji uprawnie\u0144 jest zwi\u0105zane z cz\u0119stym wykorzystywaniem przez in\u017cynier\u00f3w kont z uprawnieniami developerskimi do wdra\u017cania aplikacji w r\u00f3\u017cnych warstwach chmury.

    Je\u015bli towarzyszy\u0107 tej praktyce b\u0119dzie dodatkowo ww. przypadek umieszczenia danych uwierzytelniaj\u0105cych w kodzie to mamy powa\u017cne ryzyko ekspozycji na atak.<\/td>    		Stosowanie zasady najmniejszych uprawnie\u0144 na poziomie szablon\u00f3w IaC. Skanowanie kont i ich uprawnie\u0144 w celu wykrycia ewentualnych narusze\u0144 przed wdro\u017ceniem na produkcji.<\/td><\/tr>
    Wykrywanie podatno\u015bci<\/td>Szablony IaC s\u0105 u\u017cywane do wdra\u017cania instancji maszyn wirtualnych, instancji kontenerowych itp. poprzez wykorzystanie bazowych obraz\u00f3w przechowywanych w zaufanych repozytoriach. Wykorzystanie obrazu posiadaj\u0105cej niewykryt\u0105 luk\u0119 bezpiecze\u0144stwa stwarza ryzyko ekspozycji na atak. Nale\u017cy d\u0105\u017cy\u0107 do wczesnego wykrycia i usuni\u0119cia wszelkich znanych luk w takich obrazach bazowych.<\/td>Regularna analiza obraz\u00f3w wykorzystywanych w szablonach IaC pod k\u0105tem mo\u017cliwych i potwierdzonych podatno\u015bci.<\/td><\/tr>
    Zaginione zasoby<\/td>Zaginione zasoby Zasoby tworzone i konfigurowane przy u\u017cyciu IaC, ale nie skatalogowane i otagowane, powoduj\u0105 powstawanie zbioru zasob\u00f3w-widm. Te z kolei mog\u0105 powodowa\u0107 problemy w zakresie kontroli i widoczno\u015bci w produkcyjnym \u015brodowisku w chmurze. Mo\u017ce mie\u0107 to konsekwencje dla bezpiecze\u0144stwa, kontroli koszt\u00f3w czy efektywno\u015bci. Tagowanie i katalogowanie zasob\u00f3w chmurowych jest niezb\u0119dne do realizacji polityk zarz\u0105dczych (governance).<\/td>Tagowanie i katalogowanie zasob\u00f3w chmurowych jest niezb\u0119dne do realizacji polityk zarz\u0105dczych (governance).<\/td><\/tr>
    Naruszenie zasad zgodno\u015bci z regulacjami<\/td>Wiele organizacji korzystaj\u0105cych z infrastruktury chmury obliczeniowej jest zobowi\u0105zanych do przestrzegania regulacji bran\u017cowych jak GDPR, HIPAA, PCI DSS czy SOC2. Dlatego wa\u017cne jest posiadanie mechanizm\u00f3w egzekwowania polityki zapewnienia zgodno\u015bci na poziomie IaC. Przyk\u0142adem mo\u017ce by\u0107 SOC2, kt\u00f3ry wymaga istnienia zasad dotycz\u0105cych hase\u0142 IAM, pomini\u0119cie implementacji tej polityki na etapie IaC skutkowa\u0107 b\u0119dzie niezgodno\u015bci\u0105 wdro\u017conej infrastruktury z regulacjami.<\/td>Wdro\u017cenie polityki zapewnienia zgodno\u015bci oraz wykonanie test\u00f3w zgodno\u015bci szablon\u00f3w IaC na ka\u017cdym etapie wyda\u0144 (CI\/CD).<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Infrastruktura definiowana poprzez kod jest podej\u015bciem oferuj\u0105cym wiele korzy\u015bci w por\u00f3wnaniu z manualnym wdra\u017caniem i konfiguracj\u0105 \u2013 pozwala na wersjonowanie, testowanie, wspiera szybsze i cz\u0119stsze dostarczanie oprogramowania.<\/p>\n\n\n\n

    Wiele organizacji zacz\u0119\u0142o ju\u017c stosowa\u0107 podej\u015bcie IaC do budowy i zarz\u0105dzania swoj\u0105 infrastruktur\u0105. Maj\u0105c na uwadze, \u017ce IaC jest nie tyle samodzielnym z\u0142otym \u015brodkiem do osi\u0105gni\u0119cia business agility a integraln\u0105 cz\u0119\u015bci\u0105 DevOps i kultury ci\u0105g\u0142ego dostarczania (CD), warto zadba\u0107 o wsparcie do\u015bwiadczonego partnera. Takie, kt\u00f3re pozwoli szybciej przeby\u0107 etap od wdro\u017cenia do korzy\u015bci, jednocze\u015bnie daj\u0105c okazj\u0119 do r\u00f3wnoleg\u0142ej budowy kompetencji w zespole wewn\u0119trznym.<\/p>\n\n\n