Стандарты безопасности в Kubernetes (обзор и видео доклада)20.04.2023 13:16

В этом докладе я расскажу о стандартах безопасности в Kubernetes. Мы рассмотрим, какие правила безопасности действительно необходимы, а также разберем пять шагов, которые помогают решить проблему с безопасностью.

Актуальность вопроса в Kubernetes

Про безопасность знают все, но далеко не всегда делают всё правильно. В итоге нам приходится разбираться с разными последствиями этого.

Почему сегодня вопрос безопасности в Kubernetes приобрел такую остроту?

Ответ прост — Kubernetes уже давно перестал быть хайповой технологией. Сейчас это стандарт, который используется в крупном, малом и среднем бизнесе.

Различные исследования показывают: кластеров под управлением Kubernetes скоро станет еще больше.

Кажется, что чем выше их число, тем лучше. Kubernetes призван решить все наши проблемы: упростить операции, ускорить доставку, увеличить количество деплоев в день и т.д. Что может пойти не так?

В первую очередь на этапе внедрения новой для нас технологии мы сталкиваемся с недостатком экспертизы.

Накапливая ее и перенося все новые и новые рабочие нагрузки в кластер, мы начинаем задумываться о других проблемах. Зачастую в организациях, в которых контейнеры используются практически для всех приложений, безопасность становится главным вызовом.

Как показал опрос Red Hat, лишь 7% респондентов не сталкивались с инцидентами в области безопасности.

Kubernetes должен был ускорить развертывание приложений, но в итоге более половины респондентов откладывали или задерживали деплой приложений из-за проблем с безопасностью в кластере.

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

О стандартах безопасности

Есть множество стандартов безопасности (международные, отечественные), которые говорят нам, как правильно делать Kubernetes.

Одним из самых известных является Kubernetes CIS Benchmark — стандарт от Center for Internet Security.

В нем содержатся конкретные инструкции о том, как сделать кластер безопасным (вплоть до того, какие флаги указать у API-сервера). Описывается, как правильно настроить компоненты control plane, конфигурацию, worker-узлы, политики и так далее.

Еще есть стандарт от Payment Card Industry Security Standards Council (вышел в 2022 году).

В него входят такие крупные платежные системы, как Visa и MasterCard. От CIS Benchmark он отличается тем, что ограничивается рекомендациями о том, как правильно выстроить процессы относительно средств оркестрации в целом. В нем нет советов конкретно для Kubernetes.

Также в 2022 году ФСТЭК выпустила свой стандарт с требованиями по безопасности к средствам контейнеризации.

Кроме того, есть множество других стандартов как от коммерческих, так и от некоммерческих организаций. Их дополняют спецификации и всевозможные чек-листы от компаний, производящих софт, связанный с безопасностью Kubernetes.

Общая идея всех стандартов

Стандартов много, но все они пересекаются между собой и имеют единый смысл. Заключается он в следующем: рассматривать безопасность в Kubernetes следует послойно.

Модель 4C называется так по первым буквам каждого слоя: Code, Container, Cluster и Cloud. В ней для каждого слоя приводятся свои рекомендации по безопасности.

Начинаем со слоя Code и организуем защиту используемых приложений и библиотек. Далее контролируем среду исполнения, ограничиваем доступ к Kubernetes control plane и узлам кластера, и, наконец, настраиваем безопасный доступ к API облака и инфраструктуре.

Понятно, что когда у злоумышленников есть доступ к API облака, неуязвимость кода в контейнере теряет всякое значение: они просто удалят виртуальные машины, скопируют диски и так далее.

Далее мы поговорим о слоях Code, Container и Cluster.

Пять шагов к безопасности в Kubernetes

Изучив все эти стандарты, проанализировав спецификации, пройдя кучу опросников служб информационной безопасности (мы внедряем нашу Kubernetes-платформу у многих Enterprise-клиентов; для этого сначала приходится общаться со службами ИБ и выполнять их требования), мы поняли, что 5 шагов к безопасности достаточно, чтобы удовлетворить 90% требований.

