Привет, Хабр!

Меня зовут Рустем Галиев, я Senior DevOps Engineer в IBM, и мы продолжаем разбираться, как искать и эксплуатировать уязвимости в контейнеризированных средах на примере практических атак. Это третья часть, ссылки на первые две:

Часть первая

Часть вторая

Неправильное хранение чувствительных данных

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

Хранение секретов в контейнере в незашифрованном виде — это одна из распространённых ошибок безопасности, которая делает контейнеры уязвимыми. Даже если злоумышленнику удаётся получить доступ к контейнеру, его основная цель часто — это не сам контейнер, а ценные данные внутри него, такие как пароли, токены доступа, API-ключи и другие секреты, которые могут быть использованы для доступа к другим системам.

Как хранение секретов в контейнере повышает риски

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

• Прямой доступ к незашифрованным секретам: Если секреты сохранены в виде переменных среды или файлов в контейнере, злоумышленник, получив доступ к контейнеру, может просто считать их. Эти данные могут использоваться для проникновения в другие системы или для получения доступа к аккаунтам пользователей.

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

• Захардкоденные секреты в Dockerfile или образах: Если ключи или пароли захардкожены в Dockerfile, они становятся частью образа и будут присутствовать в каждом экземпляре контейнера. Это делает секреты доступными для любого, у кого есть доступ к образу или истории его изменений.

Чтобы защитить секреты и снизить риски утечки конфиденциальной информации, можно использовать следующие методы:

Использование специализированных инструментов управления секретами

Инструменты для управления секретами, такие как HashiCorp Vault, AWS Secrets Manager или Azure Key Vault, предоставляют безопасное хранилище и управление доступом для конфиденциальных данных. Эти решения шифруют секреты и позволяют контейнерам получать к ним доступ только по необходимости:

• HashiCorp Vault: Позволяет безопасно хранить и получать секреты через API. Он поддерживает динамическую генерацию и управление доступом.

• AWS Secrets Manager: Автоматически шифрует секреты и позволяет использовать IAM для управления доступом. Подходит для интеграции с приложениями, запущенными в AWS.

Использование Docker Secrets для Swarm

Если вы используете Docker Swarm, то Docker Secrets — это встроенный механизм управления секретами. Docker Secrets позволяет хранить конфиденциальные данные, такие как пароли и API-ключи, за пределами образа, в зашифрованном виде. Пример использования Docker Secrets:

# Создать секрет в Swarm

echo "my_secret_password" | docker secret create db_password -

# Использовать секрет в сервисе

docker service create \

  --name my_service \

  --secret db_password \

  my_image

Секреты, переданные через Docker Secrets, хранятся в памяти контейнера и не записываются в файловую систему, что делает их более защищёнными.

Использование Kubernetes Secrets

Kubernetes предлагает Kubernetes Secrets для управления конфиденциальными данными. Kubernetes Secrets позволяют хранить секреты в зашифрованном формате и передавать их контейнерам через переменные среды или тома. Например:

apiVersion: v1

kind: Secret

metadata:

  name: db-secret

type: Opaque

data:

  username: bXlfdXNlcm5hbWU=  # my_username в base64

  password: bXlfcGFzc3dvcmQ=  # my_password в base64

Подключение Kubernetes Secret в поде:

apiVersion: v1

kind: Pod

metadata:

  name: myapp

spec:

  containers:

  - name: mycontainer

	image: myimage

	env:

  	- name: DB_USERNAME

    	valueFrom:

      	secretKeyRef:

        	name: db-secret

        	key: username

  	- name: DB_PASSWORD

    	valueFrom:

      	secretKeyRef:

        	name: db-secret

        	key: password

При этом Kubernetes Secrets может хранить данные в зашифрованном виде, если используется провайдер шифрования (например, KMS).

Подключение секретов в виде временных файлов

Вместо хранения секретов в переменных окружения или Dockerfile можно подключить секреты как временные файлы через тома. Это позволяет ограничить доступ к секретам и удалить их после использования. Например, в Kubernetes можно подключить секреты как файл в контейнере:

volumeMounts:

- name: secret-volume

  mountPath: "/etc/secrets"

  readOnly: true

volumes:

