31 июля организация CNCF объявила о принятии в свою «песочницу» (т.е. на самый ранний этап поддержки) нового Open Source-проекта, охарактеризованного как «облачный (cloud native) реестр», — Harbor. На его сайте нам объясняют, что продукт создан для управления образами Docker-контейнеров в безопасном окружении.
Казалось бы, уже есть Docker Registry (или, скажем, Quay от CoreOS), но очевидно, что новые решения не появляются и не дозревают до применения в production просто так — тем более, Open Source-решения… и уж тем более, попадающие в CNCF. Эта обзорная статья призвана пролить свет на причины появления Harbor, его ключевые возможности и особенности.
История проекта начинается в 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. Если же говорить о функциональных возможностях проекта, то уже в первом релизе авторы заложили некоторые актуальные и по сей день фичи, такие как:
Управление проектами в веб-интерфейсе 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):
В то же самое время становится всё более актуальным вопрос безопасности Docker-образов. В начале 2018 года инженеры «братской» для VMware компании Pivotal ссылаются на исследование, согласно которому даже последние версии образов, размещённые на Docker Hub (как от сообщества, так и официальные), содержат многочисленные уязвимости (в среднем по 70 на образ).
Тут-то Harbor и предстал со своим новым предназначением, ориентированным на безопасность, и уже на упомянутой «почве» CaaS — в Pivotal Container Service (PKS):
Что же такого безопасного добавляется в Harbor (помимо уже реализованных в проекте RBAC и аудита)? Указываются два основных направления:
Общая схема применения Harbor в PKS выглядит следующим образом:
Итак, предлагая реестр образов контейнеров для использования on-premises и обеспечивая безопасность в разных аспектах работы с ними, на сегодняшний день Harbor развился до следующей архитектуры, как видно, объединяющей в себе функции из других Open Source-проектов:
Помимо уже упомянутых Docker Registry, Clair и Notary, реализующих ключевые возможности Harbor, в этой схеме можно также увидеть ещё наличие двух СУБД:
Базы данных в архитектуре 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, и достаточно активное сообщество разработчиков.
Читайте также в нашем блоге:
Казалось бы, уже есть 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 и аудита)? Указываются два основных направления:
- Сканирование уязвимостей. Для этого в Harbor реализовано получение CVE по известным базам данных (NIST NVD, Ubuntu CVE Tracker, Red Hat Security Data и т.п.) и автоматическое сканирование каждого образа контейнера на их наличие при выполнении операций push и pull. Если обнаружена уязвимость, операции отменяются в зависимости от настроек безопасности, а сам образ помечается, что будет видно администратору реестра. Для реализации этой возможности в Harbor провели интеграцию с Clair от CoreOS.
- Подпись образов. Здесь тоже используются наработки другого проекта — Notary (мы упоминали о нём в этой статье), — который делает подпись при push'е образов, а затем валидирует такие подписи при каждом pull'е.
Общая схема применения Harbor в PKS выглядит следующим образом:
Harbor сегодня
Итак, предлагая реестр образов контейнеров для использования on-premises и обеспечивая безопасность в разных аспектах работы с ними, на сегодняшний день Harbor развился до следующей архитектуры, как видно, объединяющей в себе функции из других Open Source-проектов:
Помимо уже упомянутых Docker Registry, Clair и Notary, реализующих ключевые возможности Harbor, в этой схеме можно также увидеть ещё наличие двух СУБД:
- PostgreSQL (ранее здесь была MySQL/MariaDB), которая используется для хранения метаданных о проектах, пользователях и их ролях, образах;
- 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.
Читайте также в нашем блоге:
- «Путеводитель CNCF по решениям Open Source (и не только) для cloud native»;
- «OPA и SPIFFE — два новых проекта в CNCF для безопасности облачных приложений»;
- «Четыре релиза 1.0 от CNCF и главные анонсы про Kubernetes с KubeCon 2017»;
- «Пакетный менеджер для Kubernetes — Helm: прошлое, настоящее, будущее»;
- «CNCF предложила бесплатное облако Open Source-проектам для DevOps/микросервисов»;
- «Статистика по базовым операционным системам в образах на Docker Hub».
