Red Hat ACM: złośliwy klaster spoke może przejąć zaufanie całej floty

20 sierpnia opublikowano zestaw podatności dotyczących Red Hat Advanced Cluster Management, Lighthouse, Submariner i multicloud-operators-subscription. Najpoważniejsze mają CVSS 3.1 równy 9,9. Wspólny problem nie sprowadza się do jednego wadliwego endpointu: system wieloklastrowy zbyt szeroko ufa danym deklarowanym przez tenant albo przyłączony klaster spoke.

To szczególnie ważne dla platform, które łączą Kubernetesy wielu zespołów, oddziałów lub środowisk brzegowych. Kompromitacja pojedynczego spoke nie powinna automatycznie oznaczać możliwości sterowania ruchem i zasobami peerów. Opisane CVE pokazują jednak kilka sposobów przekroczenia tej granicy: ogłoszenie fałszywych podsieci, podstawienie adresów EndpointSlice, wybór dowolnej przestrzeni nazw, renderowanie chartu z podwyższonymi uprawnieniami oraz odczyt Secret z obcego namespace.

Pięć podatności, jedna architektoniczna lekcja

CVE-2026-66785 dotyczy Submariner. Złośliwy spoke może opublikować spreparowany endpoint i zadeklarować arbitralne zakresy sieci. Ruch peerów przeznaczony dla tych zakresów zostaje skierowany do tunelu kontrolowanego przez napastnika. Skutkiem może być ujawnienie informacji, man-in-the-middle albo zakłócenie komunikacji.

CVE-2026-66787 występuje w Lighthouse DNS. Niewystarczająca walidacja adresów w EndpointSlice pozwala skompromitowanemu spoke wskazać adres napastnika jako cel legalnej usługi międzyklastrowej. Klient używa prawidłowej nazwy, ale trafia do fałszywego backendu. To podważa założenie, że service discovery jest tylko warstwą dostępności.

CVE-2026-66788 pozwala sterować docelowym namespace zasobów wstrzykiwanych przez Lighthouse. Dane pochodzą z kontrolowanej przez atakującego etykiety lub adnotacji obiektu brokera. W efekcie EndpointSlice i ServiceImport mogą trafić do dowolnej przestrzeni peer cluster, włącznie z kube-system i openshift-*. CVSS 9,9 odzwierciedla zmianę zakresu i możliwy wpływ na poufność, integralność oraz dostępność.

CVE-2026-67567 dotyczy kontrolera HelmRelease. Tenant mający prawo tworzenia tego CR może przekazać chart, który kontroler renderuje i wdraża przy użyciu własnego, silniejszego ServiceAccount. Bez odpowiedniej walidacji tenant uzyskuje możliwość tworzenia arbitralnych zasobów w klastrze.

CVE-2026-73137 wykorzystuje pole secretRef.Namespace. Tenant z prawem do HelmRelease może wskazać Secret z innej przestrzeni, a kontroler pobiera go przez GetSecret() i używa wobec kontrolowanego przez napastnika repozytorium Helm. To tworzy ścieżkę eksfiltracji poświadczeń.

Dlaczego RBAC nie wystarczył

Kubernetes RBAC ocenia akcję wykonywaną przez konkretną tożsamość. Jeżeli tenant tworzy tylko obiekt CR, jego uprawnienia mogą wyglądać bezpiecznie. Potem jednak operator lub kontroler odczytuje ten obiekt i wykonuje pracę przy użyciu własnego ServiceAccount. Jeśli nie traktuje pól CR jak danych niezaufanych, powstaje confused deputy: komponent uprzywilejowany realizuje intencję podmiotu, który sam takich praw nie ma.

W systemie multicluster dochodzi drugi wymiar. Hub i peer muszą przyjmować informacje o usługach, endpointach i sieciach od spoke. Użyteczność wymaga zaufania, lecz nie powinno ono być bezwarunkowe. Adres ogłoszony przez spoke musi należeć do przydzielonego zakresu; namespace powinien pochodzić z polityki huba; Secret powinien pozostawać w zatwierdzonej przestrzeni; zasoby systemowe nie mogą być docelowe dla danych kontrolowanych przez tenanta.

Kto powinien reagować

Właściciele RHACM powinni sprawdzić wersje huba, managed clusters, Submariner, Lighthouse oraz komponentów subscription. Skan samego obrazu kontenera nie wystarczy, ponieważ osiągalność zależy od włączonych funkcji, uprawnień CRD, konfiguracji brokerów i granic administracyjnych. Najwyższy priorytet mają środowiska, w których klastry spoke należą do różnych zespołów, klientów lub stref ryzyka.

Ważny jest też model „kompromitacja jest możliwa”. Nawet jeśli administratorzy wszystkich spoke są zaufani, workload, token CI/CD albo operator lokalny może zostać przejęty. Ocena nie powinna więc kończyć się zdaniem „to nasze klastry”. Należy sprawdzić, co dokładnie może zrobić jeden z nich po utracie kontroli.

