Лучше изолировать etcd от остального control-plane в отдельной подсети, разрешить к нему доступ только из доверенных источников и только при верификации сертификатов. Например у нас есть пайплайн который создает определенные ippools в calico с нужным октетом, для этого с билд-сервера нужна связность до etcd кластера и определенные сертификаты для доступа на чтение или запись.
К Kubelet доступ не ограничивается сетевыми политиками (если только к метрикам), а вот к api-server можно и нужно. Для анализа источников запросов можно использовать инструмент https://github.com/kinvolk/inspektor-gadget. Мы проанализировали трафик с кластеров, и оставили доступ к api только тем приложениям, которым он действительно нужен, а для остальных ограничили доступ написав специальный NetworkPolicy
Да, чтобы использовать этот функционал мы обновились на свежую версию Calico, сейчас комбинируем как внешние фаервольные решения так и внутренние
Конечно!
Лучше изолировать etcd от остального control-plane в отдельной подсети, разрешить к нему доступ только из доверенных источников и только при верификации сертификатов. Например у нас есть пайплайн который создает определенные ippools в calico с нужным октетом, для этого с билд-сервера нужна связность до etcd кластера и определенные сертификаты для доступа на чтение или запись.
К Kubelet доступ не ограничивается сетевыми политиками (если только к метрикам), а вот к api-server можно и нужно. Для анализа источников запросов можно использовать инструмент https://github.com/kinvolk/inspektor-gadget. Мы проанализировали трафик с кластеров, и оставили доступ к api только тем приложениям, которым он действительно нужен, а для остальных ограничили доступ написав специальный NetworkPolicy
Да, чтобы использовать этот функционал мы обновились на свежую версию Calico, сейчас комбинируем как внешние фаервольные решения так и внутренние