Как стать автором
Обновить
821.22
OTUS
Цифровые навыки от ведущих экспертов

Проверка образов с помощью Gitlab CI/CD

Время на прочтение 5 мин
Количество просмотров 6K
Автор оригинала: Dale Rodriguez
Всем привет, в преддверии старта курса «CI/CD на AWS, Azure и Gitlab» подготовили перевод интересного материала.




В этой статье мы поговорим о том, как проверять образы контейнеров на платформе Gitlab CI/CD с помощью Sysdig Secure.

Образы контейнеров, которые не соответствуют политикам безопасности, определенным в Sysdig Secure, не будут опубликованы в реестре контейнеров и остановят пайплайн.



Поиск уязвимостей с помощью Gitlab CI/CD


Gitlab CI/CD – это open source сервер непрерывной интеграции и доставки, встроенный в платформу разработки программного обеспечения и коллаборации Gitlab.

После того, как вы настроите для своего репозитория Gitlab CI/CD, каждый раз, когда разработчики будут коммитить в отслеживаемые ветви репозитория, сценарии пайплайна будут запускаться автоматически.

Такие пайплайны можно использовать для автоматизации многих процессов. Например, для QA-тестирования, создания артефактов распространения программного обеспечения (таких как Docker-образы или пакеты Linux) или, для того, о чем мы будем говорить в этой статье — для проверки конфигурации, поиска уязвимостей и проверки на соответствие требованиям.

Проверка образов на пайплайне Gitlab CI/CD: shift left security


Как и везде в IT, чем раньше вы обнаружите в контейнере уязвимость, тем быстрее и проще вы сможете ее исправить без последствий.

Внедрение проверки на уязвимости в ваш пайплайн сборки – это хорошая практика по нескольким причинам:

  • Существующие уязвимости никогда не отправятся на продакшен;
  • Вы можете сразу использовать подход «secure-by-default», зная, что любой образ в вашем реестре контейнеров уже прошел все проверки безопасности, и вам не потребуется проводить ручную проверку потом по факту.
  • Автор образа сразу получит уведомление, не уходя от контекста разработки. Так проблема будет устранена быстрее и проще, чем когда ее обнаружит спустя несколько месяцев кто-то другой.

Sysdig Secure предлагает полнофункциональный набор инструментов для проверки образов контейнеров наряду с многими другими функциями проверки безопасности контейнеров, таких как обнаружение угроз времени выполнения с профилированием на основе машинного обучения и расширяемыми шаблонами обнаружения угроз из коробки, принудительное использование Kubernetes PSPs, реагирование на инциденты и экспертиза на соответствие. Давайте посмотрим на то, как сервис проверки образов Sysdig Secure работает с Gitlab.

Требования для проверки безопасности на Gitlab


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


Настройка Gitlab CI/CD пайплайна для проверки образов с помощью Sysdig Secure


Мы посмотрим на практике как можно интегрировать эти две платформы. С помощью этого руководства вы научитесь работать с Sysdig Secure Image scanning в считанные минуты.

Настройка учетных данных доступа


Пайплайну Gitlab CI/CD понадобятся учетные данные доступа, чтобы установить связь с бэкендом Sysdig Secure. Для того, чтобы сделать все правильно, скопируйте access-токен из Sysdig UI Settings > User profile.

Затем настройте новую глобальную переменную для вашего проекта на Gitlab:

  1. В своем проекте загляните в Settings > CI/CD и выберите Variables.
  2. Создайте новую переменную SYSDIG_SECURE_TOKEN и добавьте ключ Sysdig Secure API в поле value.
  3. Нажмите на кнопку Masked, чтобы ваш токен API не печатался в логах пайплайна.

Определение пайплайна Gitlab


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

FROM debian:stretch
RUN apt update && apt install python-pip python-numpy openssh-server -y && rm -rf /var/lib/apt
RUN pip install flask
COPY app.py /app.py
EXPOSE 5000 22
ENTRYPOINT ["python", "./app.py"]

