Исследователи из CrowdStrike недавно выпустили статью с интересным названием – Improving Kubernetes Security: Lessons from an Istio Configuration Finding. В статье они рассказывают, как атакующий с возможностью создавать Pod с парой определенных аннотаций от Istio и специально заготовленного образа может сбежать из контейнера (без магии в SecurityContext).

Так например, используя аннотацию sidecar.istio.io/proxyimage, можно задать кастомный образ для sidecar контейнера. А аннотация sidecar.istio.io/enableCoreDump добавляет sidecar контейнеру CAP_SYS_ADMIN capability.

Интересно, что команда Istio не признала это как проблему безопасности, сославшись на то, что пользователь с достаточными привилегиями может запустить такой контейнер и сбежать из него независимо от Istio. Хотя этот аргумент верен, создание такого debug контейнера с возможностью выполнения произвольного кода под прикрытием Istio может значительно затруднить его обнаружение в случае реальной атаки, поскольку sidecar контейнер Istio будет выглядеть гораздо более легитимным, чем неучтенный «обычный» привилегированный контейнер.

Данную ситуацию можно контролировать с помощью Policy Engine, на пример, Kyverno, но и тут надо очень внимательно писать политику. Стандартное контролирование YAML ресурса Pod в разделе Security Context не поможет. Так что как всегда Policy Engine must have!

Однако, после обращения ресерчеров из CrowdStrike, команда Istio немедленно открыла PR, чтобы удалить функциональность четырехлетней давности. 7 октября PR был принят.