Ответ
Контроль Egress трафика через NetworkPolicies — это критичный элемент безопасности кластера по модели «запрещено всё, что не разрешено явно». Я настраиваю его, чтобы минимизировать ущерб от скомпрометированного пода.
Проблема без Egress-политик: Если злоумышленник получит доступ в под (например, через уязвимость в приложении), он сможет:
- Установить связь с командным сервером (C2) в интернете.
- Инициировать атаку на внутренние системы компании (сканирование портов, brute force).
- Выгрузить украденные данные на внешний ресурс.
Как я настраиваю Egress на практике:
-
Базовый уровень: Разрешить только необходимые внешние зависимости.
# Разрешаем подам в namespace `monitoring` ходить только в Prometheus и Grafana Cloud apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-monitoring-egress namespace: monitoring spec: podSelector: {} # Применяется ко всем подам в namespace policyTypes: - Egress egress: - to: - ipBlock: cidr: 192.0.2.0/24 # Prometheus vendor IP range ports: - protocol: TCP port: 9090 - to: - ipBlock: cidr: 203.0.113.0/24 # Grafana Cloud IP range ports: - protocol: TCP port: 443 - to: # Разрешаем DNS — обязательно! - namespaceSelector: {} podSelector: matchLabels: k8s-app: kube-dns ports: - protocol: UDP port: 53 -
Продвинутый уровень: Использование Egress Gateway (например, через Istio). Это позволяет:
- Централизованное логирование всех исходящих запросов.
- Применение TLS-шифрования даже для трафика внутри кластера до выхода.
- Блокировка по доменным именам (FQDN), а не только по IP, что решает проблему CDN с плавающими IP-адресами.
Итог: Egress-контроль — это не просто «запретить интернет», а создание четких, документированных правил выхода наружу, что является требованием многих стандартов безопасности (PCI DSS, SOC2).