Дыры и заборы: безопасность в Kubernetes

Система не может быть надежной, если она не безопасна. Какой смысл говорить о девятках SLO в Kubernetes, если вы даже не знаете, кому прямо сейчас принадлежит ваш кластер?

13 октября состоялся вебинар по безопасности в Kubernetes.

В прямом эфире разобрали настройки безопасности кластера Kubernetes, известные кейсы взлома и манифесты участников.

Поговорили про культуру безопасности в Kubernetes, а еще про вахтерство и карго-культ.

Рассмотрели некоторые нашумевшие взломы Kubernetes (Tesla 2018, TeamTNT 2020 и секретный бонус).

Вместе с участниками атаковади чужой кластер, помайнили на нём и отключили.

[ДенисКвочка]

Здравствуйте.
Только начал изучать Docker, далее на очереди K8s и решил посмотреть это видео ин адванс, так что о методах аутентификации на этих бордах пока не в курсе, так что не бейте за вопрос:
- в 2021 году эти дашборды не поддерживают MFA? По мне так любой дашборд обязан быть настроен на использование MFA, которое и должно на первом этапе решить проблемы взлома через смотрящий не туда дашборд. Или я что-то упустил?
Спасибо.

[serogavalapinaga]

Атака: 1) не совсем понятно при первой атеке, что значит привелегерованый security context, он может создать какой ресурс? ClusterRole и к нему подключить ServiceRole?
Если у меня стоит политика restricted (в развертывании через rancher), то пользователь namespace может выполнить атаку? Права на создание ClusterRole у него отсутствуют. Так же отсуствуют права на создание Role.
Если у меня рабочие поды разворачиваются не на той же ноде, где развернут control plane и etcd, то возможна ли эта атака?
Фраза "зачем приватный ключ", тоже не ясна. Так как приватный ключ может быть един для взаимодействия между нодами и с его помощью можно зайти на любую ноду. Возможно я не прав.
Атака 2: Можем ли мы защититься использованием vault ( например, от hashicorp) от подобной атаки? Стоит ли защищать доступ до prometheus?
Атака 3: Что от нее защищает, если разработчики делают такие дыры?