Ответ
В моих проектах безопасность Kubernetes обеспечивалась комплексом инструментов:
Контроль доступа и сеть:
- RBAC – детальная настройка через
RoleиClusterRole. Например, создавал роль, разрешающую толькоgetиlistдля pods в конкретном namespace. - Network Policies (Cilium) – изолировал среды. Для продакшена применял политику по умолчанию
deny-all, а затем явно разрешал необходимый трафик между микросервисами.
Безопасность подов и конфигураций:
- Pod Security Admission (PSA) – настраивал namespaces с уровнями
baselineилиrestricted, чтобы блокировать запуск подов с привилегированным режимом или монтированием hostPath. - OPA/Gatekeeper – использовал для enforcement кастомных политик. Например, политика, требующая наличия меток
appиenvу всех ресурсов Deployment. - HashiCorp Vault с injector – для динамического управления секретами. Секреты никогда не хранились в виде Kubernetes Secrets в чистом виде.
Аудит и соответствие:
- kube-bench – запускал как Job в кластере для проверки на соответствие CIS Benchmark, результаты отправлял в SIEM.
- Falco – настраивал правила для детектирования подозрительных действий, например, запуска новых процессов в runtime или неожиданных исходящих сетевых соединений.
Пример NetworkPolicy, которая разрешает только входящий трафик от ingress-контроллера к подам с меткой app: api:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: api-ingress-only
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: nginx-ingress
ports:
- protocol: TCP
port: 8080