Plan aktualizacji i ograniczenia ryzyka

Red Hat publikuje status produktów i poprawki w swoich stronach CVE oraz erratach. Administrator powinien dopasować aktualizację do kanału i wersji RHACM/OpenShift, a nie zgadywać poprawiony numer na podstawie wersji upstream. Przed zmianą trzeba zapisać wersje operatorów, CSV, CRD, Submariner brokers, topologię tuneli i stan service discovery.

Jeśli patch nie może wejść natychmiast, ogranicz tworzenie HelmRelease do minimalnej grupy. Przejrzyj istniejące CR pod kątem secretRef.Namespace, zewnętrznych repozytoriów i zasobów generowanych poza namespace właściciela. Zmniejsz uprawnienia ServiceAccount kontrolerów tam, gdzie wspiera to produkt. Zablokuj admission policy, która odrzuca systemowe namespace, nieprzydzielone CIDR i adresy spoza zatwierdzonej puli.

Dla Submariner i Lighthouse utwórz mapę dozwolonych podsieci per cluster ID. Nie polegaj wyłącznie na tym, co spoke deklaruje w brokerze. Jeżeli możliwe, warstwa routingu i firewall powinna niezależnie egzekwować zakresy. Dla komunikacji wrażliwej użyj wzajemnego uwierzytelnienia na poziomie aplikacji lub service mesh, aby fałszywy endpoint nie wystarczył do podszycia się pod usługę.

Hunting po kompromitacji spoke

Przeszukaj historię zmian broker objects, EndpointSlice, ServiceImport, HelmRelease oraz Secret access. Interesujące są zasoby utworzone w kube-system, openshift-* i namespace niepowiązanych z klastrem źródłowym. W logach API szukaj akcji wykonywanych przez ServiceAccount operatorów, ale inicjowanych krótko po zmianie CR należącego do tenanta.

Na warstwie sieciowej sprawdź nowe prefiksy reklamowane przez spoke, nagłe zmiany tras, tunel przenoszący ruch do nieoczekiwanego klastra i rozbieżność między IP usługi a inwentarzem. W DNS i telemetry service mesh warto wyszukać backendy, które zmieniły adres bez deploymentu. Dla CVE-2026-73137 zbadaj połączenia kontrolera do nowych repozytoriów Helm i Secret reads z nietypowych namespace.

Po znalezieniu anomalii sama aktualizacja nie wystarcza. Trzeba ocenić sekrety, które mogły zostać odczytane, dane przesłane przez fałszywy endpoint oraz zasoby utworzone w peerach. Rotacja powinna objąć realnie narażone poświadczenia, a nie wszystkie sekrety bez planu, ponieważ chaotyczna rotacja może wywołać kolejną awarię.

Jak zaprojektować bezpieczniejszą platformę multicluster

Każdy spoke powinien mieć jawnie zdefiniowany kontrakt: dozwolone CIDR, namespace, typy zasobów, nazwy usług i kierunki komunikacji. Hub waliduje kontrakt niezależnie od danych spoke. Kontroler pracujący z uprawnieniami cluster-wide powinien mieć mały, testowalny translator między CR a akcją, a pola referencji muszą być normalizowane i sprawdzane przed pobraniem zasobu.

W testach bezpieczeństwa warto używać negatywnych przypadków: obcy namespace, systemowy namespace, adres loopback, cudzy CIDR, repozytorium kontrolowane zewnętrznie i EndpointSlice wskazujący poza pulę. Nie chodzi o tworzenie exploita na produkcji, tylko o udowodnienie w środowisku testowym, że polityka odrzuca każdą niedozwoloną relację.

Fakty producenta i wnioski Breachroad

Wektory pięciu CVE, oceny CVSS oraz opis wpływu pochodzą z rekordów Red Hat i CVE opublikowanych 20 sierpnia. Źródła nie potwierdzają aktywnej eksploatacji. Nie publikują też jednej uniwersalnej wersji naprawczej dla wszystkich wariantów produktu, dlatego numer należy potwierdzić w erracie przypisanej do subskrypcji.

Kontrakt zaufania dla spoke, dodatkowe mTLS, korelacja CR z akcją operatora i priorytety huntingu są analizą Breachroad. To kontrole obrony w głąb, które zmniejszają skutki podobnych błędów także po tej aktualizacji.

Szkolenie cyberbezpieczeństwa dla zespołów technicznych pomaga przełożyć takie scenariusze na wspólny model odpowiedzialności platformy i aplikacji. Audyt bezpieczeństwa chmury może następnie sprawdzić RBAC, operatorów, admission policy, routing i dowody aktualizacji.

Źródła

• Red Hat — CVE-2026-66785
• Red Hat — CVE-2026-66787
• Red Hat — CVE-2026-66788
• Red Hat — CVE-2026-67567
• Red Hat — CVE-2026-73137