Безопасность в Kubernetes: Docker Image Security

Kuber_Deep_19.6_site-5020-5f95c7.png

Начинаем публикацию серии статей, посвящённых выступлению Дмитрия Лазаренко, руководителя PaaS-направления в Mail.Ru Cloud Solutions. Он поделится опытом реализации типовых паттернов безопасности в Kubernetes, которые могут быть применены как в публичном, так и в частном облаке.

С чем у вас ассоциируется Docker?

Kubernetes является одновременно и мощным, и сложным инструментом. Вопрос безопасности здесь не является исключением: тут всё совсем не так тривиально, как в случае с «классической» безопасностью приложений, работающих в виртуальных средах или даже на базе Docker.

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

1-20219-14ce04.jpg

Теперь давайте рассмотрим каждый из этих уровней подробнее.

Docker Image Security

Первая матрёшка — это про безопасность докеров. Тут можно выделить базовые принципы, так называемые «9 заповедей докеровода»: 1. Не записывайте secrets в Docker-файлы. 2. Не используйте root. 3. Всегда создавайте пользователя. 4. Используйте gosu вместо sudo. 5. Используйте COPY вместо ADD. 6. Всегда фиксируйте версию для базовых images, пакетов и т. д. 7. Безопасно скачивайте пакеты (checksum). 8. Удаляйте зависимости после сборки. 9. Убедитесь, что images не содержат известных уязвимостей.

Решения для сканирования исходного кода: 1. InfoWatch Uppercut. 2. Snyk.

Решения для сканирования Docker Images: 1. Docker Security Scanning. 2. CoreOS Clair. 3. Anchore. 4. JFrog Xray. 5. Aqua MicroScanner.

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

2-20219-39449b.jpg

Что с этим делать дальше?

Если в результате проверки мы убедились, что Image доверенный, мы можем: 1) подписать Docker Image после успешной проверки (Docker Notary); 2) запретить pull неподписанных Images из Registry (Harbor); 3) запретить деплой подов из неподписанных Images в K8S.

Пример реализованной архитектуры:

3-20219-aece88.jpg

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

4-20219-37cbf6.jpg

Как это работает в Kubernetes?

Реализация возможна благодаря тому, что в Kubernetes есть концепция адмишн-контроллеров:

5-20219-346c51.jpg

Если перейти к конкретике, то первым вариантом архитектуры является Anchore Engine — опенсорсный инструмент, который интегрируется с Kubernetes на базе ImagePolicyWebhook. Вот как выглядит эта архитектура:

6-20219-929602.jpg

Есть и альтернативное решение, связанное с использованием стандартных Docker-инструментов, например, Notary. Его можно скрестить с проектом от IBM под названием Portieris. В свою очередь, Notary + Portieris можно скрестить с Kubernetes на базе Mutating Admission Webhook.

Что ж, одну «матрёшку» мы разобрали, в следующей заметке поговорим про Host Level Security. Следите за новостями!

Автор
0 комментариев
Для комментирования необходимо авторизоваться