OpenShift to uniwersalna platforma pozwalająca na uruchomienie każdej aplikacji na dowolnej infrastrukturze

Z Kirsten Newcomer, dyrektor zespołu odpowiedzialnego za rozwój platformy OpenShift i rozwiązań bezpieczeństwa w firmie Red Hat rozmawiamy o zmieniających się procesach wytwarzania oprogramowania, nowych technologiach i architekturach oraz wyzwaniach związanych z wykorzystywaniem konteneryzacji. Omawiamy także możliwości platformy OpenShift, potrzeby zaostrzenia kontroli nad łańcuchami dostaw aplikacji oraz rolę firmy Red Hat w kontekście wyzwań biznesowych związanych z tworzeniem i użytkowaniem oprogramowania.

Jest Pani związana z branżą IT od przeszło 30 lat. Jak na przestrzeni tego czasu zmieniło się podejście do tworzenia oprogramowania?

To prawda, mam okazję z bliska obserwować rozwój branży od dłuższego czasu. Myślę, że jedną z największych zmian, jakie w ostatnich latach wpłynęły na rozwój oprogramowania było upowszechnienie się podejścia zwinnego. Faktem jest, że metody zwinne łatwiej jest wdrożyć w projektach o mniejszej skali, a trudniej w tych bardziej rozbudowanych. Nie zmienia to faktu, że ewolucja w tym kierunku postępuje. Nie jest to jednak rozwój tylko w jednym kierunku.

Dobrym przykładem jest koncepcja DevOps, która jest jedną z możliwych opcji rozszerzenia podejścia Agile, zorientowana na zacieśnienie współpracy między zespołem deweloperów, a działami odpowiedzialnymi za bieżące funkcjonowanie środowisk IT. Pełne wdrożenie tej koncepcji nie jest łatwe. Paradoksalnie najtrudniejsze staje się zbudowanie faktycznej pętli zależności i komunikacji pomiędzy zespołami Dev i Ops.

Dlaczego?

Z prozaicznych powodów. Przede wszystkim w większych przedsiębiorstwach nadal funkcjonują struktury silosowe. Wychodzę z założenia, że metodyk i innych koncepcji nigdy nie należy wdrażać nie zważając na specyfikę czy uwarunkowania danej organizacji. Trzeba dostosowywać metody do okoliczności. Uważam jednak, że nie da się uzyskać korzyści oczekiwanych od podejścia DevOps bez faktycznego zbudowania procesu ciągłej interakcji pomiędzy zaangażowanymi zespołami.

Nie jest to łatwe, zwłaszcza w tych firmach, w których kwestie rozwoju aplikacji, operacji IT i bezpieczeństwa pozostawały domenami odrębnych zespołów. Dotychczas sprawowały one pełną kontrolę nad swoimi królestwami w ściśle zdefiniowanych granicach. W takich organizacjach zmiana status quo, przełamanie przyzwyczajeń i zbudowanie wzajemnego zrozumienia pomiędzy zespołami stanowią największe wyzwanie na drodze do implementacji DevOps. Jestem jednak przekonana, że warto ten wysiłek podjąć, aby stworzyć jeden, całościowy i działający w efektywny sposób zespół – zdolny do współdziałania i dzielenia się wiedzą.

Jakie, początkowo niedoceniane, aspekty procesu wytwarzania oprogramowania stały się dziś kluczowe?

W pierwszej kolejności wymieniłabym tu zmianę w podejściu do kwestii szeroko rozumianego bezpieczeństwa. Nie chodzi o to, że kiedyś programiści nie przywiązywali wagi do tworzenia bardziej bezpiecznego kodu. Pamiętajmy, że nie tak dawno realia i faktyczne potrzeby w tym zakresie były zupełnie inne niż dziś. W nieodległej przeszłości zdecydowana większość aplikacji funkcjonowała w ramach lokalnych, centralnie zabezpieczonych środowisk IT. Istniało zatem powszechne przekonanie, że skoro aplikacje działają w lokalnych, odizolowanych w dużej mierze od świata zewnętrznego środowiskach, to troska o podstawową poprawność kodu aplikacyjnego wystarczy, aby zminimalizować ewentualne ryzyka.

