Kubelet authorization. Основной сценарий тут крутится вокруг того, что атакующий может тем или иным способом попасть на Node и завладеть кредами kubelet, которые он использует для общения с Kubernetes API Server, для поднятия привилегий и распространения атаки.Из интересных/важных моментов:
- Команда
kubectl auth can-i --list покажет только права выданные RBAC, а другими authorization modes отображены не будут (а нам тут интересен режим Node authorizer), но их можно индивидуально проверить с помощью kubectl auth can-i
- Проверьте на своих кластерах что данная настройка для kube-apiserver выставлена именно так --authorization-mode=Node,RBAC, что работал и RBAC и Node authorizer
- Отказ в режиме авторизации Node, означает что запрос передается на режим RBAC и он уже там может быть разрешен. На пример, путем накидывания прав на группу system:node
- Обязательно Node authorizer должен работать в связке с NodeRestriction Admission Controller
- Все эти права могут меняться от дистрибутива к дистрибутиву, от инсталляции к инсталляции, так что всегда стоит проверять этот момент.Но для полноты картины в данной теме я бы порекомендовал ознакомиться с исследованием "Kubernetes Control Plane Vulnerability Assessment", о котором мы писали ранее - там раскрыто намного больше деталей.