Выход за пределы pod'а в Kubernetes через монтирование логов

[evg_krsk]

И ни слова о PSP. Странно.

[Wimbo]

Да, вы правы.
Частично такую проблему можно решить с помощью PSP: kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems, а именно AllowedHostPaths. Однако это тоже не защита от симлинков. Мы добавим данный комментарий в статью.

Спасибо.

[evg_krsk]

Вообще, я имел ввиду защиту от запуска под рутом :-)

[gecube]

Опеншифт опять со своим секурити впереди планеты всей.
Теоретически какой-нибудь селинукс и мапирование пользователей внутри контейнера помогло бы.
Обидно, что мейнстрим это куб поверх убунты, а не шифт

[gecube]

Проблема только лишь в том, что не нужно разрешать HostPath.
Выпиливаем HostPath — и уязвимость исчезает.
Действительно же — контейнеру нефиг что-либо делать на файловой системе хоста.
А вот как при этом организовать локальный сторидж верно — вопрос, который остаётся за кадром.

[VolCh]

Сейчас нет возможности проверить: а классический chroot имеет подобную багофичу?

[SlavniyTeo]

Здесь дело не в chroot, а в том что мы одну и ту же символьную ссылку маунтим два раза: внутри контейнера мы переписываем ссылку на /etc/shadow, а читаем её уже с помощью kubectl logs. Выхода за пределы chroot jail не происходит.

Прочитать /etc/shadow хоста изнутри пода не получится.

Все дело в том, что не нужно позволять кому-попало маунтить что-угодно с хостов.

Нормальный подход в данной ситуации:

• с помощью PodSecurityPolicy запрещаем запуск подов под рутом;
• с помощью PodSecurityPolicy запрещаем все volume кроме ConfigMap, Secret, PersistentVolumeClaim + какие вам необходимы, но не HostPath/Local;
• с помощью RBAC запрещаем пользователю создавать PersistentVolume, по требованию создаем для него.

Если уж заговорили про безопасность, то добавить к перечисленному еще и ResourceQuota и NetworkPolicy.

[vanyas]

Или юзать опеншифт, в котором все это включено по дефолту

[angapov]

Если я правильно понял, само по себе монтирование /var/log через hostPath даже с правом записи не несет в себе описанной уязвимости (так работает, например, стандартный fluentd). Нужно запустить под именно привилегированным, а это достаточно редко нужно.

[SlavniyTeo]

Если Вы имеете в виду priveleged, то этого не нужно. Нужно, чтобы пользователь внутри контейнера был root. А это происходит достаточно часто.

[VolCh]

Я бы сказал, что по умолчанию.

[gecube]

Таковых 99% образов на докерхабе (вывод — докерхаб — помойка).