В рамках конференции Cloud Native Rejekts 2024 прошел доклад “Malicious Compliance Automated: When You Have 4000 Vulnerabilities and only 24 Hours Before Release” от Duffie Cooley и Kyle Quest. Данный доклад является логическим развитием одного из моим самых любимых докладов за последнее время "Malicious Compliance: Reflections on Trusting Container Image Scanners" =)

В новом докладе авторы обманывали сканеры уязвимостей всеми правдами и неправдами уже не в ручную, а автоматизировано и получили результат с нескольких тысяч уязвимостей до 0 =) В основном для это авторы использовали инструмент mint.

Кто там сторонник zero tolerance к уязвимостям?! В общем сезон образов без уязвимостей объявляется открытым!

Как думаете, насколько опасна такая Role?

```

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-exec-view-role
rules:
- apiGroups: [""]
resources: ["pods/exec"]
verbs: ["get"]

```

Если вы думали, что только Role/ClusterRole с правами create – pods/exec может позволить пользователю делать exec в Pod, то вы ошибались. Благодаря особенностям работы Websockets, прав get – pods/exec будет достаточно, чтобы выполнять команды в Pod.

Что ещё более интересно, так это то, что такое поведение уже было давно в Kubernetes, но вы могли его не заметить, поскольку по умолчанию для exec использовался SPDY протокол, а не Websockets. О проблеме известно с 2019 года!

Чтобы получить exec при правах get – pods/exec, например, можно воспользоваться wscat:

```

wscat -s "base64url.bearer.authorization.k8s.io.$token, base64.channel.k8s.io" -n -c 'wss://192.168.99.100:8443/api/v1/namespaces/default/pods/testpod/exec?container=testpod&command=sh&stdout=true&stderr=true&stdin=true&tty=true'

```

Однако, начиная с версии Kubernetes 1.31 для операций attach, exec и port\-forward теперь по умолчанию используется Websockets, а это значит, что прав get – pods/exec будет достаточно, чтобы выполнять команды в Pod.

Нельзя не упомянуть свежую заметку Rory McCune – When is read-only not read-only?, в которой он рассказал об этой особенности.

Продолжая тематику Kubernetes Network Security, Rory McCune представил новую заметку в своем блоге – Exploring A Basic Kubernetes Network Plugin.

Статья объясняет, как в Kubernetes кластере Pods получают IP-адреса через сетевые плагины, соответствующие спецификации CNI. В примере используется kind с плагином kindnetd.

Конфигурация сети хранится в файле 10\-kindnet.conflist, где указаны IP-диапазоны для каждого узла. Для маршрутизации трафика между подами на разных узлах kindnetd создает записи в таблице маршрутизации. В завершение автор отмечает, что работа с сетью в Kubernetes может быть сложной и зависит от выбранного сетевого плагина.

Когда-то на канале мы рассказывали о фишке, которая может быть полезна при пентесте в Kubernetes окружении – получение адресов всех сервисов в Kubernetes через dig:

```

dig SRV +short any.svc.cluster.local

```

Но, начиная с версии CoreDNS 1.9 (вышла около двух лет назад) эту возможность выпилили. А значит в свежих версиях Kubernetes этот трюк точно не будет работать.

P.S – тут может помочь k8spider, про который мы рассказывали в одном из предыдущих постов.

Совсем недавно компания RedHat выпустила 30-ти страничный отчёт "The state of Kubernetes security report 2024 edition". В нём довольно много цифр и статистики, но самое важное из этого:

- Обеспокоенность в мисконфигурациях продолжает снижаться из года в год. Тем не менее мисконфиги – это по прежнему одна из основных и частых проблем в безопасности Kubernetes кластеров (наши аудиты тому подтверждение)

- Уязвимостей с каждым годом становится только больше. Их нужно правильно триажить и приоритезировать

- Большинство респондентов ответило, что за последний год хотя бы раз сталкивались с инцидентами в рантайме

- Большая часть организаций признают ценность DevSecOps и способствуют сотрудничеству между DevOps и командами безопасности

Сегодня хотим поделиться небольшой утилитой incert, которая позволяет в одну команду изменить docker image, добавить в него CA сертификат и запушить обновленный образ в registry. Например, так:

```

$ incert -image-url=mycompany/myimage:latest -ca-certs-file=/path/to/cacerts.pem -dest-image-url=myregistry/myimage:latest

```

Саму тулзу можно посмотреть здесь, а в видео Adding Certificates to Container Images with Incert | Chainguard можно посмотреть какие проблемы она решает и как работает.

Для того чтобы блокировать операции над subresources, вроде pods/exec или pods/portforward, необходимо внести некоторые изменения в конфигруацию вебхуков PolicyEngine. А именно – добавить операцию CONNECT. По умолчанию этой операции нет, и если её не добавить соответствующая политика на запрет использования pods/exec или pods/portforward просто не будет работать.

Но есть и хорошие новости. Если вы используете Kyverno и применяете политику, где задействован такой subresource (для контроля которого нужна операция CONNECT), то Kyverno автоматически пропатчит конфиг своего вебхука и добавит туда нужную операцию.

Про необходимость использования операции CONNECT мы рассазывали тут.

GitHub

[Bug] PodPortForwardOptions · Issue #5345 · kyverno/kyverno

Kyverno Version 1.7.3 Kubernetes Version 1.21.x Kubernetes Platform Other (specify in description) Kyverno Rule Type Validate Description Hello! I'm already using a blocking policy for exec and...