Red Hat, OpenShift i bezpieczeństwo. Kiedy proste staje się zbyt proste?

Często pod artykułami o nowych wersjach systemu Windows padają argumenty, że jego rozwój jest w zasadzie zbędny, a wszystko co potrzebne, wymyślono ponad dekadę temu. Z podobnymi opiniami można się spoktać w dyskusjach na tematy linuksowe (system obrasta w zbędne warstwy, a freedesktop.org to imperium zła) oraz chmurowe (serverless, Kubernetes i konterneryzacja to przesada, wystarczą zwykłe maszyny wirtualne). Każde nowe API i warstwa abstrakcji dodaje tylko zbędnej złożoności, rozleniwia programistów, zmniejsza bezpieczeństwo i generuje rynek na "ekspertów" od przejściowo modnych rozwiązań.

Sam od czasu do czasu ulegam takim poglądom. Martwią mnie rozbudowane ścieżki wdrażania i duży okład infrastrukturalny. Jaki jest kontrargument na tak postawioną sprawę? W odpowiedzi na to pytanie pomógł mi Brian Gracely, dyrektor strategiczny projektu OpenShift w Red Hacie. Oto odmienny punkt widzenia na owe zagadnienia.

*Kamil Dudek, dobreprogramy: W jaki sposób najłatwiej obronić się przed zarzutem zbędnego wzrostu złożoności i wytłumaczyć zjawisko rozbudowy warstw abstrakcji przez takie rozwiązania jak OpenShift, oddalające nas od systemu operacyjnego? Dlaczego po prostu nie używać samych maszyn wirtualnych? OpenShift jest wszak warstwą "nad" systemami operacyjnymi wdrożonymi w środowisku chmurowym. Dodaje to złożoności, dodatkowe warstwy wymagają opieki, skąd przekonanie, że sumaryczny poziom bezpieczeństwa jest wystarczający? *

Brian Gracely, Red Hat: Żeby odpowiedzieć na to pytanie rzetelnie, musimy umieścić je w odpowiednim kontekście. To znaczy, jeżeli bezpieczeństwo jest kluczową i niemal jedyną rzeczą, która nas interesuje podczas wdrożenia, to musimy pamiętać, że "bezpieczne" systemy nie są bezpieczne przez cały swój cykl życia. Ponieważ świat się zmienia, a nowe podatności są wciąż odkrywane, konieczne jest znalezienie balansu między nowymi funkcjami, bezpieczeństwem a szybkimi aktualizacjami. Te cechy są potrzebami biznesowymi, na które trzeba odpowiadać. Nowe warstwy adresują ten problem, a nie tylko dodają złożoność .

**K. D.: Zatem jeżeli nawet zastosujemy mniej warstw, zwiększamy zakres odpowiedzialności wdrożeniowców. Czy w domyśle oznacza to, że użycie starego podejścia również skutkowałoby wzrostem złożoności, ale na innym polu?B. G.: Postaram się przedstawić, w jaki sposób zdecydowaliśmy się podejść do tego zagadnienia w platformie OpenShift u jej zarania. Było to w okolicach roku 2012. Wtedy powszechnie stosowano wirtualne maszyny, a np. Azure nie istniał. Chmura publiczna zaczęła osiągać swoją popularność, ponieważ środowiska dotychczas wymagające zestawienia i zarządzania przez zespoły IT stawały się dostępne na wyciągnięcie ręki u dostawców infrastruktury.

Z perspektywy programistów tworzących oprogramowanie, sprawa wyglądała tak, że oni w zasadzie też nie chcieli maszyn wirtualnych, a jedynie zamkniętego, podlegającego kontroli środowiska do uruchamiania i testowania swoich aplikacji.

Odbiorcy oczekiwali zatem godnej zaufania platformy, dostarczanej jako usługa. Nie chcieli się przejmować kwestią obsługi sieci, bezpieczeństwem i tak dalej, ale nie dlatego, że były to dla nich kwestie w jakiś sposób nieważne. Zatem musieliśmy się tym zająć za nich.

Nauczyliśmy się dzięki temu, że uruchamianie kompletnych maszyn wirtualnych tylko po to, by oferować PaaS, było to obliczeniowo drogie i ciężkie. Stąd pojawiły się kontenery, większość dostawców zaczęło je stosować. Nie były to nowe warstwy dodawane z powodu mody i chęci dostarczenia łatwości za wszelką cenę, bez względu na koszt.

Te dodatkowe warstwy stały się zatem metodą dostarczania bezpiecznych ustawień domyślnych. Oferowanie ludziom mniejszej liczby wyborów pozwala im się nie zajmować rzeczami, które w ich rękach stałyby się w konsekwencji mniej bezpieczne.