Dzisiejsze realia są zupełnie odmienne. Środowiska IT są otwarte na świat i mocno zróżnicowane. Upowszechniła się praca zdalna i koncepcja chmury obliczeniowej. Z drugiej strony pojawiły się też nowe zagrożenia, jak choćby ransomware, a wiedza o lukach i podatnościach konkretnych aplikacji stała się powszechna. W tej sytuacji naturalna jest potrzeba ograniczenia zaufania do użytkowników, źródeł danych czy interfejsów integracyjnych. Jednocześnie, istnieje szereg wyzwań związanych z wdrożeniem koncepcji zero-trust na poziomie poszczególnych aplikacji. Kluczowe jest zapewnienie odpowiednich zabezpieczeń na wszystkich miejscach styku ze światem.  Zarówno na poziomie konkretnej aplikacji, jak i całego stosu technologicznego, na którym jest ona posadowiona.

Jeśli zaś chodzi o kwestie, które w przeszłości były niedoceniane, to zwróciłabym uwagę na potrzebę standaryzacji i uporządkowania procesu budowania aplikacji jako całości. Oczywiście, istnieje szereg świetnych narzędzi CI/CD, jak Jenkins, CircleCl czy Tekton, ale nie zawsze są one wykorzystywane jako element szerszego, uporządkowanego procesu. Staramy się, jako Red Hat, wspierać programistów w przestrzeganiu pewnych standardów i dobrych praktyk, które są istotne pod kątem bezpieczeństwa, stabilności czy skalowalności aplikacji.

Największe znaczenie ma jednak zapewnienie współpracy i dobrego przepływu informacji pomiędzy wszystkimi zaangażowanymi zespołami. Pamiętam przykład jednej z firm, która – po przejściu na architekturą kontenerową i platformę Kubernetes użytkowaną w chmurze publicznej – zdecydowała się na wdrożenie koncepcji DevSecOps na potrzeby zwiększenia bezpieczeństwa aplikacji. Na etapie przygotowania tej zmiany, szef zespołu cyberbezpieczeństwa i wiceprezesi odpowiedzialni za rozwój aplikacji oraz kwestie operacyjne rozpoczęli dialog zmierzający do wyznaczenia najważniejszych scenariuszy, które powinny być zaadresowane. Dialog ten przyczynił się do większego zrozumienia specyfiki pracy, potrzeb i zadań stojących przed każdym z zespołów. Przykładowo, CSO zdecydował, że jego zespół musi rozumieć charakterystykę procesu CI/CD.

Jakie zmiany na poziomie architektury aplikacji uważa Pani za kluczowe?

Jedną taką zmianą dla zespołów zajmujących się infrastrukturą jest wirtualizacja. Jestem w branży wystarczająco długo, aby pamiętać jak dużą zmianą było wprowadzenie wirtualizacji. Był to ogromny krok naprzód pod względem lepszego i bardziej elastycznego wykorzystania możliwości zasobów sprzętowych. Znam dobrze historię rozwoju tej koncepcji i technologii, ponieważ mój przyjaciel dołączył do zespołu VMware w czasach, kiedy był to startup. Potem pojawiły się kontenery. Konteneryzacja dość szybko upowszechniła się wśród deweloperów, ponieważ zapewniła im większą kontrolę nad całym środowiskiem. Na poziomie infrastruktury cenna okazała się możliwość jeszcze bardziej precyzyjnego gospodarowania zasobami. Nie zmienia to jednak faktu, że były to raczej zmiany ewolucyjne niż rewolucyjne. W aplikacje oparte na architekturze trójwarstwowej inwestowano na tyle długo, że ich przeniesienie do środowiska kontenerowego naprawdę nie jest trywialne.

Łatwe nie jest też efektywne zarządzanie środowiskami kontenerowymi. Moim zdaniem wiele organizacji powinno pochylić się nad problemem orkiestracji kontenerów. Rewolucyjne zmiany w tym kontekście przyniosła platforma Kubernetes. Zapewnia bowiem możliwość prawdziwego zarządzania infrastrukturą za pośrednictwem kodu aplikacyjnego i zautomatyzowaną skalowalność środowiska. Oferuje też programistom cały zestaw narzędzi ogromnie ułatwiających tworzenie, uruchamianie i rozwijanie nowoczesnych aplikacji, które przecież ulegają coraz szybszym zmianom.