Рассмотрим их подробнее.

Шаг первый: корректная конфигурация кластера Kubernetes

Прежде всего необходимо запустить пресловутый CIS-бенчмарк и проверить, насколько настройка узлов и control plane соответствует тому, что описано в стандарте. Самая распространенная реализация этого стандарта — kube-bench: запустили, прогнали, посмотрели файлы, предупреждения, исправили их, и можно идти дальше.
При возможности следует ограничить сетевой доступ к Kubernetes API, настроить white-листы, включить доступ только через VPN и так далее.
Каждый пользователь должен уникально идентифицироваться при доступе к Kubernetes API. Это нужно для последующего проведения аудита и понимания, кто и какие действия провел; также это пригодится для грануляции RBAC’ов.
Должны выдаваться только необходимые RBAC’и. Например, некий оператор в кластере получает список всех подов. В этом случае не нужно выдавать ему возможность видеть все секреты и тем более редактировать их.

Кажется, что все просто. Но давайте рассмотрим реальные примеры.

Как дела с managed Kubernetes обстоят у российских облачных провайдеров?

Я развернул кластеры у пары провайдеров и запустил CIS-бенчмарк. Ошибок и предупреждений практически не было (тестировались только worker«ы, т.к. не у всех провайдеров доступны control plane-узлы). Затем я посмотрел, как организован доступ в мой только что развернутый кластер — ведь взаимодействие со новым кластером мы всегда начинаем с получения доступа к Kubernetes API.

Скачав kubeconfig, я обнаружил, что внутри используется группа system: masters. При этом в первом пункте чек-листа по безопасности в Kubernetes четко указано: после развертывания кластера никто не должен в нем аутентифицироваться как system: masters.

Сертификат выписан на месяц: если кто-то украдет у меня этот kubeconfig, придется перевыпускать все CA в кластере, потому что отозвать доступ у группы system: masters без этого невозможно.

Как видим, даже облачные провайдеры нарушают базовые принципы, поэтому о них говорить всегда актуально.

Шаг второй: сканирование образов

Теперь настало время подумать о том, какой софт мы будет запускать в кластере, и сделать его хотя бы минимально безопасным. Самым простым решением кажется сканирование используемых образов.

Провести его можно на разных этапах: на этапе конвейера CI/CD, настроить сканирование registry по расписанию или сканировать все образы, которые используются в кластере. Для этого существует множество решений. Каждый выбирает сам, что ему больше подходит — self-hosted или SaaS. Самое главное — следовать базовым принципам.

После сканирования следует проанализировать его результаты.

Нужно смотреть критические проблемы, warning-инциденты, которые у нас возникают, разбирать найденные уязвимости. Самое главное здесь — подходить к вопросу с холодной головой: если мы нашли критическую уязвимость, это еще не значит, что ее можно эксплуатировать.

Также следует использовать базовые образы. Если у нас есть golden image, и мы нашли в нем CVE, то его достаточно просто заменить и перезапустить все CI/CD.

И самый мой любимый момент — не нужно тащить лишние зависимости. Например, всякие инструменты для дебага не должны оказываться в образах для production. Для компилируемых языков собираем артефакт, в нем компилируем бинарный файл, копируем его в golden image, и уже его запускаем в production. Чем больше лишних зависимостей, тем выше риск обнаружить в них CVE.

Шаг третий: сетевая безопасность

Итак, мы собрали приложение и подготовили его к работе. Теперь нужно подумать, как запускать его в нашем новом классном кластере Kubernetes.

И первым в голову приходит то, что нужно сделать его безопасным именно с точки зрения сети:

CNI в кластере должен поддерживать сетевые политики;
Ingress и egress-политики должны быть настроены для всех компонентов кластера;
все соединения по умолчанию должны быть явно разрешены.

На практике я сталкивался с тем, что клиенты обращаются к нам за аудитом. Говорят, что у них все хорошо, Kubernetes развернут, все ходят со своими сертификатами… В итоге мы и правда видим: у разработчиков есть доступ только в пространство имен stage.

