📊 От учётки разработчика до облака: GitLab-раннер разрешил цепочку без эксплойтов Как показал пентест, описанный на habr_infosec, стартовой точкой хватило учётки разработчика в GitLab. Раннер PROD-K8S-RUNNER01 состоял в группе docker — типовое упущение. С его помощью через Docker-сокет запустили контейнер с монтированием хостовой файловой системы и добавили свой SSH-ключ в /root/.ssh/authorized_keys: так получили root без единого эксплойта. На хосте нашли kubeconfig с правами, фактически дающими контроль над кластером, и поднял привилегированный под с hostPath, чтобы добраться до ноды. Там, в /etc/kubernetes, лежал cloud-config OpenStack с учётными данными. → kubeconfig давал права на secrets, pods/exec, bindings create — прямой путь к cluster-admin → облачная учётка имела роли управления инстансами, сетями, дисками, образами и оркестрацией в OpenStack → вся цепочка: GitLab → docker group → root → kubeconfig → нода K8s → облако — ни одного CVE Аудит по чеклистам здесь бесполезен: каждый компонент сам по себе выглядит допустимым. Опасна связность. Если кто-то положил kubeconfig на раннер для отладки, а пентестер его подобрал — виновата не только группа docker, но и культура «временных» решений. Остановить такую цепочку можно лишь запретив привилегированные поды, убрав docker-сокет у раннеров и сделав сервисные токены короткоживущими — но всё это потребует пересборки конвейеров и отказа от привычных компромиссов. #GitLab #Docker #Kubernetes #OpenStack #PrivilegeEscalation