Эта статья на Хабре https://habr.com/ru/articles/783586/

Введение

Зачем?

Представим ситуацию, что мы деплоим по push-модели. В качестве платформы для запуска деплоя у нас используется Gitlab: в нём настроен пайплайн и джобы, разворачивающие приложения в разные окружения в Kubernetes

Какой бы инструмент мы не использовали (kubectl, helm), для манипуляций с ресурсами API нам в любом случае будет необходимо аутентифицироваться при выполнении запросов к Kubernetes. Для этого в запросе надо передать данные для аутентификации, будь то токен или сертификат. И тут возникает несколько вопросов:

1. Где хранить эти креды?

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

2. Как сделать так, чтобы у каждого пользователя были свои данные для доступа в кластер?

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

А что если сделать так, чтобы в качестве провайдера аутентификационных данных для Kubernetes выступал сам Gitlab? Тогда не надо было бы нигде хранить креды, и каждый пользователь мог бы аутентифицироваться в кубере под своей учёткой при запуске деплоя

В чём проблема

Из-за того, что индексный файл helm репы bitnami стал весить слишком много (23МБ+ на момент написания этой заметки), разработчики стали “выкидывать” оттуда старые версии чартов

Что делать

Полный индекс со всеми версиями можно забирать из специальной ветки на гитхабе

Для этого надо заменить url helm репозитория https://charts.bitnami.com/bitnami на https://raw.githubusercontent.com/bitnami/charts/archive-full-index/bitnami

Варианты запуска сборок

1. Shell executor

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

2. docker-in-docker

   • Изолированные друг от друга контейнеры, т.к. здесь child контейнеры от контейнера dind, а не от хостового docker.sock
   • Необходим запуск с privileged (небезопасно)

3. Проброс docker.sock

   • Все контейнеры - siblings (видят друг друга), т.к. запускается через хостовый docker
   • Небезопасно, т.к. можно выполнять какие угодно docker команды на хосте, в т.ч. пробрасывать хостовые папки и запускать privileged контейнеры

4. buildah/buildkit/img

   • Позволяют внутри докер контейнера запускать сборку образа без докер-демона
   • Требуется unprivileged_userns_clone (user namespaces), у которого свои security-риски
   • Синтаксис запуска отличается -> переучивать команду

5. kaniko

   • Позволяют внутри докер контейнера запускать сборку образа без докер-демона
   • Не поддерживается установка бинарника в свой образ. Необходимо использовать официальный образ
   • Синтаксис запуска отличается -> переучивать команду

Потенциальные векторы атаки

1. Источник

   • В сборке используется публичный образ, в котором в entrypoint выполняется команда проверки docker.sock и запуск контейнера через него
   • При сборке в зависимостях (напрмер, node) скачивается зловред, который запускается в процессе сборки. Далее проверка docker.sock и запуск контейнера через него

2. Цель

   • Закрепиться в системе. Через докер возможно установить свои бинарники и сервисы в систему
   • Дальнейший скан сети и поиск уязвимостей для распространения и закрепления

Пайплайны для Merge Requests существуют отдельно (имеют лейбл detached) и запускается независимо от основного pipeline. Из-за этого если сделать push в репу в ветку, из которой в гитлабе есть открытый МР, то запускаются 2 одинаковых пайплайна

  Есть варианта, чтобы это избежать:

1. Дублировать все джобы через extends, чтобы разделить на запускаемые на МРах и на обычные
2. Не запускать CI на некоторых ветках, пока из них нет открытого МРа

Эта статья на Хабре https://habr.com/ru/post/491108/

Helmfile - обёртка для helm, которая позволяет в одном месте описывать множество helm релизов, параметризовать их чарты для нескольких окружений, а также задавать порядок их деплоя.

О самом helmfile и примерах его использования можно почитать в readme и best practices guide.

Мы же познакомимся с неочевидными способами описать релизы в helmfile

Допустим, у нас есть пачка helm-чартов (для примера пусть будет postgres и некое backend приложение) и несколько окружений (несколько kubernetes кластеров, несколько namespace’ов или несколько и того, и другого). Берём helmfile, читаем документацию и начинаем описывать наши окружения и релизы:

    .
    ├── envs
    │   ├── devel
    │   │   └── values
    │   │       ├── backend.yaml
    │   │       └── postgres.yaml
    │   └── production
    │       └── values
    │           ├── backend.yaml
    │           └── postgres.yaml
    └── helmfile.yaml

dapp — утилита от российской компании Флант, которая занимается внедрением devops-практик (kubernetes, ci/cd и всё такое, ну вы в курсе) Подробное описание можно прочитать на Хабре, а я бы хотел остановиться на некоторых особенностях работы с ней при сборке образов (здесь и далее под образом подразумевается docker image)

На момент написания статьи актуальная версия dapp 0.36.*

В качестве примера для наглядности и понимания общей картины возьмём за основу немного урезанное содержимое dappfile.yaml из официальной документации