31 июля организация CNCF объявила о принятии в свою «песочницу» (т.е. на самый ранний этап поддержки) нового Open Source-проекта, охарактеризованного как «облачный (cloud native) реестр», — Harbor. На его сайте нам объясняют, что продукт создан для управления образами Docker-контейнеров в безопасном окружении.



Казалось бы, уже есть Docker Registry  (или, скажем, Quay от CoreOS), но очевидно, что новые решения не появляются и не дозревают до применения в production просто так — тем более, Open Source-решения… и уж тем более, попадающие в CNCF. Эта обзорная статья призвана пролить свет на причины появления Harbor, его ключевые возможности и особенности.

Первый фокус Harbor: сеть и enterprise


История проекта начинается в 2016 году, в марте которого состоялся первый публичный релиз — 0.1.0. За его созданием стояли инженеры компании VMware, которые описывали проект как «registry-сервер корпоративного класса», который, основываясь на разработках Docker, «расширяет возможности Docker Registry, добавляя в него больше функций, что обычно требуются в enterprise».

В то время акцент больше ставился на возможность использования этого реестра внутри компании, в частности, потенциально улучшая продуктивность благодаря хранению образов в корпоративной сети: «[Harbor] очень полезен для пользователей контейнеров, не обладающих хорошим подключением к интернету. Например, Harbor повышает производительность китайских разработчиков, устраняя сложности в загрузке образов из публичного интернета» (из README к Harbor 0.1.0).

Примечание: Ориентация Harbor на Китай, подтверждавшаяся и наличием соответствующей локализации с первых релизов, была не случайна: создание проекта как такового инициировало именно китайское подразделение компании (VMware China R&D).

Что стало уже повседневностью для cloud native-экосистемы, Harbor с самого начала был написан на языке Go и лицензирован на условиях Apache License 2.0. Если же говорить о функциональных возможностях проекта, то уже в первом релизе авторы заложили некоторые актуальные и по сей день фичи, такие как:

  • управление доступом на основе ролей (RBAC, позволяющий организовывать пользователей и репозитории в виде «проектов» и выдавать разные права к образам в рамках этих проектов), а также поддержка LDAP и AD для аутентификации пользователей;
  • пользовательский веб-интерфейс для просмотра репозиториев, поиска по ним, управления проектами;
  • аудит всех операций;
  • REST API для управления.


Управление проектами в веб-интерфейсе Harbor

Эволюция Harbor: безопасность


В 2017 году в VMware нашли логичное применение своему новому проекту — интеграция с другими решениями компании для контейнеров. В частности, шло активное развитие vSphere Integrated Containers (VIC), которые, не являясь полноценной PaaS (Platform as a Service) или CaaS (Containers as a Service), предлагали некий фундамент для работы с контейнерами. На сегодняшний день из них, например, вырос vSphere Integrated Containers Engine, являющийся исполняемой средой контейнеров для vSphere. А вот как описывал в то время VIC инженер решений VMware (Nate Reid):

«VIC берёт каркас единственного Docker-хоста и масштабирует его на множество хостов ESXi. Предлагаемая им архитектура для оркестровки похожа на Swarm, Kubernetes (K8s) и Mesos. Однако здесь есть свои нюансы, а задачи заменить все эти продукты нет. VIC обеспечивает для контейнеров сеть, позволяет получать их имена, предлагает RBAC, панель управления на HTML5 (Admiral; подробнее о нём читайте в нашем обзоре GUI для Docker — прим. перев.), реестр корпоративного уровня (Harbor), множество аналогичных Docker команд, интеграцию с инструментами vSphere. [..]

Если вам нужна поддержка оркестровки с Kubernetes и/или возможности CI/CD на базе IaaS от VMware, стоит посмотреть на VMware PKS и/или Pivotal Cloud Foundry. Это уже решения класса CaaS и PaaS».

