конспект лекций, вопросы к экзамену

Лучшие практики безопасности для контейнерных приложений при использовании Kubernetes

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

Концепции

Каждый контейнер является частью (N-уровневой архитектуры) приложения и основан на изображении (статический файл с исполняемым кодом, который может создавать контейнер).

  • Pod - это группа из одного или нескольких контейнеров.
  • Пространство имен - это логическая группа модулей с одной или несколькими службами.
  • Узел (может быть виртуальной машиной) содержит службы, необходимые для запуска модулей, и управляется главными компонентами. Службы на узле включают среду выполнения контейнера.

Служба - это абстракция для создания логического набора модулей, не зависящих от IP-адресов (интерфейс и серверная часть одного и того же приложения). Этот паттерн называется микросервисом.

Архитектура сервисов с модулями
  • Кластер - это набор узлов, на которых выполняются контейнерные приложения.
Архитектура Kubernetes

Соображения безопасности

Безопасность изображения

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

С https://hub.docker.com/search?type=image с более чем 8M доступными и официальными изображениями

Безопасность контейнеров

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

Рекомендации по безопасности изображений

Выполните проверку изображений, аудит и управление:

  • Используйте минимальные базовые изображения
  • Предпочитайте изображения с меньшим количеством инструментов и библиотек, чтобы уменьшить поверхность для атаки
  • Сканируйте образы докеров как часть непрерывной интеграции (многие инструменты с открытым исходным кодом позволяют этот контроль: например, Clair)

Лучшие практики по обеспечению безопасности контейнеров

Политики безопасности Pod

Используйте ограничительные политики безопасности Pod, которые требуют:

  • Пользователи для запуска от имени непривилегированного пользователя
  • Блокирует возможные переходы к корневому каталогу, чтобы избежать доступа корневых контейнеров.
  • Сведите к минимуму допуск контейнеров в RootFilesystem, чтобы избежать контейнеров, которые могут писать в корневую файловую систему, поскольку их корневая файловая система должна быть неизменной.
apiVersion: policy / v1beta1
вид: PodSecurityPolicy
метаданные:
имя: ограничено
аннотации:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'докер / по умолчанию, время выполнения / по умолчанию'
apparmor.security.beta.kubernetes.io/allowedProfileNames: 'время выполнения / по умолчанию'
apparmor.security.beta.kubernetes.io/defaultProfileName: 'время выполнения / по умолчанию'
спецификация:
привилегированный: ложь
# Требуется для предотвращения эскалации до root.
allowPrivilegeEscalation: ложь
requiredDropCapabilities:
- ВСЕ
# Разрешить основные типы томов.
тома:
- 'configMap'
- 'emptyDir'
- 'прогнозируемый'
- "секрет"
- 'downwardAPI'
# Предположим, что эфемерные драйверы CSI и persistentVolumes, установленные администратором кластера, безопасны для использования.
- 'csi'
- 'persistentVolumeClaim'
- эфемерный
hostNetwork: ложь
hostIPC: ложь
hostPID: ложь
runAsUser:
# Требовать запуск контейнера без привилегий root.
правило: 'MustRunAsNonRoot'
seLinux:
# Эта политика предполагает, что узлы используют AppArmor, а не SELinux.
правило: RunAsAny
дополнительныеГруппы:
правило: 'MustRunAs'
диапазоны:
# Запретить добавление корневой группы.
- мин: 1
макс: 65535
fsGroup:
правило: 'MustRunAs'
диапазоны:
# Запретить добавление корневой группы.
- мин: 1
макс: 65535
readOnlyRootFilesystem: ложь

Сетевые политики

Каждый модуль может связываться с комбинацией следующего:

  • Сам: под не может заблокировать доступ к себе
  • Другой модуль: чтобы вы могли создавать сетевую политику на основе модулей.
  • Разрешенные пространства имен: чтобы вы могли создавать сетевые политики на основе пространств имен.
  • IP-блоки, чтобы вы могли определять политики на основе IP-блоков (трафик к узлу, на котором работает Pod, и от него, всегда разрешен)

Зачем использовать пространства имен? При определении NetworkPolicy на основе пода или пространства имен вы используете селектор, чтобы указать, какой трафик разрешен к и от подов, которые соответствуют селектору.

apiVersion: extension / v1beta1
вид: NetworkPolicy
метаданные:
имя: policy-one
спецификация:
podSelector:
matchLabels:
роль: серверная часть
вход:
- от:
- podSelector:
matchLabels:
роль: интерфейс
порты:
- протокол: tcp
порт: 80

Калико

Когда вам нужно расширить брандмауэр на Kubernetes, Calico - это зрелое и задокументированное решение с открытым исходным кодом. Он обеспечивает микросегментацию между хостами / виртуальными машинами / контейнерами, а также обнаружение и предотвращение вторжений (IDS / IPS) для Kubernetes и интеграции SIEM.

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

логирование

При использовании Kubernetes вы можете обращаться к стеку EFK (с Fluentd вместо Logstash стека ELK ). Установленный на уровне узла Fluent, он будет собирать и отправлять журналы для Elasticsearch. Инструментарий ведения журнала должен быть установлен в пространстве имен. Elasticsearch - это база данных, в которой хранятся журналы, сборщик fluentd и кибана для информационных панелей в качестве сервиса k8s.

Вывод

Контролируйте весь жизненный цикл контейнера от сборки (со сканированием изображений), во время доставки (контроль ресурсов, безопасность реестра и контроль доступа пользователей к ресурсам) до работы с механизмами безопасности контейнера (такими как PSP и сетевые политики).

Это должно дополнять передовой опыт, связанный с инфраструктурой, такой как:

  • Применение подхода RBAC для управления кластером Kubernetes
  • Внутренняя / внешняя сегментация сети
  • Решение DDoS, WAF и брандмауэры, связанные с облачным провайдером или инфраструктурой, когда они доступны в Интернете.
  • Контейнер должен быть уничтожен и перестроен с использованием обновленного базового образа при необходимости исправления.
05.03.2022; 05:00
просмотров: 32