Czy to już ten moment, kiedy niezbędne staje się całościowe zarządzanie cyklem życia aplikacji kontenerowych?

Zdecydowanie! Uporządkowane i całościowe spojrzenie na funkcjonowanie aplikacji, ale też tworzących je kontenerów, jest niezbędne ze względu na skalę, dynamikę i złożoność. Mówiąc jednak o cyklu życia aplikacji zwróciłabym uwagę na dwa aspekty. Pierwszy z nich to sama platforma służąca do uruchamiania skonteneryzowanych aplikacji, drugi – cykl życia samych kontenerów jako fragmentów jednej aplikacji. Oba te obszary muszą być właściwie zaadresowane i precyzyjnie zarządzane.

Możliwość zarządzania całym cyklem życia aplikacji ma znaczenie m.in. w kontekście aktualnych wyzwań z zakresu cyberbezpieczeństwa. Pozwala bowiem na realną ocenę ryzyka i właściwe zaadresowanie wykrywanych zagrożeń na wszystkich warstwach działania aplikacji. W tym samym kontekście duże znaczenie ma też precyzyjne zarządzanie cyklem życia poszczególnych kontenerów. Niezbędna jest też automatyzacja, która pozwala nadążyć za zmianami zachodzącymi w środowisku aplikacyjnym.

Jakie możliwości zapewnia w tym kontekście Kubernetes?

Kubernetes dostarcza dziś zestaw narzędzi niezbędnych do efektywnego zarządzania aplikacjami i kontenerami w całym cyklu ich funkcjonowania w sposób zautomatyzowany. W tym kontekście potrzebne jest nie tylko monitorowanie i rejestrowanie działania kontenerów, ale też całościowa obsługa stosu sieciowego oraz zapewnienie dobrej integracji i współpracy tych obszarów.

Jak wiadomo, Kubernetes początkowo koncentrował się głównie na aplikacjach mikrousługowych, później pojawiła się obsługa kontenerów, a ostatnio – aplikacji stanowych. Wraz z wprowadzeniem funkcjonalności KubeVirt bezpośrednio w środowisku Kubernetes doszła możliwość uruchamiania maszyn wirtualnych na tej samej platformie, co aplikacji kontenerowych. Obecnie rozwijane są też nowe rozwiązania odpowiadające na specyficzne potrzeby aplikacji wykorzystujących sztuczną inteligencję. Kubernetes jest zatem dość złożoną i wszechstronną platformą.

Czym jest zatem OpenShift – i jaką rolę pełni?

Red Hat OpenShift to certyfikowane przez CNCF (Cloud Native Computing Foundation), oparte na platformie Kubernetes i rozszerzone o dodatkowe rozwiązania open source, kompletne środowisko aplikacyjne. Innymi słowy, jest to – oferowana na zasadach komercyjnych i z całościowym wsparciem – uniwersalna platforma pozwalająca na uruchomienie niemal każdej nowoczesnej aplikacji, w tym aplikacji stanowych i bezstanowych, aplikacji AI, a nawet maszyn wirtualnych, w sposób lokalny, na rozwiązaniach bare metal, w chmurze publicznej, czy w modelu edge computing.

Uniwersalność platformy OpenShift jest istotna z wielu powodów. Jednym z nich jest możliwość bardzo łatwego przenoszenia aplikacji pomiędzy różnymi środowiskami, niekoniecznie w ramach jednej infrastruktury. OpenShift zapewnia zatem warstwę abstrakcji, która ma kluczowe znaczenie dla projektów modernizacji i migracji środowisk aplikacyjnych, także w kontekście regulacji, takich jak DORA.

Jakie znaczenie praktyczne ma możliwość przenoszenia aplikacji między różnymi środowiskami?