- name: secret-volume

  secret:

	secretName: my-secret

 Удаление секретов после использования

Для контейнеров, которые всё-таки используют временные файлы с секретами, убедитесь, что эти файлы удаляются после использования. Например, если приложение прочитало секрет из файла, можно включить команду для его удаления:

RUN cat /path/to/secret && rm /path/to/secret

Шифрование секретов в образах

Если конфиденциальные данные должны быть включены в контейнер, то они должны быть зашифрованы. Перед запуском контейнера приложение должно расшифровать их, используя безопасный метод шифрования, например GPG или AES. Однако этот метод менее предпочтителен из-за сложности управления ключами шифрования внутри контейнеров.

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

The last but not the least Отсутствие мониторинга и логгинга приведет к тому, что атаки не будут замечены или замечены слишком поздно

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

Как отсутствие мониторинга и логирования угрожает безопасности контейнеров?

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

• Отсутствие записи для расследования инцидентов: Без логирования трудно понять, как и когда произошёл инцидент безопасности. В случае атаки или подозрительного поведения логи позволяют восстановить последовательность событий, чтобы понять, каким образом была скомпрометирована система.

• Задержка в реагировании на инциденты: Логи и мониторинг позволяют настраивать автоматические уведомления и сигналы тревоги при обнаружении аномалий или известных угроз. Без них IT-команде будет сложно оперативно отреагировать на инциденты и принять меры для их устранения.

Основные аспекты мониторинга и логирования в контейнерных средах

Для обеспечения безопасности контейнеров необходимо внедрить мониторинг и логирование на нескольких уровнях:

1. Логирование на уровне контейнеров

Регулярные логи приложений и системные логи позволяют отслеживать внутренние процессы в контейнерах. Это может включать:

• Логи приложений: Сюда входят ошибки, исключения и другая информация о работе приложения. Эти логи помогают определить, если приложение ведет себя нестабильно или подвергается атакам.

• Системные логи контейнера: Включают логи о запуске, остановке и перезапуске контейнеров, а также попытки изменения конфигурации контейнера.

Популярные инструменты для централизованного сбора логов из контейнеров — Fluentd, Logstash и Elasticsearch. Они позволяют агрегацию логов из разных контейнеров и сбор в центральное хранилище, где их легче анализировать.

2. Мониторинг на уровне кластера

Для отслеживания работы всех контейнеров в кластере, например, Kubernetes, полезно использовать метрики и сигналы от системы оркестрации контейнеров. Это может включать:

• Ресурсные метрики: Уровень потребления CPU, памяти, сетевой активности. Аномально высокий уровень потребления может указывать на попытки внедрения вредоносного кода.

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

3. Мониторинг сети и трафика

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

Инструменты, такие как Wireshark для детального анализа трафика и Cilium для контроля сетевой активности в Kubernetes, позволяют создавать правила для анализа трафика между контейнерами и отслеживать нежелательные подключения.

4. Настройка сигналов тревоги и уведомлений

Сигналы тревоги помогают командам безопасности оперативно реагировать на потенциальные угрозы. Уведомления можно настроить на основе:

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

• Аномального поведения: Мониторинг на поведение, отклоняющееся от нормы (например, слишком частые попытки доступа к базе данных), помогает выявлять атаки на ранней стадии.

• Сетевой активности: Наличие подозрительных IP-адресов или странных шаблонов трафика между контейнерами также должно активировать сигнал тревоги.

5. Анализ логов для обнаружения угроз

Используйте инструменты для автоматического анализа и корелляции логов, такие как Splunk, ELK Stack (Elasticsearch, Logstash, Kibana), чтобы быстро находить подозрительные паттерны. Анализ логов позволяет:

• Отслеживать попытки входа в контейнер или доступ к данным.

• Обнаруживать подозрительную активность, такую как быстрое создание и удаление контейнеров.

• Определять поведенческие аномалии и необычные шаблоны доступа.

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

Стартовый курс для администраторов и инженеров, которые хотят освоить основы работы с k8s — «Kubernetes База»

Продвинутый курс для тех, кто уже работал с k8s и хочет повысить компетенции с точки зрения развертывания и сопровождения кластеров K8s — «Kubernetes Мега»