IBM Senior DevOps Engineer & Integration Architect. Официальный DevOps ментор и коуч в IBM Привет, Хабр!Все больше компаний стремятся интегрировать безопасность в каждый этап разработки программного обеспечения. В контексте быстро развивающегося мира контейнеризации и облачных технологий, DevSecOps становится неотъемлемой частью создания безопасных и надежных приложений. Одним из ключевых моментов при работе с контейнерами является безопасность образов. Amazon Elastic Container Registry (Amazon ECR) предоставляет мощный инструмент для хранения Docker-образов, но безопасность этих образов играет критическую роль. В этой статье мы исследуем процесс сканирования образов на безопасность перед их отправкой в Amazon ECR, раскрывая методы и инструменты, которые помогают обеспечить непрерывную безопасность в DevSecOps-окружении. Amazon Elastic Container Registry (Amazon ECR) — это управляемый сервис хранения контейнеров от Amazon Web Services (AWS). Amazon ECR предоставляет безопасное и масштабируемое хранилище для Docker-образов, которые могут быть использованы в сервисе AWS Elastic Container Service (ECS), Kubernetes на AWS (Amazon EKS) или самостоятельно в других инструментах управления контейнерами.Безопасность образов контейнеров играет критическую роль в DevSecOps. Образы контейнеров представляют собой основу для развертывания приложений в инфраструктуре, и даже незначительные уязвимости или ошибки в них могут привести к серьезным угрозам безопасности. Сканирование образов на безопасность — важная практика, которая позволяет выявлять уязвимости, недостатки конфигурации и потенциальные угрозы в образах контейнеров еще до их развертывания. Это обеспечивает возможность предотвращения инцидентов безопасности на ранних этапах разработки и эксплуатации приложений. Процесс сканирования образов на безопасность включает в себя несколько ключевых аспектов: Поиск уязвимостей: Использование специализированных инструментов для сканирования образов на предмет известных уязвимостей, включая устаревшие библиотеки, известные уязвимости безопасности и прочие уязвимости, которые могут быть использованы злоумышленниками. Проверка конфигурации: Анализ конфигурации образа на предмет соответствия лучшим практикам безопасности, включая правильность настройки сетевых параметров, доступность лишь необходимых сервисов и минимизацию доступа к привилегиям. Интеграция с процессами CI/CD: Автоматизация сканирования образов в рамках цепочек Continuous Integration и Continuous Deployment (CI/CD) для обеспечения непрерывной проверки безопасности образов на всех этапах разработки и развертывания. Управление угрозами: Оценка и приоритизация обнаруженных уязвимостей, а также принятие мер для устранения или уменьшения их воздействия на безопасность приложения. Инструменты для сканирования образов на безопасность, такие как Clair, Anchore, Twistlock, Trivy и другие, предоставляют возможность автоматического анализа контейнерных образов на предмет уязвимостей и неправильной конфигурации. Их интеграция в пайплайны CI/CD позволяет обеспечить непрерывную безопасность приложений, начиная с ранних этапов разработки и до их эксплуатации в продакшне. Этот процесс сканирования образов на безопасность становится ключевым элементом стратегии DevSecOps и гарантирует, что безопасность интегрируется в каждый этап жизненного цикла приложения. Давайте приступим. Для пререквизитов нам понадобится аккаунт в aws и aws cliСоздадим ECR репозиторий: В командной строке применим конфигурацию сканирования к созданному репозиторию: Эта конфигурация устанавливает для scanOnPush значение true для репозитория контейнеров. Это означает, что каждый раз, когда вы отправляете новый образ контейнера, он будет генерировать отчет об уязвимостях.Напишем небольшой bash скрипт, который предоставит необходимые нам ресурсы: Напишем и запустим bash-скрипт для создание ec2 инстанса(конечно можно и терраформом, на bash писать интереснее) Теперь мы подключимся к инстансу, чтобы создать образ лямбда-контейнера и отправить его в ECR. Нужно получить IP-адреса созданного вами инстанса EC2 и установить их в качестве переменных. Этот скрипт сделает это за нас. Мы сохраняем идентификатор учетной записи AWS в переменной и копируем его в ваш инстанс EC2: Теперь сами подключимся Теперь, когда мы подключены к нашему инстансу EC2, это можно считать нашей средой разработки. Мы устанавливаем регион в нашем экземпляре EC2, чтобы AWS CLI мог его инициализировать: Устанавливаем переменные среды: Получаем данные для входа в ECR и в Docker: Вместо того, чтобы создавать новый образ контейнера из файла Dockerfile, на этот раз мы собираемся запуллить старый образ контейнера NGINX (версия 1.14.1 является более старой версией NGINX и действительно содержит уязвимости безопасности, которые были исправлены в новых версиях, поэтому разумно использовать в целях тестирования): Данные для входа в Docker: Применяем тег к изображению, чтобы можно было отправить его в репозиторий ECR: Пушим Вскоре после завершения отправки мы можем просмотреть результаты сканирования безопасности изображения в формате JSON: Уязвимости системы безопасности классифицируются по степени серьезности и им присваивается номер CVE. CVE расшифровывается как Common Vulnerabilities and Exposures и представляет собой глоссарий, поддерживаемый консорциумом и классифицирующий уязвимости. Оценка CVE часто используется для определения приоритета безопасности уязвимостей. Эта уязвимость имеет КРИТИЧЕСКИЙ уровень и, следовательно, будет иметь высший приоритет. В этом случае решением будет обновить версию NGINX. Статья подготовлена в рамках онлайн-курса «Внедрение и работа в DevSecOps». Записывайтесь на бесплатные открытые уроки на странице курса.  Редактор