Какие инструменты вы использовали для безопасной работы с Kubernetes?

«Какие инструменты вы использовали для безопасной работы с Kubernetes?» — вопрос из категории Безопасность, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

В моих проектах безопасность 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