В этой заметке речь пойдет о рисках полной или частичной компрометации
Предположим, что в одном из подов развернуто веб приложение уязвимое к
Поэтому, единственным возможным решением данной проблемы является переход на использованием новой версии сервиса
EKS кластера, а в особо запущенных случаях и всего аккаунта AWS, с помощью эксплуатации SSRF (Server Side Request Forgery) уязвимого веб приложения, с использованием сервиса Instance Metadata (IMDSv1). Для начала несколько слов о самом сервисе метаданных, основной задачей которого является предоставление информации о конфигурации сервисов, включая IAM credentials, настройки Security-groups и пр. Сервис IMDS доступен только по не маршрутизируемому (link local) адресу 169.254.169.254 по умолчанию из любого контейнера/пода кластера AWS EKS.Предположим, что в одном из подов развернуто веб приложение уязвимое к
SSRF атаке, успешная эксплуатация этой уязвимости предоставляет атакующему возможность обратиться к сервису IMDS, чтобы получить temporary credentials для IAM роли worker ноды, чтобы далее проанализировать конфигурацию IAM политик с целью повышения привилегии. При этом даже если используется настроенная AWS в традициях лучших практик - managed IAM политика EKSWorkerNodePolicy, потенциальный злодей все равно может нанести ущерб, просто удалив все сетевые интерфейсы ec2:DeleteNetworkInterface, нарушив доступность и reliability ресурсов кластера. Поэтому, единственным возможным решением данной проблемы является переход на использованием новой версии сервиса
IMDSv2, реализация которой предполагает наличие session token при обращении к сервису метаданных, что обеспечивает надежную защиту от SSRF атак. Но несмотря на то, что прошел уже почти год с момента, когда AWS анонсировал полную поддержку IMDSv2 в EKS, подавляющие большинство клиентов пока не спешат переходить на использование новой версии сервиса...😢