При этом живут клиенты в «коммунальном» кластере — многие клиенты, в том числе Enterprise-уровня, разворачивают несколько больших кластеров, в которых stage и production существуют в рамках одного control plane. Разработчики спокойно хотят в stage, но оттуда могут попадать куда угодно, в том числе и в production-базы данных, потому что сегментация сети и сетевая изоляция отсутствуют.

Такое часто встречается на практике. Что с этим можно сделать?

У себя в платформе мы используем Cilium. В нем есть визуальный редактор, в котором буквально в три клика можно настроить подходящую политику. Она разрешит разработчику ходить только в рамках своего пространства имен и обращаться к Kubernetes DNS.

Вот так выглядит созданная egress-политика:

egress:
   - toEndpoints:
       - matchLabels:
           io.kubernetes.pod.namespace: kube-system
           k8s-app: kube-dns
     toPorts:
       - ports:
           - port: "53"
             protocol: UDP
         rules:
           dns:
             - matchPattern: "*"
   - toEndpoints:
       - {}

В данном случае она решает все проблемы.

Разработчик может ходить в БД только в рамках stage и не может попадать в production.

Бывают и еще более ужасные вещи, когда пароли и названия stage- и production-баз совпадают. Если у разработчиков или инженеров достаточно пытливый ум, то запросы из stage начинают лететь в production-базу.

Политики необходимо внедрять также в случае, если у каждого сервиса свой отдельный кластер.

Давно пора уйти от правила «доверяй, но проверяй» или считать, что все, что разворачивается в закрытый контур, по умолчанию безопасно. Нужно отслеживать и понимать, кто и куда обращается. Это очень важно.

Кроме того, необходимо внедрить подход «политики как код». Он идентичен подходу «инфраструктура как код» и означает, что политики безопасности деплоятся вместе с приложением из Git-репозитория.

Внедрять все это необходимо на самом старте — в этот момент соответствующие практики привить гораздо проще. При введении нового компонента сразу должны описываться его сетевые взаимодействия и разворачиваться политики. В уже работающую инфраструктуру внедрять политики гораздо сложнее.

Шаг четвертый: контроль над запускаемыми приложениями

Мы обсудили сетевую безопасность, но остается еще такое понятие, как runtime — хост, на котором будет запускаться наш контейнер.

Запрос в Kubernetes проходит достаточно длинную цепочку. Одним из ее элементов является Admission Controller, который валидирует создаваемые в кластере объекты.

В Kubernetes 1.23 есть Pod Security Admission, который закрывает базовые потребности.

Существуют Pod Security Standards, которые, среди прочего, запрещают запускать поды от root, использовать host network и так далее. Если этих политик недостаточно, можно воспользоваться следующими вариантами:

В каких случаях стандартов Pod Security Standards недостаточно? Мы у себя в платформе составили список этих случаев и создали CRD OperationPolicy, которое работает поверх ресурсов Gatekeer. Пример его конфигурации:

apiVersion: deckhouse.io/v1alpha1
kind: OperationPolicy
metadata:
  name: common
spec:
  policies:
    allowedRepos:
      - myregistry.example.com
    requiredResources:
      limits:
        - memory
      requests:
        - cpu
        - memory
    disallowedImageTags:
      - latest
    requiredProbes:
      - livenessProbe
      - readinessProbe
    maxRevisionHistoryLimit: 3
    imagePullPolicy: Always
    priorityClassNames:
    - production-high
    checkHostNetworkDNSPolicy: true
    checkContainerDuplicates: true
  match:
    namespaceSelector:
      labelSelector:
        matchLabels:
         operation-policy.deckhouse.io/enabled: "true"

Пользователям рекомендуем сразу настраивать этот инструмент. В него входят следующие базовые принципы:

Самые важные, по моему мнению, точки контроля:

не разрешаем разработчикам использовать образы напрямую с Docker Hub в определенных пространствах имен, требуя конфигурации доверенного registry.
заставляем использовать priorityClass’ы.

В своей практике я нередко сталкивался с ситуациями, когда, например, у системы логирования приоритет был выше, чем у бэкенда. Результат — не совсем корректная работа системы в целом.

Какие вещи в целом закрывает Admission Controller?

Самый яркий пример — довольно старая CVE от 2019 года, до сих пор сохраняющая актуальность: если запустить контейнер от root, можно получить доступ к хосту. Риски стать жертвой этой уязвимости многократно повышаются, если разработчикам разрешено запускать образы из любых недоверенных registry.

В завершение этого шага хочется подчеркнуть, что описывать политики безопасности приложений просто необходимо. Больше контроля — меньше вероятность возникновения ошибки, а значит и ниже вероятность стать жертвой уязвимости.

Шаг пятый: аудит и регистрация событий

После запуска приложения хочется понимать, что происходит внутри Kubernetes и всей системы.

Речь сейчас не про мониторинг и снятие метрик с подов. Речь про аудит событий.

В Kubernetes встроен классный аудит «из коробки» — аудит Kubernetes API, который очень легко настроить. Пишем логи в файл или в stdout, собираем и отгружаем в систему сбора логов, а уже в ней — анализируем.

Пример простой политики сборки запросов, которые отправляются к ресурсам типа pods:

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
 - RequestReceived
rules:
 - level: RequestResponse
   resources:
   - group: ""
     resources: ["pods"]

В результате мы получаем вот такой лог:

