Контейнер дал течь» проверьте безопасность Docker-образа

Для поиска уязвимостей в образах Docker есть специальные инструменты: Anchore Engine и Clair.

Anchore Engine – централизованная служба проверки, анализа и сертификации образа. Она сканирует образы, используя данные об уязвимостях (feeds) от вендоров ОС, таких как Red Hat, или Debian. Для non-OS данных используется NVD (National Vulnerability Database), которая включает уязвимости для RPM, Deb, APK, а также Python (PIP), Ruby Gems и т. д.

Clair – статический анализатор, разработанный компанией CoreOS для контейнеров Docker и APPC. Анализатор использует уязвимость метаданных для Red Hat Security Data, NVD, Ubuntu CVE Tracker, Alpine SecDB, Debian Security Bug Tracker и т. д.

Как Anchore, так и Clair могут быть развёрнуты в Kubernetes или OpenShift, но для простоты настроим всё на локальной машине с помощью docker-compose.

Чтобы настроить Anchore, выполняем следующие действия:

Установка и настройка Anchore

Для Clair выполняем такую последовательность

Установка и настройка Clair

Контейнер дал течь» проверьте безопасность Docker-образа

Начнём тест Anchore с базового образа Debian:

Посмотрим, какие уязвимости были обнаружены:

Сначала мы запускаем команду image vuln со всеми флагами, чтобы обнаружить уязвимости ОС и пакетов, присутствующих в образе. Все они незначительны или неизвестны – это хорошо. Затем мы запускаем команду evaluate check , чтобы проверить, проходит ли образ проверку политики по умолчанию, и, как видим выше, он проходит ( Status: pass ). Базовые образы обычно работают без нареканий, поскольку они широко используются и находятся под большим вниманием.

Но как насчет простого “Hello World” на Python, построенного с использованием образа Python 3 Debian Buster? Давайте сначала посмотрим на Dockerfile:

Ничего не сообщает о “vulnerable” или “insecure”. Тогда соберём и проанализируем:

Сначала мы забилдили образ, используя вышеприведённый debian.Dockerfile и hello.py , затем переместили его в Docker Hub, откуда он был добавлен в Anchore и проанализирован. Взглянем на результаты:

Уже не так хорошо. После переключения на официальный образ Debian Python, появилось более 1000 уязвимостей. После выполнения оценки образа мы видим, что она не удалась ( Status: fail ).

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

Контейнер дал течь» проверьте безопасность Docker-образа

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

Мало что изменилось по сравнению с Debian-версией. Мы переключили текущий образ на gcr.io/distroless/python3 . Теперь можем продолжать: сбилдить, запушить и добавить его в Anchore Engine:

Посмотрим, работает ли Distroless менее эффективно, чем Debian-образ:

Можно видеть, что по сравнению с первым примером здесь только 53 уязвимости и всего 2 уязвимости с низкой степенью важности. Можно с уверенностью заключить, что Distroless – лучший выбор, когда речь заходит о безопасности контейнерных приложений. Однако есть еще несколько штуковин, с которыми можно поиграться – использовать различные политики оценки:

В приведённой выше команде перечислены все доступные политики, которые мы можем использовать для проверки образов. По умолчанию используется anchore_default_bundle , который отлично работает, но если мы хотим видеть проверку, выполняемую с использованием другого списка и правил, то можно попробовать anchore_cis_1. 13.0_base :

В примере выше мы рассмотрели описание политики, запустив policy hub get . Далее мы установили ее и, как результат – имеем две доступные политики, причем одна из них неактивна. Исправим это с помощью команды policy activate .

Для получения полного списка правил в этой политике наберите anchore-cli –json policy hub get anchore_cis_1.13.0_base .

Пришло время запуска:

Приведённые проблемы/уязвимости не дают образу нормально пройти оценку политики и должны быть проанализированы. Одна из них (вторая) вызвана использованием Distroless образа, так что ее можно игнорировать. Две другие должны быть исправлены. Все это показывает нам, что выбрать конкретную политику, основанную на ваших требованиях или даже использовать несколько из них – это хорошая возможность найти как можно больше уязвимостей.

