Detalle de la noticia

Vulnerabilidad

Cómo un único archivo YAML de Kubernetes puede transferir una organización de GCP

Fuente: BleepingComputer Publicado: 23/09/2026 · 14:01 UTC
Compartir:
Vulnerabilidad Cómo un único archivo YAML de Kubernetes puede transferir una organización de GCP
Imagen: BleepingComputer

Para evi­tar el pro­ble­ma de dis­per­sión de cre­den­cia­les en la nube, la co­mu­ni­dad de Ku­ber­ne­tes uti­li­za con­tro­la­do­res Gi­tOps que per­mi­ten a los de­sa­rro­lla­do­res ges­tio­nar re­cur­sos me­dian­te ar­chi­vos de con­fi­gu­ra­ción en for­ma­to YAML. En Goo­gle Cloud, la he­rra­mien­ta uti­li­za­da para este fin es Goo­gle Ku­ber­ne­tes Con­fig Con­nec­tor (KCC), que se eje­cu­ta en un clús­ter de GKE y pro­ce­sa estas so­li­ci­tu­des em­plean­do su pro­pia cuen­ta de ser­vi­cio, la cual suele po­seer pri­vi­le­gios ele­va­dos para ad­mi­nis­trar in­fra­es­truc­tu­ra a nivel de or­ga­ni­za­ción o de pro­yec­to sin que los de­sa­rro­lla­do­res ne­ce­si­ten cre­den­cia­les di­rec­tas.

Esta con­fi­gu­ra­ción, sin em­bar­go, ge­ne­ra una vul­ne­ra­bi­li­dad co­no­ci­da como Con­fig­Con­fu­sion, des­cu­bier­ta por un in­ves­ti­ga­dor de se­gu­ri­dad. Un ata­can­te con ac­ce­so li­mi­ta­do a un es­pa­cio de nom­bres (na­mes­pa­ce) en Ku­ber­ne­tes y per­mi­sos para crear re­cur­sos es­pe­cí­fi­cos puede uti­li­zar­los in­di­rec­ta­men­te para asig­nar­se el rol de pro­pie­ta­rio en toda la or­ga­ni­za­ción de Goo­gle Cloud. El pro­ble­ma ra­di­ca en que Ku­ber­ne­tes va­li­da úni­ca­men­te los per­mi­sos den­tro del clús­ter, mien­tras que Goo­gle Cloud solo ve­ri­fi­ca los per­mi­sos de la cuen­ta de ser­vi­cio de KCC, ca­yen­do en un es­ce­na­rio tí­pi­co de "dipu­tado con­fu­so" (con­fu­sed de­puty) donde se eje­cu­tan ac­cio­nes con más au­to­ri­dad de la que posee el usua­rio ori­gi­nal.

Ante este ha­llaz­go, la pos­tu­ra de Goo­gle ha sido con­si­de­rar que KCC fun­cio­na tal como fue di­se­ña­do y que los ries­gos de­ri­van de de­ci­sio­nes de con­fi­gu­ra­ción del ad­mi­nis­tra­dor al otor­gar per­mi­sos am­plios. Im­ple­men­tar una so­lu­ción que va­li­de la iden­ti­dad en la nube de cada usua­rio rom­pe­ría el mo­de­lo ope­ra­ti­vo ori­gi­nal de la he­rra­mien­ta. No obs­tan­te, pro­ble­mas si­mi­la­res de ar­qui­tec­tu­ra de ope­ra­do­res de in­fra­es­truc­tu­ra ocu­rren en otras pla­ta­for­mas como AWS y Azure, aun­que estas úl­ti­mas im­ple­men­tan me­di­das para li­mi­tar el al­can­ce de los per­mi­sos por ser­vi­cio o por es­pa­cio de nom­bres.