В то же самое время становится всё более актуальным вопрос безопасности Docker-образов. В начале 2018 года инженеры «братской» для VMware компании Pivotal ссылаются на исследование, согласно которому даже последние версии образов, размещённые на Docker Hub (как от сообщества, так и официальные), содержат многочисленные уязвимости (в среднем по 70 на образ).

Тут-то Harbor и предстал со своим новым предназначением, ориентированным на безопасность, и уже на упомянутой «почве» CaaS — в Pivotal Container Service (PKS):

«Это [наличие уязвимостей и другие проблемы безопасности в образах Docker] и есть причина, по которой мы включили так много полезных дополнений, делающих PKS надёжным и безопасным! [..]

Поскольку Kubernetes сам по себе не занимается такими вопросами [безопасным управлением образов], мы потрудились вместе с друзьями из VMware для того, чтобы включить Harbor в PKS».

Что же такого безопасного добавляется в Harbor (помимо уже реализованных в проекте RBAC и аудита)? Указываются два основных направления:

  1. Сканирование уязвимостей. Для этого в Harbor реализовано получение CVE по известным базам данных (NIST NVD, Ubuntu CVE Tracker, Red Hat Security Data и т.п.) и автоматическое сканирование каждого образа контейнера на их наличие при выполнении операций push и pull. Если обнаружена уязвимость, операции отменяются в зависимости от настроек безопасности, а сам образ помечается, что будет видно администратору реестра. Для реализации этой возможности в Harbor провели интеграцию с Clair от CoreOS.
  2. Подпись образов. Здесь тоже используются наработки другого проекта — Notary (мы упоминали о нём в этой статье), — который делает подпись при push'е образов, а затем валидирует такие подписи при каждом pull'е.

Общая схема применения Harbor в PKS выглядит следующим образом:



Harbor сегодня


Итак, предлагая реестр образов контейнеров для использования on-premises и обеспечивая безопасность в разных аспектах работы с ними, на сегодняшний день Harbor развился до следующей архитектуры, как видно, объединяющей в себе функции из других Open Source-проектов:



Помимо уже упомянутых Docker Registry, Clair и Notary, реализующих ключевые возможности Harbor, в этой схеме можно также увидеть ещё наличие двух СУБД:

  1. PostgreSQL (ранее здесь была MySQL/MariaDB), которая используется для хранения метаданных о проектах, пользователях и их ролях, образах;
  2. Redis — для хранения сессий.


Базы данных в архитектуре Harbor

Некоторые подробности об общем внутреннем устройстве Harbor можно также почерпнуть из этой wiki-страницы, на которую ссылается официальная документация проекта (однако есть подозрение, что некоторые детали по архитектуре могли местами устареть). Там же можно найти ссылки на инструкции по установке Harbor и его деплою в Kubernetes. Последняя, впрочем, объявлена устаревшей (основана на старых версиях, не поддерживает Clair и Notary), а вместо неё предлагается использовать Helm-чарт.

Актуальная версия Harbor — v1.5.2, выпущенная в конце июля. Требования к Linux-машине, на которую устанавливается свежий релиз реестра, — наличие Docker версии 17.03.0-ce (или выше) и Docker Compose 1.10.0+, а также Python и OpenSSL.

Очень интересным новшеством для будущей версии Harbor (уже вышла v1.6.0-rc1) выглядит поддержка Helm-чартов: «Harbor, начиная с версии 1.6.0, станет композитным cloud native-реестром, который будет поддерживать и управление образами, и управление чартами». Среди прочих планов по развитию значатся поддержка OAuth 2.0 для аутентификации пользователей, возможность развёртывания на множестве узлов для отказоустойчивости и балансировки нагрузки, сбор статистики по репозиториям и утилита для миграции на Harbor.

Вместо заключения


Harbor — пример успешного проекта из современного облачного мира, сумевшего найти свою нишу и зарекомендовать себя, попутно интегрируя возможности других Open Source-инструментов. Свидетельством же его успеха является не только включение в список проектов CNCF, но и 5000+ звёзд на GitHub, и достаточно активное сообщество разработчиков.

P.S.


Читайте также в нашем блоге: