Tester penetracyjny uzyskał dostęp do naszego klastra Kubernetes w 15 minut. Oto co wykorzystali. Łańcuch ataku: - Znalazł wystawiony na zewnątrz pulpit nawigacyjny Kubernetes (nasza wina) - Pulpit miał konto serwisowe tylko do odczytu (myśleliśmy, że to bezpieczne) - Konto serwisowe mogło wylistować sekrety we wszystkich przestrzeniach nazw - Znalazł dane uwierzytelniające AWS w sekrecie - Użył danych uwierzytelniających AWS, aby uzyskać dostęp do profilu instancji EC2 - Profil instancji miał pełne uprawnienia administratora Kubernetes przez IAM - Użył kubectl do stworzenia uprzywilejowanego poda - Wydostał się na węzeł - Uzyskał dostęp root do całego klastra Co myśleliśmy, że zrobiliśmy dobrze: - Pulpit był tylko do odczytu - Sekrety były szyfrowane w spoczynku - Polityki sieciowe były wdrożone - Regularne aktualizacje zabezpieczeń Co przeoczyliśmy: - Pulpit nie powinien być w ogóle wystawiony - Konta serwisowe muszą mieć zasadę najmniejszych uprawnień - Sekrety nie powinny zawierać danych uwierzytelniających AWS (użyj IRSA zamiast) - Polityki bezpieczeństwa poda nie były egzekwowane - Dostęp do węzła nie był wzmocniony Naprawa zajęła 2 tygodnie: - Całkowicie usunięto pulpit nawigacyjny Kubernetes - Wdrożono IRSA dla całego dostępu do AWS przez pod - Zastosowano surowe PSP/Standardy bezpieczeństwa poda...