Istnieje wiele powodów, dla których organizacje decydują się na zmianę środowiska lub całego stosu stojącego za działaniem poszczególnych aplikacji. Nierzadko jest to kwestia kosztów lub dostępności wyspecjalizowanych zasobów. Przykładowo chęć używania aplikacji korzystających z AI może oznaczać konieczność zastosowania dedykowanych układów GPU, a te nie są łatwo dostępne na rynku. Ich możliwości można jednak stosunkowo łatwo wykorzystać w formie usług oferowanych przez czołowych dostawców publicznej chmury obliczeniowej. Z drugiej strony, jeśli firma korzystająca dotąd z usług chmurowych jednego dostawcy zaczyna obserwować gwałtowny wzrost kosztów, może zdecydować o przeniesieniu obciążeń do innej platformy chmurowej lub do środowiska lokalnego. Jeszcze inny scenariusz to konieczność przeniesienia aplikacji i danych do konkretnego regionu świata, przykładowo, do Europejskiego Obszaru Gospodarczego. Zastosowanie wszechstronnej platformy, takiej jak Red Hat OpenShift zapewnia zdolność adaptacji i zwinność.

Co wyróżnia OpenShift dla tle alternatywnych platform?

Platforma Red Hat OpenShift została zaprojektowana pod kątem pełnego wsparcia dla wielodostępności, kompleksowej izolacji środowisk i bezpieczeństwa. Co więcej, OpenShift korzysta z mechanizmów wbudowanych w system Red Hat Enterprise Linux (RHEL), aby zapewnić jeszcze mocniejsze funkcje zabezpieczeń. Wykorzystanie RHEL jako fundamentu dla działania OpenShift z rozszerzeniami bezpieczeństwa (Security-Enhanced Linux, SELinux) aktywnymi w trybie wymuszania oznacza, że nawet w przypadku ucieczki procesu z kontenera, dostęp do hosta bazowego będzie uniemożliwiony lub ograniczony. Nasze rozwiązanie dobrze wpisuje się też w potrzeby środowisk opartych na wielu klastrach. Obserwujemy bowiem, że nasi klienci przechodzą ze środowisk opartych na niewielkiej liczbie dużych klastrów z wieloma użytkownikami do większej liczby mniejszych klastrów, w części wielodostępnych. Z tego powodu zainwestowaliśmy w rozwiązania do zarządzania wieloma klastrami i bezpieczeństwem, takie jak Red Hat Advanced Cluster Management oraz Red Hat Advanced Cluster Security. Idąc dalej, OpenShift zapewnia też rozbudowane możliwości kontroli ruchu sieciowego w klastrze i pomiędzy klastrami. Oferuje też dodatkową, dedykowaną dla maszyn wirtualnych, warstwę zabezpieczeń na poziomie sieci. Charakterystyka platformy OpenShift sprawia, że jest to rozwiązanie dobrze dopasowane do specyfiki środowisk korporacyjnych.

Platforma OpenShift może być też uruchomiona w środowiskach publicznej chmury obliczeniowej, choć dysponują one własnymi rozwiązaniami kontenerowymi. Dlaczego zatem warto rozważyć wykorzystanie tam OpenShift?

Kluczową przewagą platformy OpenShift jest tu wspomniana kompletność i wszechstronność, które przekładają się na łatwość przenoszenia aplikacji. Z perspektywy klientów takie podejście oznacza swobodę w działaniu. Jeśli dana organizacja chce korzystać z chmury publicznej, ale oczekuje sposobu na sprawną migrację aplikacji do innego środowiska lub do infrastruktury lokalnej, to ma taką możliwość z OpenShift. Na to nakładają się też rozbudowane funkcje służące do zapewnienia zgodności z regulacjami.

Platforma OpenShift jest dostępna także w ramach środowisk Amazon Web Services oraz Microsoft Azure. To świadczy o rynkowym znaczeniu naszego rozwiązania i stwarza nowe możliwości dla klientów.

Wróćmy do kwestii związanych z cyberbezpieczeństwem. Coraz częściej mówi się o konieczności zabezpieczenia całego łańcucha dostaw oprogramowania…

O tak! Prawdopodobnie jednym z najbardziej znanych i znaczących w skutkach przykładów naruszenia bezpieczeństwa łańcucha dostaw oprogramowania jest cykl zdarzeń, które dotknęły firmę SolarWinds, a następnie jej klientów. Kluczowe znaczenie miał fakt wprowadzenia aplikacji szpiegującej do łańcucha dostaw oprogramowania SolarWinds, która następnie została rozdystrybuowana w formie aktualizacji wśród szerokiej grupy organizacji. Skala skutków tego naruszenia doprowadziła do powstania szeregu uniwersalnych zaleceń w obszarze bezpieczeństwa oprogramowania na poziomie potoku aplikacji.

