Krytyczna podatność w Kubernetes. 9.8/10 w skali CVSS

Kubernetes generalnie uznawany jest za rozwiązanie bezpieczne (więcej o samym rozwiązaniu, dostępnych komponentach – tutaj). Rzeczywiście, historycznie nie było tutaj jakiejś ogromnej liczby bugów. A tymczasem użytkownicy mogą przejąć kontrolę nad całym systemem:

An API call to any aggregated API server endpoint can be escalated to perform any API request against that aggregated API server, as long as that aggregated API server is directly accessible from the Kubernetes API server’s network. In default configurations, all users (authenticated and unauthenticated) are allowed to perform discovery API calls that allow this escalation.

Stosowną łatkę wydał też Microsoft, nad patchem pracuje RedHat (łatka w OpenShift). W tym ostatnim możliwe efekty są takie:

For OpenShift Dedicated environments, a regular user, with pod exec/attach/portforward permissions, can gain cluster-level administrative privileges on any compute node that can run that pod.  This includes exec access to all running workloads, all current secrets, logs, etc.

(…) The second attack doesn’t require any privileges and exploits the API extension feature used by ‘metrics-server’ and ‘servicecatalog’ in OpenShift Container Platform, OpenShift Online, and Dedicated. It allows an unauthenticated user to gain cluster-admin privileges to the any API extension deployed to the cluster including ‘servicecatalog’. Cluster-admin access to ‘servicecatalog’ allows creation of service brokers in any namespace and on any node.

RedHat przygotował nawet krótki filmik ilustrujący problem (choć przyznam szczerze, mógłby być bardziej szczegółowy):

Zapewne niedługo pokażą się PoC exploity na opisywaną podatność, postaramy się wtedy nieco dokładniej opisać problem. Na razie – łatajcie.

–ms