Затем вам нужно создать новый файл .gitlab-ci.yml в корне проекта. Этот файл будет описывать все необходимые шаги (стадии) сборки нашей среды. Он позволит определить все необходимые стадии.

В нашем пайплайне сейчас 3 стадии:

  • Сборка образа контейнера;
  • Сканирование образа на наличие уязвимостей или нарушений политики;
  • Перемещение образа в конечный репозиторий.

variables:
  CI_REGISTRY_IMAGE: "sysdiglabs/dummy-vuln-app"
  SCAN_IMAGE_NAME: "sysdiglabs/secure_inline_scan:latest"
  SYSDIG_SECURE_ENDPOINT: "https://secure.sysdig.com"

docker-build-master:
  image: docker:latest
  stage: build
  services:
    - docker:dind
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
  script:
    - docker build --pull -t "$CI_REGISTRY_IMAGE" .
    - docker run --rm -v /var/run/docker.sock:/var/run/docker.sock "$SCAN_IMAGE_NAME" /bin/inline_scan analyze -s "$SYSDIG_SECURE_ENDPOINT" -k "$SYSDIG_SECURE_TOKEN" "$CI_REGISTRY_IMAGE"
    - docker push "$CI_REGISTRY_IMAGE"
  only:
    - master

Сборка образа контейнера


Сборка образа происходит с помощью docker build --pull -t "$CI_REGISTRY_NAME". Он берет инструкции из вашего Docker-файла и генерирует новый локальный образ, который будет проверяться на следующем шаге.

Проверка образа на наличие уязвимостей


Следующая стадия – это проверка контейнеров. Здесь мы будем проверять образ на наличие уязвимостей и проверять конфигурацию, сохраняя результаты на бэкенде Sysdig.

Одним из преимуществ локального сканирования Sysdig является то, что вы не теряете контроль над своими образами, поскольку образ не нужно перемещать в другой реестр или подвергать воздействию извне, чтобы провести проверку. Она происходит внутри runner’а, а в Sysdig Secure отправляются только результаты.

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock "$SCAN_IMAGE_NAME" /bin/inline_scan analyze -s "$SYSDIG_SECURE_ENDPOINT" -k "$SYSDIG_SECURE_TOKEN" "$CI_REGISTRY_IMAGE"

На этой стадии Sysdig Secure вернет код ошибки, если образ будет отвечать любому из условий остановки, указанных в вашей политике (например, критическую уязвимость). Остановка пайплайна предотвратит передачу уязвимых образов в реестр контейнеров.





В Sysdig Secure мы можем посмотреть дополнительную информацию и понять, почему не удалось завершить проверку на безопасность:



Как видно на скриншоте, контейнер оставляет открытым 22 порт, который находится в списке запрещенных портов, а также содержит некоторые серьезные уязвимости в библиотеке Python.

Перемещение образа в конечный репозиторий


После успешной проверки на уязвимости пайплайн выполнит docker push и образ будет опубликован в реестре контейнеров. Если вы не укажете никаких учетных данных или удаленного хранилища, Gitlab использует дефолтное.

Заключение


С помощью Sysdig Secure image scanning вы можете проверять образы в пайплайне Gitlab CI/CD, не отправляя их из инфраструктуры в публичный или промежуточный реестр, проверить конфигурацию и предотвратить просачивание уязвимостей на продакшен.

Найдите известные уязвимости и проверьте конфигурацию на соответствие рекомендациям по безопасности, включая инструкции Dockerfile, белый и черный списки пакетов или сторонних библиотек, установленных в базовый образ, таких как JAR/WAR-файлы в Java или языковые менеджеры пакетов, такие как npm для Javascript, pip для Python и gem для Ruby.

При сбое можно быстро сообщить об этом автору контейнера, чтобы оперативно решить проблему и создать secure-by-default политику безопасности контейнеров. Чтобы попробовать Sysdig Secure, вы можете запросить демо-версию уже сегодня!

На этом все. Узнать о курсе подробнее можно тут.
Теги:
Хабы:
+6
Комментарии 0
Комментарии Комментировать

Публикации

Информация

Сайт
otus.ru
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия
Представитель
OTUS