El nou llançament de la plataforma de contenidors Kubernetes 1.13 elimina una vulnerabilitat crítica (CVE-2018-1002105), que permet a qualsevol usuari obtenir un control complet sobre un grup de contenidors aïllats. El problema també es va solucionar en les actualitzacions 1.10.11, 1.11.5 i 1.12.3.
En la vulnerabilitat trobada a Kubernetes per poder realitzar l'atac n'hi ha prou amb enviar una sol·licitud especialment dissenyada a través de l'API per determinar els backends disponibles (sol·licitud de descobriment).
Sobre la vulnerabilitat de Kubernetes
A causa d'un error, aquest tipus de sol·licitud deixa oberta la connexió de xarxa, cosa que permet utilitzar el servidor API (kube-apiserver) com a intermediari per enviar sol·licituds a qualsevol servidor utilitzant la connexió establerta amb el servidor API.
En conseqüència, les sol·licituds reenviades a través d'aquestes connexions seran processades pel backend com a sol·licituds internes del servidor API, enviades utilitzant els paràmetres d'autenticació del servidor API.
Per defecte, tots els usuaris de Kubernetes autenticats i no autenticats tenen la capacitat d'enviar sol·licituds a través de l'API de descobriment, que són suficients per llençar un atac.
Per tant, qualsevol usuari de Kubernetes sense privilegis que tingui accés a l'API pot obtenir un control complet sobre tota la infraestructura, per exemple, enviant una sol·licitud per executar el codi al host.
A més d'obtenir el control de la infraestructura de Kubernetes, la vulnerabilitat també es pot aplicar a atacs dirigits a clients a través de la manipulació dels serveis al client ubicats al núvol.
El problema es manifesta a totes les versions de Kubernetes, començant amb la versió 1.0.
Per això es recomana a tots els administradors de Kubernetes que actualitzin amb urgència els seus sistemes als problemes actuals, així com que auditin els registres del sistema per detectar possibles activitats malicioses.
Com a solució per protegir-vos contra atacs d'usuaris no autoritzats, podeu deshabilitar l'accés anònim a l'API usant l'opció “–anonymous-auth = false” i revocar els drets per realitzar operacions exec/attach/portforward.
S'assenyala per separat que, als registres de Kubernetes, l'atac que utilitza sol·licituds no autoritzades no es registra en absolut, per tant, va ser possible determinar si el compromís va ser possible només mitjançant signes indirectes.
Sobre el nou llançament de Kubernetes 1.13 i les novetats
En aquest nou llançament de Kubernetes 1.13 la interfície CSI (Container Storage Interface) s'ha estabilitzat, cosa que us permet crear complements per admetre diversos sistemes d'emmagatzematge.
CSI proporciona una única interfície per assignar espai, adjuntar i muntar repositoris, la qual cosa us permet subministrar complements per a la integració amb diversos serveis d'emmagatzematge sense la necessitat de realitzar canvis a la base de codi de Kubernetes.
Per defecte, s'utilitza el servidor DNS CoreDNS.
CoreDNS està escrit en el llenguatge Go i destaca per una arquitectura flexible basada en complements.
Per exemple, funcions específiques com el descobriment de serveis de Kubernetes, l'acumulació de mètriques per al sistema de monitorització de Prometheus i la integració amb el sistema d'emmagatzematge de configuració, etc. s'implementen a través de complements.
Kubeadm s'ha estabilitzat com una interfície simplificada per administrar el clúster Kubernetes, que us permet realitzar operacions com crear i implementar un clúster a l'equip existent, configurar els components bàsics de Kubernete, connectar i eliminar nodes, realitzar operacions d'actualització;
Es presenta una interfície experimental per crear complements per a la integració amb sistemes de monitorització de tercers.
El registre de complements de dispositius Kubelet de servei estabilitzat, que proporciona els mitjans per accedir a Kubelet des de complements.
El programador de distribució de contenidors de TAVS (Topology Aware Volume Scheduling) s'ha estabilitzat, tenint en compte la topologia de les seccions del Pod (tenint en compte les restriccions establertes per als nodes i les zones).
Passem a la fase de prova beta d'APIServer DryRun, a l'equip de Kubectl Diff i la capacitat d'usar dispositius de bloc sense processar com a fonts de dades persistents (font de volum persistent).
Si volen conèixer una mica més sobre aquest nou llançament poden visitar el següent enllaç.