Типы и уровни уязвимостей. Не все уязвимости одинаковы и применимы к нашим приложениям/контейнерам/средам. Поэтому нужно смотреть не только на их тяжесть, но и на факторы, из которых эта тяжесть рассчитывается. Это включает в себя вектор атаки, сложность атаки, влияние на конфиденциальность, влияние на целостность и т. д. Затем эти факторы создают окончательную оценку серьезности, полученную с помощью калькулятора CVSS. Значения метрик по тяжести: нет, низкая, средняя, высокая и критическая. Более подробную информацию о них можно найти на сайте NIST (Национальный институт стандартов и технологий).

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

Теперь сравним с Anchore работу Clair. Запустим инструмент на наших примера с образами Debian и Distrolless:

Выглядит довольно похоже на то, что мы получили от Anchore – много проблем для образа Debian и ничего для Distroless. В выводах двух сканеров присутствуют одинаковые результаты, но так может быть не всегда. Именно поэтому мы рекомендуем использовать несколько инструментов сканирования, использующих разные источники уязвимостей метаданных.

Если вы захотите дополнительно изучить другие инструменты и вопросы безопасности можно обратиться в Docker Bench for Security.

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

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

Вы пропустили

AEGIS Algorithms Android Angular Apache Airflow Apache Druid Apache Flink Apache Spark API API Canvas AppSec Architecture Artificial Intelligence Astro Authentication Authorization AutoGPT AWS AWS Aurora AWS Boto3 AWS EC2 AWS Lambda Azure Babylon.js Backend bash Beautiful Soup Bento UI Big Data Binary Tree Browser API Bun Career Cassandra Charts ChatGPT Chrome Extension Clean Code CLI ClickHouse Coding Codux Combine Compose Computer Context Fusion Copilot Cosmo Route CProgramming cron Cryptography CSS CTF Cypress DALL-E Data Analysis Data science Database dbt dbt Cloud deno Design Design Patterns Detekt Development Distributed Systems Django Docker Docker Hub Drizzle DRY DuckDB Express FastAPI Flask Flutter For Beginners Front End Development Game Development GCN GCP Geospatial Git GitHub Actions GitHub Pages Gitlab GMS GoFr Golang Google Google Sheets Google Wire GPT-3 GPT3 Gradio Gradle Grafana Graphic Design GraphQL gRPC Guidance HMS Hotwire HTML Huawei HuggingFace IndexedDB InfoSec Interview iOS Jackknife Java JavaScript Jetpack Compose JSON Kafka Kotlin Kubernetes LangChain Laravel Linux LlaMA LLM localStorage Logging Machine Learning Magento Math Mermaid Micro Frontends Mobile Mobile App Development mondayDB MongoDB Mongoose MySQL Naming NestJS NET NetMock Networks NextJS NLP Node.js Nodejs NoSQL NPM OOP OpenAI OTP Pandas PDF PHP Playwright Plotly Polars PostgreSQL Prefect Productivity Programming Prometheus Puppeteer Pushover Python Pytorch Quarkus Rabbitmq RAG Ramda Raspberry Pi React React Native Reactor Redis REST API Revolut Riverpod RProgramming Ruby Ruby on Rails Rust Scalene SCDB ScyllaDB Selenium Servers Sklearn SLO SnowFlake Snowkase Software Architecture Software Development Solara Solid Spring Boot SQL SQLite Streamlit SudoLang Supabase Swift SwiftUI Tailwind CSS Taipy Terraform Testing Transformers TURN TypeScript Ubuntu UI Design Unix UX UX Design Vim Vite VSCode Vue Web Architecture Web Components Web Development Web Frameworks Web Scraping Web-разработка Webassembly Websocket Whisper Widgets WordPress YAML YouTube Zed Наука о данных Разное Тренды

Как исследовать и визуализировать данные МО для обнаружения объектов на изображениях