Nowa wersja Kubernetes Container Platform 1.13 usuwa krytyczną lukę w zabezpieczeniach (CVE-2018-1002105), co pozwala każdemu użytkownikowi uzyskać pełną kontrolę nad grupą izolowanych kontenerów. Problem został również rozwiązany w aktualizacjach 1.10.11, 1.11.5 i 1.12.3.
W luce znalezionej w Kubernetes, aby przeprowadzić atak, wystarczy wysłać przez API specjalnie zaprojektowane żądanie w celu ustalenia dostępnych backendów (żądanie discovery).
O luce Kubernetes
Z powodu błędu tego typu żądanie pozostawia otwarte połączenie sieciowe, umożliwiając korzystanie z serwera API (kube-apiserver) jako pośrednik do wysyłania żądań do dowolnego serwera przy użyciu połączenia nawiązanego z serwerem API.
W związku z tym żądania przekazywane przez takie połączenia będą przetwarzane przez zaplecze jako żądania wewnętrznego serwera APIwysyłane przy użyciu parametrów uwierzytelniania serwera API.
Domyślnie, wszyscy uwierzytelnieni i nieuwierzytelnieni użytkownicy Kubernetes mają możliwość wysyłania żądań za pośrednictwem Discovery API, które są wystarczające do przeprowadzenia ataku.
Dlatego każdy nieuprzywilejowany użytkownik Kubernetes, który ma dostęp do API, może uzyskać pełną kontrolę nad całą infrastrukturą, na przykład wysyłając żądanie uruchomienia swojego kodu na hoście.
Oprócz przejęcia kontroli nad infrastrukturą Kubernetes, luka może dotyczyć również ataków na klientów poprzez manipulację usługami klienta zlokalizowanymi w chmurze.
Problem objawia się we wszystkich wersjach Kubernetes, począwszy od wersji 1.0.
Dlatego wszyscy administratorzy Kubernetes są zachęcani do pilnego aktualizowania swoich systemów pod kątem bieżących problemów, a także do audytowania dzienników systemowych pod kątem potencjalnej złośliwej aktywności.
Jako rozwiązanie chroniące przed atakami nieautoryzowanych użytkowników, mogą wyłączyć anonimowy dostęp do API używając opcji „–anonymous-auth = false” i unieważnij prawa do wykonywania operacji exec / attach / portforward.
Osobno zaznaczamy, że w logach Kubernetes atak z wykorzystaniem nieautoryzowanych żądań w ogóle nie jest rejestrowany, dlatego można było określić, czy kompromitacja była możliwa tylko za pomocą znaków pośrednich.
O nowej wersji Kubernetes 1.13 i nowościach
W nowej wersji Kubernetes 1.13 Interfejs Container Storage Interface (CSI) został ustabilizowany, umożliwiając tworzenie wtyczek obsługujących wiele systemów pamięci masowej.
CSI zapewnia jeden interfejs do przydzielania, dołączania i montowania repozytoriów, umożliwiając udostępnianie wtyczek do integracji z różnymi usługami pamięci masowej bez konieczności wprowadzania zmian w bazie kodu Kubernetes.
Domyślnie używany jest serwer DNS CoreDNS.
CoreDNS jest napisany w języku Go i wyróżnia się elastyczną architekturą opartą na wtyczkach.
Na przykład określone funkcje, takie jak wykrywanie usług Kubernetes, gromadzenie metryk dla systemu monitorowania Prometheus i integracja z systemem przechowywania konfiguracji itp. są realizowane poprzez wtyczki.
Kubeadm został ustabilizowany jako uproszczony interfejs do zarządzania klastrem Kubernetes, który pozwala na wykonywanie takich operacji jak tworzenie i wdrażanie klastra na istniejącej maszynie, konfigurowanie podstawowych komponentów Kubernete, łączenie i usuwanie węzłów, wykonywanie operacji aktualizacji;
Przedstawiono eksperymentalny interfejs do tworzenia wtyczek do integracji z systemami monitorowania innych firm.
Rejestr wtyczek urządzeń Kubelet ze stabilizacją usług, który zapewnia dostęp do Kubelet z wtyczek.
Harmonogram dystrybucji kontenerów TAVS (Topology Aware Volume Scheduling) został ustabilizowany, biorąc pod uwagę topologię sekcji pod (biorąc pod uwagę ograniczenia określone dla węzłów i stref).
Przeszliśmy do fazy testów beta APIServer DryRun, zespołu Kubectl Diff i możliwości wykorzystania surowych urządzeń blokowych jako trwałych źródeł danych (trwałe źródło woluminów).
Jeśli chcesz dowiedzieć się czegoś więcej o nowej wersji puszka odwiedź poniższy link.