Kubernetes werd verreweg het populairste cloudcontainersysteem Dus eigenlijk het was slechts een kwestie van tijd voordat zijn eerste grote beveiligingsfout werd ontdekt.
En zo was het, want onlangs De eerste grote beveiligingsfout in Kubernetes werd uitgebracht onder CVE-2018-1002105, ook wel bekend als de mislukte escalatie van bevoegdheden.
Deze grote fout in Kubernetes is een probleem, aangezien het een kritiek CVSS 9.8-beveiligingslek is. In het geval van de eerste grote beveiligingsfout van Kubernetes.
Details van de fout
Met een speciaal ontworpen verzoeknetwerk kan elke gebruiker een verbinding tot stand brengen via vanaf de Application Programming Interface-server (API) Kubernetes naar een back-end-server.
Eenmaal gevestigd, een aanvaller kan willekeurige verzoeken via de netwerkverbinding rechtstreeks naar die backend sturen waarbij het doel te allen tijde die server is.
Deze verzoeken worden geverifieerd met de TLS-inloggegevens (Transport Layer Security) vanaf de Kubernetes API-server.
Erger nog, in de standaardconfiguratie kunnen alle gebruikers (geverifieerd of niet) API-opsporingsoproepen uitvoeren die deze privilege-escalatie door de aanvaller mogelijk maken.
Waarmee iedereen die dat gat kent, van de gelegenheid gebruik kan maken om het commando over zijn Kubernetes-cluster over te nemen.
Op dit moment is er geen gemakkelijke manier om te detecteren of deze kwetsbaarheid eerder werd gebruikt.
Aangezien ongeautoriseerde verzoeken worden gedaan via een bestaande verbinding, worden ze niet weergegeven in de controlelogboeken van de Kubernetes API-server of het serverlogboek.
Verzoeken worden weergegeven in de kubelet-logboeken of de samengevoegde API-server, maar ze onderscheiden zich van correct geautoriseerde en proxyverzoeken via de Kubernetes API-server.
Misbruik deze nieuwe kwetsbaarheid in Kubernetes het zou geen duidelijke sporen achterlaten in de logboeken, dus nu de Kubernetes-bug aan het licht komt, is het slechts een kwestie van tijd voordat het wordt gebruikt.
Met andere woorden, Red Hat zei:
Door de fout bij het escaleren van bevoegdheden kan elke ongeautoriseerde gebruiker volledige beheerdersrechten krijgen op elk rekenknooppunt dat wordt uitgevoerd in een Kubernetes-pod.
Dit is niet alleen een diefstal of een opening om kwaadaardige code te injecteren, het kan ook de applicatie- en productiediensten binnen de firewall van een organisatie verminderen.
Elk programma, inclusief Kubernetes, is kwetsbaar. Kubernetes-distributeurs brengen al fixes uit.
Red Hat meldt dat al zijn op Kubernetes gebaseerde producten en services, waaronder Red Hat OpenShift Container Platform, Red Hat OpenShift Online en Red Hat OpenShift Dedicated, worden getroffen.
Red Hat begon met het leveren van patches en service-updates aan getroffen gebruikers.
Voor zover bekend heeft nog niemand de inbreuk op de beveiliging gebruikt om aan te vallen. Darren Shepard, hoofdarchitect en mede-oprichter van Rancher Laboratory, ontdekte de bug en rapporteerde deze met behulp van het Kubernetes-rapportageproces voor kwetsbaarheden.
Hoe kunt u deze fout verhelpen?
Gelukkig is er al een oplossing voor deze bug uitgebracht Waarin alleen ze worden gevraagd om een Kubernetes-update uit te voeren zodat ze een aantal van de Kubernetes gepatchte versies v1.10.11, v1.11.5, v1.12.3 en v1.13.0-RC.1 kunnen kiezen.
Dus als u nog steeds een van de Kubernetes v1.0.x-1.9.x-versies gebruikt, is het raadzaam om te upgraden naar een vaste versie.
Als ze om de een of andere reden Kubernetes niet kunnen updaten en ze deze mislukking willen stoppen, is het noodzakelijk dat ze het volgende proces uitvoeren.
U moet stoppen met het gebruik van de serveraggregaten-API of pod exec / attach / portforward-machtigingen verwijderen voor gebruikers die geen volledige toegang zouden moeten hebben tot de kubelet-API.
Jordan Liggitt, de software-engineer van Google die de bug heeft verholpen, zei dat die maatregelen waarschijnlijk schadelijk zullen zijn.
Dus de enige echte oplossing voor deze beveiligingsfout is het uitvoeren van de bijbehorende Kubernetes-update.