Przykładowo, organizacja SLSA.dev, którą staramy się wspierać, stworzyła zestaw wytycznych dotyczących bezpieczeństwa łańcucha dostaw i ustanowionych w drodze konsensusu branżowego. Wytyczne te obejmują szereg kwestii – od tych relatywnie prostych, do najbardziej złożonych. Jako przykład można tu podać zapewnienie ścisłej kontroli dostępu do kodu źródłowego, wersjonowania i podpisywania treści, a nawet organizacji pracy nad oprogramowaniem. Dodam, że w tym kontekście przydają się także narzędzia, takie jak Tekton czy OpenShift Pipelines. Pozwalają one bowiem na uporządkowanie strumienia prac deweloperskich oraz rozbicie ich na kroki, które mogą być ściśle monitorowane i audytowane. Z kolei narzędzie rozwijane w ramach projektu Sigstore zapewnia funkcje podpisywania komponentów wykorzystywanych w aplikacji – od plików po kontenery.

Jakiego znaczenia w kontekście bezpieczeństwa aplikacji nabiera dziś sztuczna inteligencja? Czy jest ona raczej źródłem problemów, czy bardziej ich rozwiązaniem?

Myślę, że jest zarówno źródłem nowych wyzwań, jak i ich rozwiązaniem. Przykładowo, sztuczna inteligencja zapewnia nowe możliwości szybkiego reagowania, wykrywania problemów zanim dojdzie do faktycznego naruszenia bezpieczeństwa w wielu obszarach działania aplikacji – i niekiedy neutralizowania ich w sposób skuteczny, nawet przy działaniach o dużej skali. AI umożliwia też sprawne korelowanie danych konfiguracyjnych i zdarzeniowych z danymi historycznymi w celu proaktywnego przeciwdziałania ewentualnym ryzykom. Od lat rozwijamy na przykład usługę Red Hat Insights, która pozwala m.in. zautomatyzować analizę wzorców konfiguracji, ich rozpoznawania i sugerowania działań pozwalających przeciwdziałać potencjalnym problemom. W tym kontekście AI staje się naprawdę praktycznym rozwiązaniem. Pozwala bowiem administratorom IT reagować jeszcze zanim dojdzie do faktycznego naruszenia bezpieczeństwa.

AI pomaga także w bardziej trafnym określaniu priorytetów działania wobec wykrytych luk w zabezpieczeniach. Jest to ważne, ponieważ, przykładowo, w pierwszej kolejności warto załatać luki bezpieczeństwa posiadające znane exploity i wykryte w aplikacjach narażonych na ataki spoza organizacji. Z drugiej strony, niestety, sztuczna inteligencja jest wykorzystywana w analogiczny sposób przez cyberprzestępców. Pozwala podejmować działania o dużej skali nawet osobom bez kompetencji deweloperskich. Jest to zatem, w pewnym sensie, wyścig dobra ze złem.

W jaki sposób można podsumować rolę firmy Red Hat w kontekście dzisiejszych potrzeb świata aplikacyjnego?

Firma Red Hat zawsze wspierała organizacje różnego rodzaju w działaniach mających na celu tworzenie lepszych, bardziej nowoczesnych i bezpieczniejszych aplikacji dopasowanych do potrzeb użytkowników. To z kolei przekłada się na konkretne inicjatywy wspierające modernizację aplikacji i wykorzystanie nowych technologii, koncepcji i architektur. Od początku działamy w ścisłej współpracy ze społecznością open source i jesteśmy przekonani o wartości takiego podejścia. Dobrym przykładem jest tu wspomniana już sztuczna inteligencja. Inwestujemy znaczne środki w działania społeczności po to, aby wspierać rozwój otwartych modeli AI, które można wykorzystać we własnym środowisku, wnikliwie poznać, a następnie dotrenować na własnych danych bez konieczności wiązania się z jakimkolwiek zamkniętym i potencjalnie trudnym do zrozumienia rozwiązaniem. Dążenie do otwartości jest kluczową wartością we wszystkich obszarach naszej działalności.