{
 "kind": "Event",
 "apiVersion": "audit.k8s.io/v1",
 "level": "RequestResponse",
 "auditID": "28eff2fc-2e81-41c1-980b-35d446480e77",
 "stage": "ResponseComplete",
 "requestURI": "/api/v1/namespaces/default/pods/nginx-6799fc88d8-5p7x5",
 "verb": "delete",
 "user": {
   "username": "system:serviceaccount:d8-service-accounts:gitlab-runner-deploy",
   "uid": "fd5a6209-c893-4b77-adf7-90500ecd2723",
   "groups": [
     "system:serviceaccounts",
     "system:serviceaccounts:d8-service-accounts",
     "system:authenticated"
   ]
 },
...

Здесь видно, что сервисный аккаунт удалил под NGINX.

Достаточно ли этого? На самом деле нет.

Помимо сборки таких событий, их необходимо и анализировать. Если сервисный аккаунт удалил под или создал какой-то ресурс в production, то, вероятно, это легитимная операция, потому что мы что-то деплоим. А вот если простой пользователь со своей учеткой пошел что-то править и создавать в production, то это уже проблема. Хотелось бы получить о ней алерт и узнать, что в кластере какая-то подозрительная активность.

Также необходимо регистрировать события непосредственно в хостовой ОС и в среде исполнения. Например, команда crictl exec не пройдет через аудит Kubernetes API, и мы не узнаем, что кто-то вошел в под, хотя знать это хотелось бы. Плюс хотелось бы иметь информацию о том, какие вообще процессы запускаются внутри контейнеров.

Для решения таких вопросов есть приложения, которые реализуют runtime security. В Deckhouse мы используем для этого Falco. Он выполняет следующие функции:

разбор системных вызовов на хосте;
получение аудит-лога от Kubernetes API через Webhook backend;
проверка потока событий с помощью сконфигурированных правил;
отправка алертов в случае нарушения правил.

Схема работы:

У нас есть ядро, в нем есть технология eBPF, которая собирает системные вызовы, есть вебхук, который собирает события с Kubernetes API, есть Falco с загруженными правилами. Он проверяет поступающие события на соответствие этим правилам и в случае чего передает данные в алертинг-систему.

Falco разворачивается в виде DaemonSet’а на все узлы кластера.

Как выглядит под с Falco?

В нем есть:

init-контейнер, в котором загружается eBPF-программа;
Falco, собирающий события и обогащающий их метаданными;
shell-operator, который собирает Falco audit rules[c] и подготавливает правила для Falco;
метрики отдаем с помощью falcosidekick;
доступ к метрикам ограничен с помощью kube-rbac-proxy.

Falco audit rules также выполнены в виде Custom Resource, что дает возможность проверки относительно OpenAPI спецификации, а также это просто удобнее — работать с примитивами Kubernetes:

apiVersion: deckhouse.io/v1alpha1
kind: FalcoAuditRules
metadata:
 name: host-audit-custom
spec:
 rules:
 - list:
     name: cli_proc_names
     items: [crictl, docker]
 - macro:
     name: spawned_process
     condition: (evt.type in (execve, execveat) and evt.dir=<)
 - rule:
     name: Crictl or docker cli are executed
     desc: Detect ctl or docker are executed in cluster
     condition: spawned_process and proc.name in (crictl, docker)
     output: Crictl or docker are executed (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline pid=%proc.pid parent_process=%proc.pname)
     priority: Warning
     tags: [host]

Созданные Falco audit rules на лету трансформируются в обычные Falco-правила:

- items:
 - crictl
 - docker
 list: cli_proc_names
- condition: (evt.type in (execve, execveat) and evt.dir=<)
 macro: spawned_process
- condition: spawned_process and proc.name in (cli_proc_names)
 desc: Detect crictl or docker are executed in cluster
 enabled: true
 output: Crictl or docker are executed (user=%user.name user_loginuid=%user.loginuid
   command=%proc.cmdline pid=%proc.pid parent_process=%proc.pname)
 priority: Warning
 rule: Crictl or docker cli are executed
 source: syscall
 tags:
 - host

Falco-правило содержит листы и макросы, позволяющие переиспользовать кусочки коды и писать более понятные и лаконичные условия.

По приведенному выше правилу в логах мы увидим следующее:

{
  "hostname": "demo-master-0",
  "output": "14:17:03.188306224: Warning Crictl or docker are executed (user= user_loginuid=1000 command=crictl ps pid=273049 parent_process=bash) k8s.ns= k8s.pod= container=host",
  "priority": "Warning",
  "rule": "Crictl or docker cli are executed",
  "source": "syscall",
  "tags": [
    "host"
  ],
  "time": "2023-03-14T14:17:03.188306224Z",
  "output_fields": {
    "container.id": "host",
    "evt.time": 1678803423188306200,
    "k8s.ns.name": null,
    "k8s.pod.name": null,
    "proc.cmdline": "crictl ps",
    "proc.pid": 273049,
    "proc.pname": "bash",
    "user.loginuid": 1000,
    "user.name": ""
  }
}
{
  "hostname": "demo-master-0",
  "output": "14:43:34.760338878: Warning Crictl or docker are executed (user= user_loginuid=1000 command=crictl stop 067bd732737af pid=307453 parent_process=bash) k8s.ns= k8s.pod= container=host",
  "priority": "Warning",
  "rule": "Crictl or docker cli are executed",
  "source": "syscall",
  "tags": [
    "host"
  ],
  "time": "2023-03-14T14:43:34.760338878Z",
  "output_fields": {
    "container.id": "host",
    "evt.time": 1678805014760339000,
    "k8s.ns.name": null,
    "k8s.pod.name": null,
    "proc.cmdline": "crictl stop 067bd732737af",
    "proc.pid": 307453,
    "proc.pname": "bash",
    "user.loginuid": 1000,
    "user.name": ""
  }
}

Пользователь с UID 1000 запустил команду crictl ps или crictl stop.

Правила Kubernetes Audit выглядят примерно так же:

- required_plugin_versions:
   - name: k8saudit
     version: 0.1.0
- macro: kevt_started
 condition: (jevt.value[/stage]=ResponseStarted)
- macro: pod_subresource
 condition: ka.target.resource=pods and ka.target.subresource exists
- macro: kcreate
  condition: ka.verb=create
- rule: Attach/Exec Pod
 desc: >
   Detect any attempt to attach/exec to a pod
 condition: kevt_started and pod_subresource and kcreate and ka.target.subresource in (exec,attach)
 output: Attach/Exec to pod (user=%ka.user.name pod=%ka.target.name resource=%ka.target.resource ns=%ka.target.namespace action=%ka.target.subresource command=%ka.uri.param[command])
 priority: NOTICE
 source: k8s_audit
 tags: [k8s]

В них также есть макросы, листы и все то, что умеет Falco. Например, это правило в логах отобразит, что кто-то пошел в под через Kubernetes API:

{
  "hostname": "demo-master-0",
  "output": "18:27:29.160641000: Notice Attach/Exec to pod (user=admin@example.com pod=deckhouse-77f868d554-8zpt4 resource=pods ns=d8-system action=exec command=mkdir)",
  "priority": "Notice",
  "rule": "Attach/Exec Pod",
  "source": "k8s_audit",
  "tags": [
    "k8s"
  ],
  "time": "2023-03-14T18:27:29.160641000Z",
  "output_fields": {
    "evt.time": 1678818449160641000,
    "ka.target.name": "deckhouse-77f868d554-8zpt4",
    "ka.target.namespace": "d8-system",
    "ka.target.resource": "pods",
    "ka.target.subresource": "exec",
    "ka.uri.param[command]": "mkdir",
    "ka.user.name": "admin@example.com"
  }
}

Но просто генерировать метрики недостаточно. Администратор кластера должен получать информацию о том, что в кластере происходит подозрительная активность. Поскольку все метрики отправляются в Prometheus, нужно создать для них правило:

apiVersion: deckhouse.io/v1
kind: CustomPrometheusRules
metadata:
 name: runtime-audit-pod-exec
spec:
 groups:
 - name: runtime-audit-pod-exec
   rules:
   - alert: RuntimeAuditPodExecAlerts
     annotations:
       description: |
         There are suspicious attach/exec operations.
         Check your events journal for more details.
       summary: Falco detected a security incident
     expr: |
       sum(rate(falco_events{rule="Attach/Exec Pod"}[5m])) > 0

Их можно настроить либо на конкретные события Falco, либо на события с определенным уровнем критичности.

Самое ценное, что есть в Falco — это Falco-правила. Они глубоко кастомизируемые, их нужно писать под конкретные приложения и под конкретную инфраструктуру. У нас есть набор базовых правил, которые можно посмотреть на GitHub.

Перечень полезных правил:

Я часто слышу, что аудит и регистрация событий нужны только компаниям enterprise-уровня для прохождения сертификаций, но это не совсем так. Falco очень полезен для разбора инцидентов, в том числе не связанных с безопасностью. Например, для поиска сбойных операторов в кластере, осуществивших нелегитимное удаление каких-то подов.

Одним их самых важных элементов аудита и регистрации событий является реагирование на угрозы — администратор должен сразу получать уведомления о том, что в кластере происходит что-то, что требует внимания.

Заключение

Безопасность — это циклический процесс. Всегда есть куда двигаться.

Постоянно появляются новые угрозы, новые технологии. Вопрос безопасности Kubernetes до конца не решен и требует внимания.

Сам по себе Kubernetes — это большая система, в которую необходимо устанавливать дополнительные компоненты, чтобы повысить безопасность. И здесь самое главное не забывать уделять время организации этой безопасности. Очень часто бизнес хочет как можно быстрее развернуть Kubernetes, быстрее перевести туда приложения, а на безопасность не остается времени. В таком случае нужно внедрить хотя бы часть описанных выше решений, которые закроют основные проблемы.

Если времени совсем нет, стоит посмотреть в сторону готовых решений. Есть как отечественные вендоры, поставляющие софт для безопасности в кластере, так и зарубежные. Также можно рассмотреть вариант с готовыми платформами, которые способны закрыть многие вопросы безопасности.

Видео и слайды

Видеозапись выступления (~50 минут):

Презентация:

P.S.

Читайте также в нашем блоге: