Zabezpiecz swój łańcuch dostaw obrazów kontenerów
Jak zabezpieczyć swój łańcuch dostaw oprogramowania?
Zabezpieczenie łańcucha dostaw oprogramowania oznacza kontrolowanie każdego artefaktu pomiędzy zatwierdzeniem kodu a produkcją. W potokach kontenerowych sprowadza się to do czterech kontroli: prywatnego rejestru z RBAC, skanowania CVE, podpisywania kryptograficznego oraz polityki blokującej niepodpisane lub podatne obrazy podczas wdrażania.
Dlaczego ataki na łańcuch dostaw celują teraz w twoje obrazy kontenerów
SolarWinds, Log4Shell, xz-utils: potok budowania to nowy obwód bezpieczeństwa
Najpoważniejsze incydenty bezpieczeństwa oprogramowania ostatnich lat nie zaczęły się od naruszenia zapory sieciowej czy kradzieży hasła. Zaczęły się wewnątrz samego łańcucha dostaw oprogramowania.
- SolarWinds: system budowania został skompromitowany w celu wstrzyknięcia złośliwego kodu do podpisanych aktualizacji oprogramowania, docierając do agencji rządowych Stanów Zjednoczonych i tysięcy klientów korporacyjnych w dalszej części łańcucha.
- Log4Shell: jeden podatny komponent open source, ukryty w drzewie zależności współdzielonym przez niezliczone projekty, stał się poważną luką, którą atakujący wykorzystali jednocześnie w tysiącach niepowiązanych organizacji.
- xz-utils: środowisko budowania zaufanego opiekuna pakietu stało się wektorem ataku, dzięki atakującemu wystarczająco cierpliwemu, by wykorzystać lata zgromadzonego zaufania.
Wzór jest taki sam we wszystkich trzech przypadkach. Punktem kompromitacji był proces budowania, a nie działająca aplikacja.
Obraz kontenera jest ostatnim artefaktem, zanim wynik budowania trafi na produkcję. Jest to również ostatnie praktyczne miejsce na wykrycie skompromitowanego komponentu i jego zależności, zanim exploit wyrządzi szkodę.
Dlaczego Docker Hub i publiczne rejestry nie wystarczają
Publiczny rejestr jest domyślnie publiczny, chyba że płacisz za prywatne repozytoria. Nie posiada RBAC dla poszczególnych zespołów, egzekwowania polityki CVE ani weryfikacji podpisu przy pobieraniu.
To nie jest luka w funkcjonalności, którą można załatać. To inny typ produktu.
Publiczne rejestry istnieją po to, aby dystrybuować oprogramowanie open source do każdego odbiorcy, który tego chce. Autor pakietu i odbiorca pakietu nigdy się nie spotykają i żaden z nich nie może zbyt wiele zweryfikować na temat drugiego.
Kontrolowanie dokładnie tego, jakie obrazy oprogramowania mogą pobierać klastry Kubernetes w Twojej organizacji, to zupełnie inny problem.
Ogólny prywatny rejestr bez udokumentowanej postawy bezpieczeństwa również nie zmniejsza ryzyka w łańcuchu dostaw oprogramowania. Ryzyko jest konkretne: jeden atak, który umieszcza złośliwy komponent w jednym obrazie, przejmuje każdy klaster, który go pobiera.
To ryzyko potęguje się z każdym zespołem korzystającym z tego samego rejestru. Bez systematycznego skanowania, warstwy polityk i ścieżki audytu dotyczącej tego, kto przesłał dany element, kiedy to zrobił i czy został on podpisany, przeniosłeś obrazy z publicznego rejestru bez zmniejszenia ryzyka.
Perspektywa zgodności: ISO 27001, SOC 2 i branże regulowane
Zespoły ds. bezpieczeństwa rzadko otrzymują budżet na tę pracę, dopóki nie wymusi go audyt. Audyty zgodności traktują nieskanowane obrazy kontenerów jako krytyczne ustalenie, a nie sugestię.
Bezpieczeństwo to postawa, którą utrzymujesz, a nie produkt, który kupujesz, a audytor sprawdza postawę, a nie listę narzędzi. Bezpieczeństwo łańcucha dostaw oprogramowania jest oceniane jako zestaw praktyk, a każda praktyka wymaga dowodów.
ISO 27001, SOC 2 oraz większość standardów bezpieczeństwa w branżach regulowanych, opracowanych w dużej mierze przy udziale agencji rządowych i organów doradczych branży, oczekują udokumentowanego, systematycznego skanowania podatności i kontroli dostępu do każdego oprogramowania trafiającego na produkcję. Obrazy kontenerów są artefaktami produkcyjnymi, takimi jak każde inne.
Obrazy kontenerów przechowują również kod aplikacji, konfigurację, a czasem zmienne środowiskowe. Uprawnienia do rejestru stanowią zatem kontrolę dostępu do wrażliwej własności intelektualnej oprogramowania.
To dokładnie te najlepsze praktyki bezpieczeństwa, których audytor oczekuje w formie udokumentowanej, a nie domniemanej.
Zalecana praktyka w każdym opublikowanym zbiorze wytycznych, od CISA po CNCF, jest taka sama i warto ją poznać, zanim zmusi cię do tego audyt:
• Uczyń każdą kontrolę udokumentowaną praktyką z wyznaczonym właścicielem.
• Zabezpiecz środowisko budowania równie starannie, jak środowisko uruchomieniowe.
• Utrzymuj zależności w aktualnym stanie, aby nie gromadziły się znane luki w zabezpieczeniach.
Audytorzy oczekują dowodów dla każdego z tych punktów, a centrum Identity, Security & Operations w OVHcloud obejmuje usługi, które je generują.
Cztery mechanizmy kontrolne, których potrzebuje każdy potok konteneryzacji
Framework taki jak SLSA (Supply-chain Levels for Software Artifacts) zapewnia zespołom ustrukturyzowany sposób mierzenia dojrzałości tych mechanizmów kontroli. Nie musisz wdrażać pełnego frameworka, aby czerpać praktyczne korzyści.
Poziomy SLSA są przydatne głównie jako wspólny język w komunikacji z audytorami i partnerami, a już tylko z tego powodu warto poznać SLSA. Partner zewnętrzny deklaruje swój poziom, Ty porównujesz go ze swoim i nikt nie musi wysyłać długich kwestionariuszy.
Dostawcy coraz częściej publikują swoje poziomy, więc pytanie partnera o jego poziom jest standardowym elementem procesu zakupowego.
Analiza statyczna, czyli SAST, jest uruchamiana na kodzie źródłowym, zanim cokolwiek zostanie zbudowane. Wykrywa ona inną klasę podatności niż skanowanie obrazów i powinna znajdować się wcześniej w łańcuchu, obok analizy składu oprogramowania dla Twoich zależności.
SAST i skanowanie obrazów to uzupełnienia, a nie substytuty. Żadne z nich nie wykrywa tego, co drugie ma za zadanie znaleźć. Trzy warstwy obejmują cały łańcuch:
1. Uruchom SAST na własnym kodzie źródłowym.
2. Uruchom analizę składu oprogramowania na zewnętrznych zależnościach.
3. Uruchom skanowanie obrazów na zbudowanym artefakcie.
Pomiń jeden z tych trzech elementów, a pozostawisz całą klasę podatności niezmierzoną, niezależnie od tego, co raportują inne narzędzia.
Cztery poniższe mechanizmy kontrolne zaczynają działać w momencie, gdy kompilacja tworzy obraz kontenera, będący głównym artefaktem w tym łańcuchu.
Przechowuj obrazy w prywatnym rejestrze kontrolowanym przez RBAC
Podstawową kontrolą bezpiecznego łańcucha dostaw oprogramowania jest rejestr, który jest domyślnie zamknięty, z RBAC dla poszczególnych projektów lub zespołów. Nie współdzielony zasobnik, do którego każdy może przesyłać, i nie publiczny rejestr z obrazami widocznymi domyślnie.
Konta robotów wykonują resztę pracy:
• Ogranicz każde konto robota do pojedynczego projektu.
• Nadaj krokom budowania uprawnienia tylko do zapisu (push), a krokom wdrażania uprawnienia tylko do odczytu (pull).
• Uruchamiaj jeden projekt na zespół, aby skompromitowany projekt pozostał odizolowany.
• Stosuj jedną centralną politykę dla każdego projektu, audytowaną centralnie.
• Całkowicie wyeliminuj dane uwierzytelniające osobiste i administracyjne z automatycznych kompilacji.
Skanuj każdy obraz pod kątem CVE przy wypychaniu i pobieraniu
Skanowanie podatności musi odbywać się w dwóch punktach:
• Przy wypychaniu (push), aby nowy obraz był skanowany w momencie jego zbudowania.
• Przy pobieraniu (pull), aby sprawdzenie polityki zostało uruchomione ponownie, zanim starszy obraz zostanie wdrożony w oparciu o nowszą bazę danych podatności.
Obraz, który był czysty w marcu, może zawierać trzy znane podatności w czerwcu, a tylko sprawdzenie w momencie pobierania je wykryje.
Asynchroniczne skanowanie przy wypychaniu nie spowalnia kompilacji. Skanowanie odbywa się równolegle podczas trwania potoku, a wyniki są dostępne, zanim obraz zostanie promowany do środowiska produkcyjnego.
Podpisuj artefakty za pomocą Cosign lub Notary v2
Kryptograficzne podpisanie obrazu rejestruje, kto go zbudował, i potwierdza, że nie został on naruszony podczas przesyłania. Ustanawia to łańcuch zaufania od systemu budowania do klastra.
Zaufanie jest tym, w co tak naprawdę celuje atakujący. Backdoor w xz-utils zadziałał, ponieważ zaufanie do jednego opiekuna budowało się przez lata, a atakujący są wystarczająco cierpliwi, by wykorzystać opiekuna, a nie firewall.
Cosign, część projektu Sigstore, oraz Notary v2 to obecnie dwa dominujące podejścia open source do podpisywania obrazów kontenerów.
Bez podpisu i polityki, która go weryfikuje, nie ma sposobu, aby po incydencie udowodnić, że obraz działający na produkcji jest dokładnie tym artefaktem, który zbudował twój potok. Niepodpisany obraz i obraz zmodyfikowany są nieodróżnialne w momencie wdrażania.
Wymuszaj politykę wdrażania, zanim obrazy trafią do Kubernetes
Skanowanie i podpisywanie mają znaczenie tylko wtedy, gdy coś je wymusza. Kontroler przyjęcia Kubernetes, przy czym Kyverno lub OPA Gatekeeper to dwa najczęstsze wybory, sprawdza każdy obraz w momencie wdrażania i odrzuca wszystko, co nie spełnia zasad:
• Nierozwiązane krytyczne luki CVE.
• Brakujący lub nieprawidłowy podpis Cosign.
• Obraz z niezatwierdzonego rejestru.
To jest mechanizm kontrolny, który sprawia, że pozostałe stają się egzekwowalne, i ten, który atak musi pokonać. Zmienia on skanowanie obrazów z raportowanej metryki w twardą bramkę, dzięki czemu żaden nieskanowany obraz nie trafia na produkcję, co stanowi rzeczywisty wymóg zgodności.
Te dwa punkty egzekwowania są komplementarne. Rejestr blokuje wypchnięcie, klaster blokuje wdrożenie, a atak, który ominie jedno, nadal napotyka drugie. Oba rozwiązania działają w oparciu o klaster, którym nie musisz zarządzać samodzielnie, korzystając z Managed Kubernetes Service w OVHcloud.
Te cztery kontrole techniczne stanowią uzupełnienie, a nie zastępstwo dla praktyk organizacyjnych, które szerzej ograniczają ryzyko. Praktyki tego typu są tanie w porównaniu z incydentem i każdą z nich audytor może zweryfikować.
Oto praktyki, które zmieniają bezpieczny projekt w bezpieczny system, a każda z nich jest praktyką kluczową, a nie opcjonalnym dodatkiem:
• Regularnie aktualizuj zależności i komponenty stron trzecich, aby chronić się przed znanymi exploitami.
• Ogranicz dostęp do wrażliwych systemów budowania i kluczy podpisujących.
• Edukuj pracowników i prowadź szkolenia z zakresu świadomości bezpieczeństwa, aby inżynierowie potrafili rozpoznać zainfekowany pakiet lub próbę phishingu wymierzoną w konto opiekuna projektu.
• Przeprowadzaj ćwiczenia w oparciu o plan reagowania na incydenty, aby zespół wiedział, jak szybko zareagować, gdy kontrola zawiedzie.
• Weryfikuj integralność oprogramowania w sposób ciągły, zamiast zakładać, że jest ona zachowana, aby każdy artefakt był zabezpieczony kontrolą, a nie nawykiem.
Każda potencjalna luka w zabezpieczeniach na tej liście jest zazwyczaj luką procesową, a nie narzędziową.
Każdy komponent oprogramowania, który pobierasz, oraz każdy komponent przechodni poniżej niego, to decyzja, którą ktoś podjął raz i rzadko do niej wraca. Nowoczesna aplikacja zawiera setki takich komponentów, w większości od zewnętrznych dostawców, których nikt nie zna.
Inwentaryzacja komponentów jest zatem praktyką, od której zależy wszystko inne. Zarządzanie zależnościami, czyli wiedza o tym, które oprogramowanie i które komponenty pochodzą od stron trzecich, sprawia, że SBOM (wykaz składników oprogramowania) jest użyteczny, gdy już go posiadasz.
SBOM zawiera listę wszystkich komponentów i ich wersji, co zmienia nowe powiadomienie o CVE w pięciominutowe zapytanie zamiast tygodnia poszukiwań w archiwach. Bez niego uczciwa odpowiedź na pytanie, czy jesteś narażony na ryzyko, brzmi: nikt tego nie wie.
Jak OVHcloud Managed Private Registry wypełnia tę lukę
Harbor pod maską: Zatwierdzony przez CNCF, zgodny ze standardem OCI, open source
Managed Private Registry to w pełni zarządzana instancja Harbor, technologii open source zatwierdzonej przez CNCF, stworzonej do przechowywania kontenerów i wykresów Helm, w której bezpieczeństwo jest kluczową funkcją, a nie dodatkiem.
Samodzielne hostowanie Harbor oznacza uruchamianie i aktualizowanie PostgreSQL, Redis, podstawowych usług Harbor i skanera, a także obsługę TLS i aktualizacji każdego z tych komponentów.
OVHcloud usuwa tę warstwę operacyjną. Tworzysz rejestr, przesyłasz obrazy i konfigurujesz politykę, podczas gdy infrastruktura Harbor leży po stronie OVHcloud. To uwalnia Twój zespół ds. cyberbezpieczeństwa, pozwalając mu skupić się na modelowaniu zagrożeń i odporności łańcucha dostaw, zamiast na łataniu bazy danych.
Ponieważ Harbor jest oprogramowaniem typu open source i opiera się na standardach, nie ma ryzyka uzależnienia od dostawcy (vendor lock-in). Obrazy znajdują się w standardowym formacie OCI, więc migracja do samodzielnie hostowanego Harbor lub innego rejestru zgodnego z OCI nie wymaga konwersji ani rezygnacji z własnościowego formatu pobierania.
Ta przejrzystość sama w sobie jest cechą bezpieczeństwa. Globalna społeczność recenzentów, a nie pojedynczy dostawca, sprawdza kod, na którym działa Twój rejestr.
Centralny projekt z wieloma recenzentami wykrywa złośliwe commity szybciej niż projekt zamknięty, a informacje o zagrożeniach dotyczących luk w zabezpieczeniach Harbor lub Trivy docierają do Ciebie tymi samymi publicznymi kanałami, z których korzystają wszyscy inni użytkownicy.
Skanowanie podatności za pomocą Trivy: Wykrywanie CVE przy przesyłaniu i pobieraniu
OVHcloud Managed Private Registry zawiera Trivy, wbudowany skaner Harbor, aktywowany na poziomie projektu.
Skonfiguruj skanowanie przy przesyłaniu (scan-on-push), aby każdy obraz był sprawdzany w momencie dodania, a następnie ustaw próg dotkliwości CVE. Ostrzeganie przy poziomie HIGH, blokowanie przy CRITICAL to zalecana polityka początkowa.
Skanowanie w momencie pobierania ponownie sprawdza starszy obraz w oparciu o nowszą bazę danych podatności.
Polityka wdrażania Harbor zapobiega pobieraniu obrazów z nierozwiązanymi podatnościami CRITICAL CVE do przestrzeni nazw produkcyjnych, co sprawia, że wynik skanowania jest możliwy do wykorzystania, a nie tylko informacyjny.
Podpisywanie obrazów za pomocą Cosign i Notary v2
Usługa opiera się na rozwiązaniu Harbor, dzięki czemu obsługuje skanowanie podatności oraz przechowywanie wykresów Helm, które są udokumentowane dla tego produktu.
Samo podpisywanie obrazów odbywa się za pomocą standardowych narzędzi open source Cosign w Twoim potoku CI/CD, wskazując na rejestr OVHcloud zamiast na własnościową usługę podpisywania.
Wymuszanie polityki: blokowanie obrazów z krytycznymi CVE przed wdrożeniem
Polityka po stronie rejestru, blokująca krytyczne luki CVE i wymagająca ważnego podpisu, to tylko połowa sukcesu w zakresie egzekwowania zasad.
Druga połowa działa w samym Kubernetes. Polityka przyjęcia (admission policy) w Kyverno lub OPA Gatekeeper odrzuca każdy obraz bez ważnego podpisu Cosign lub z nierozwiązaną poważną luką w zabezpieczeniach, niezależnie od tego, jak został wdrożony lub przez kogo.
Razem zapewniają one kompleksową blokadę CVE wymuszaną przez polityki. Jest to konfiguracja, którą ustawiasz celowo, a nie automatyczna gwarancja.
Przechowywanie wykresów Helm (zgodne z OCI)
Wykresy Helm są przechowywane w tym samym formacie zgodnym z OCI co obrazy kontenerów, w tej samej strukturze projektu, z tymi samymi kontami RBAC i robotami.
Zespoły pakujące wdrożenia jako wykresy Helm otrzymują jeden rejestr dla obu typów artefaktów, zamiast oddzielnego repozytorium wykresów do zabezpieczenia i utrzymania.
Łączenie potoku CI/CD (GitHub Actions, GitLab CI, Tekton)
Konta robotów: tylko do zapisu przy wypychaniu dla kompilacji, tylko do odczytu przy pobieraniu dla wdrożeń
Utwórz jeden projekt Harbor na zespół lub aplikację, a następnie wydaj konta robotów o uprawnieniach ograniczonych dokładnie do tego, czego wymaga dany etap: tylko do zapisu (push) dla etapu budowania, tylko do odczytu (pull) dla etapu wdrażania.
Nigdy nie umieszczaj danych uwierzytelniających administratora lub osobistych, ani klucza konta robota, w definicji kompilacji.
konta robota, w definicji kompilacji. Wyciek danych konta robota z uprawnieniami tylko do odczytu to incydent o ograniczonym zasięgu. Wyciekłe dane uwierzytelniające administratora w rękach podmiotu zewnętrznego nie są.
W przypadku kluczy podpisywania Cosign, OVHcloud OVHcloud Key Management Service obsługuje model bring-your-own-key z pamięcią masową opartą na modułach HSM zgodnych z FIPS 140-2, co chroni Twoje klucze przed dostępem z laptopów programistów i serwerów CI.
Przykład GitHub Actions: budowanie, skanowanie, podpisywanie i wypychanie
Pojedynczy etap obejmuje całą bramkę:
1. Zbuduj obraz.
2. Wypchnij go za pomocą konta robota z uprawnieniami tylko do zapisu.
3. Poczekaj na wynik skanowania Trivy.
4. Podpisz za pomocą Cosign tylko wtedy, gdy skanowanie przejdzie skonfigurowany próg CVE.
Ta sekwencja utrzymuje sztywną barierę między istnieniem obrazu a uznaniem go za wystarczająco zaufany, by go podpisać, zamiast podpisywać go bezwarunkowo w czasie budowania.
Ten sam wzorzec ma zastosowanie niezależnie od tego, czy budowanie odbywa się w GitHub Actions, GitLab CI czy Tekton. Zmienia się tylko składnia wywołania rejestru i skanera, niezależnie od języka programowania, w którym napisana jest Twoja aplikacja.
Polityki admission Kyverno w usłudze Managed Kubernetes Service
W usłudze OVHcloud Managed Kubernetes Service polityka Kyverno, zdefiniowana jako standardowy plik polityki Kubernetes, sprawdza każdy przychodzący spec poda pod kątem ważnego podpisu Cosign i odrzuca wdrożenie, jeśli podpis jest brakujący lub nieprawidłowy.
W połączeniu z polityką CVE po stronie rejestru, zamyka to pętlę między tym, co budujesz, a tym, co może uruchomić klaster. Niepodpisany lub nieskanowany obraz nigdy nie zostanie uruchomiony, niezależnie od tego, kto zlecił wdrożenie.
Suwerenny łańcuch dostaw: dlaczego jurysdykcja Twojego rejestru ma znaczenie
Obrazy kontenerów niosą ze sobą własność intelektualną, a wraz z nią ekspozycję na ustawę CLOUD Act
Obraz kontenera zawiera kod aplikacji, warstwy konfiguracyjne i czasami zmienne środowiskowe: znaczący fragment własności intelektualnej Twojej organizacji. Centralny rejestr to miejsce, w którym koncentruje się ta własność intelektualna, dlatego jego jurysdykcja ma znaczenie. Przechowywanie tego obrazu u dostawcy z siedzibą w USA, nawet jeśli posiada on centra danych w UE, podlega jurysdykcji amerykańskiej ustawy CLOUD Act, ponieważ ekspozycja podąża za spółką macierzystą, a nie za lokalizacją przechowywania danych. Ta sama logika dotyczy każdego wdrożenia AWS ECR, Google Artifact Registry lub Docker Hub: Jurysdykcja amerykańskiej ustawy CLOUD Act ma zastosowanie niezależnie od regionu.
Siedziba w Europie, brak spółki macierzystej w USA, RODO zgodnie z jurysdykcją
Obraz kontenera zawiera kod aplikacji, warstwy konfiguracyjne i czasami zmienne środowiskowe: znaczący fragment własności intelektualnej Twojej organizacji.
Centralny rejestr to miejsce, w którym koncentruje się ta własność intelektualna, dlatego jego jurysdykcja ma znaczenie.
Przechowywanie tego obrazu u dostawcy z siedzibą w USA, nawet jeśli posiada on centra danych w UE, podlega jurysdykcji amerykańskiej ustawy CLOUD Act, ponieważ ekspozycja podąża za spółką macierzystą, a nie za lokalizacją przechowywania danych.
To samo dotyczy każdego rejestru obsługiwanego przez dostawcę z siedzibą w USA: Jurysdykcja amerykańskiej ustawy CLOUD Act ma zastosowanie niezależnie od regionu.
Siedziba w Europie, brak spółki macierzystej w USA, RODO zgodnie z jurysdykcją
OVHcloud jest europejskim operatorem bez spółki matki w USA, więc nie ma strukturalnego narażenia na ustawę CLOUD Act w odniesieniu do czegokolwiek przechowywanego w rejestrze.
Infrastruktura rejestru podlega RODO ze względu na jurysdykcję, a nie na zobowiązania wynikające z polityki.
Ochrona prawna wynika z lokalizacji firmy oraz infrastruktury, a nie z obietnicy umownej nałożonej na infrastrukturę, do której udostępnienia mogłyby mimo wszystko zmusić obce organy władzy.
Ścieżka kompleksowa: Managed Private Registry do Managed Kubernetes Service
Utwórz projekt Managed Private Registry, wypchnij obraz i włącz skanowanie oraz podpisywanie. MKS Free obejmuje środowiska programistyczne i testowe bez dodatkowych kosztów, dzięki czemu możesz zweryfikować cały łańcuch polityk, zanim zacznie od niego zależeć ruch produkcyjny. W przypadku wielu klastrów produkcyjnych, sektorów regulowanych lub pul węzłów GPU, architekt rozwiązań OVHcloud pomoże w doborze odpowiedniej wielkości. Centrum orkiestracji kontenerów to miejsce, w którym dowiesz się o reszcie.
Dostępność 3-AZ w Paryżu i Mediolanie, gwarancja dostępności (SLA) 99,99% w MKS Standard
Rejestr działa w 3 strefach dostępności (3-AZ) w Paryżu z wbudowaną wysoką dostępnością. Awaria pojedynczej strefy nie zatrzymuje ani Twoich kompilacji, ani wdrożeń, co ma znaczenie, ponieważ awaria rejestru blokuje oba te procesy.
Usługa Managed Kubernetes Service Standard działa w 3 strefach dostępności w Paryżu i Mediolanie z gwarancją dostępności (SLA) na poziomie 99,99%, dzięki czemu rejestr i pobierający z niego klaster mają ten sam poziom dostępności, zamiast być dla siebie słabym ogniwem.
MKS Free na start, MKS Standard dla produkcji
Managed Kubernetes Service posiada darmowy poziom dla środowisk programistycznych i testowych, wystarczający do zweryfikowania pełnego łańcucha dostaw oprogramowania: rejestru, skanowania, podpisywania i polityki przyjmowania, przed podjęciem decyzji o wdrożeniu w klastrze produkcyjnym.
Przypinanie wersji w plikach polityk zapewnia powtarzalność tej weryfikacji.
Gdy będziesz gotowy na ruch produkcyjny, MKS Standard doda poziom 3-AZ z gwarancją dostępności SLA na poziomie 99,99%, a te same polityki Kyverno lub OPA Gatekeeper pozostaną niezmienione w obu poziomach.
Zespoły obsługujące kilka klastrów dodają Managed Rancher Service, aby uzyskać jeden płaszczyznę sterowania dla nich wszystkich.
Rozpocznij: aktywuj swój rejestr i zacznij dostarczać bezpieczne obrazy już dziś
Utwórz projekt Managed Private Registry, wypchnij obraz i włącz skanowanie oraz podpisywanie. MKS Free obejmuje środowiska programistyczne i testowe bez dodatkowych kosztów, dzięki czemu możesz zweryfikować cały łańcuch polityk, zanim zacznie od niego zależeć ruch produkcyjny. W przypadku wielu klastrów produkcyjnych, sektorów regulowanych lub pul węzłów GPU, architekt rozwiązań OVHcloud pomoże w doborze odpowiedniej wielkości. Centrum orkiestracji kontenerów to miejsce, w którym dowiesz się więcej.