K. D.: Platforma jako usługa zmniejsza wobec tego wymaganie, by twórca oprogramowania był odpowiedzialny za bezpieczeństwo i opiekę nad całym stosem technologicznym. Czy oznacza to zatem, że to nieprawda, że wszystkie nowe warstwy abstrakcji to tylko samonapędzający się biznes? Czy może jednak wymusza to kształcenie kolejnych fachowców od zbędnej acz powszechnej metodyki? Pół żartem-pół serio mawia się tak dziś na przykład o IPv6 i nowych frameworkach JavaScriptu.

B. G.: Zawsze ktoś będzie uważał, że nowe produkty są tworzone tylko po to, by definiować branżę modnych ekspertów. Z tym, że pogląd o którym mowa wziął się skądinąd. To efekt własnościowych rozwiązań przed dekady-dwóch, które kupione raz wymagały brnięcia w kapitał intelektualny, kształcąc inżynierów "tylko od" dedykowanych produktów. Dziś zwiększył się nacisk na przenośność między platformami. Dlatego tyle współpracujemy z open source. Więc istotnie nie zgadzam się z poglądem, że OpenShift powstał by nakręcić popyt na inżynierów OpenShifta.

Opisywany model wdrażania może się nieco kłócić z charakterystyką systemów specjalnego przeznaczenia, jak krytyczna infrastruktura dla systemów łączności lub sterowania. Czy nowe mechanizmy szyfrowania i zgodności z FIPS zostały wprowadzone po to, by spróbować zaoferować OpenShifta i w takich scenariuszach, czy może powody tej rozbudowy są inne?

Powyższe funkcje są oczywiście dostępne dla każdego. Każdy, kto ma wewnętrzne regulacje lub oczekiwania, może z nich skorzystać, nie istnieje wymagany przepis wdrożenia, bez którego nie działają. Nie trzeba być armią. Ale właśnie na przykład sektor rządowy będzie oczekiwać takich funkcji wprost.

Jeżeli natomiast chodzi o telekomunikację, pojawiają się przykłady, gdzie chmurowe wdrożenie jest niemożliwe, a infrastruktura pozwala na użycie zredukowanej ilości sprzętu. Nie da się zastosować wytycznych dobrych praktyk, mówiących że potrzebne jest kilka węzłów oraz spory narzut sprzętowy, by zapewnić bezbolesne skalowanie. Jak się pomieścić w czymś takim? Staramy się wtedy adaptować rozwiązania tak, by spełnić wymagania konkretnej specyfiki.

Dużo osób nas pyta "czym się różni Kubernetes od OpenShifta?". Tłumaczymy wtedy, że Kubernetes nie zawiera systemu, domyślnej konfiguracji sieci i wielu innych rzeczy, które dalej trzeba samemu dostarczyć.

K. D.: Na koniec nawiążmy do flagowego przykładu ciężkich, monolitycznych wdrożeń odpornych na chmurę: scentralizowane zarządzanie tożsamością - czy jest skazane na wymarcie? Czy stare monolity zostaną zastąpione przez wdrożenia typu OpenShifta?

B. G.: To jest ponadczasowe pytanie. Dużo osób ma tendencje do binarnego patrzenia na rzeczywistość i chciałoby prostej recepty i odpowiedzi, że "nowa rzecz" jest lepsza, przez co można się w całości pozbyć starej, żeby było lżej. Stąd zagadnienie "kontenery vs maszyny wirtualne" bywa rozpatrywane jako "nie potrzebuję maszyn wirtualnych, użyję kontenerów". Często potem pada "kontenerów też nie potrzebuję, pójdę w serverless" i tak dalej. Nie da się na takie pytania jednoznaczne odpowiedzieć.

Zawsze trzeba patrzeć na potrzeby i na budżet. Migracja na OpenShifta ma zdjąć obciążenie starymi rozwiązaniami, z którymi nie da się iść do przodu, a nie zastąpić wszystko, co dawne.

K. D.: Dziękuję za rozmowę.

Zwrócono tu uwagę na istotną kwestię, jaką jest czynnik ludzki. Zapotrzebowanie na złożone systemy informatyczne przekracza możliwości kadrowe, związane z zatrudnianiem administratorów-wdrożeniowców. Nie tylko jest ich za mało, ale także nie wszędzie są "zakontraktowani". W konsekwencji, opieka nad prostszymi strukturalnie, acz trudniejszymi w konserwacji środowiskami, skutkuje obniżeniem bezpieczeństwa. Przy takich kadrach, teoretycznie bardziej złożone narzędzia, efektywnie stają się bezpieczniejsze.

Naturalnie, Red Hat jest bardzo dumny ze swoich rozwiązań. Trudno oczekiwać prezentacji produktu w postaci nieprzefiltrowanej marketingową optykę. Pada tu jednak rzeczowy argument dotyczący ukrytych kosztów utrzymywania infrastruktury. Czy Red Hat jest w owej kwestii przekonujący? Dajcie nam znać w komentarzach.