company_banner

Harbor — реестр для Docker-контейнеров с безопасностью «из коробки»

    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.


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

    Флант
    286,00
    Специалисты по DevOps и высоким нагрузкам в вебе
    Поделиться публикацией

    Комментарии 18

      +2
      Пасиб за статью!
      Мощно.
      То что искал недавно. А то большинство свободных веб интерфейсов к DockerRegistry — «бедненькие».
      Ещё и пример интеграции с Kubernetes имеется.

      Жаль ресурсов много хочет. На тестировочном кластере — особо не разгонишься…
        +1
        > Казалось бы, уже есть Docker Registry  (или, скажем, Quay от CoreOS)

        Quay же платный, верно? Логичнее было бы вспомнить о GitLab тогда.
          0
          Gitlab вообще прекрасен в плане CI и как docker registry, не вижу особых причин использовать что-то другое.
            0
            Хотя здесь наверное дело в масштабах…
              0
              Ну в докер реджистри вообще нет никакой веб-админки.
            0
            Вот, к слову, обзор разных registries. Он уже староват, но хотя бы всех упоминает.
              0

              У gitlab нет функционала для лимитов на каждый проект.

              0
              > PaaS (Platform as a Service) или CaaS (Containers as a Service)

              CaaS тоже ведь включает в себя понятие PaaS. Т.е. если сама система может билдить и хранить имеджи — то это PaaS, если же нет — то IaaS.
                0
                Демо уже лежит demo.goharbor.io: 503 Service Temporarily Unavailable
                  0
                  А почему например не Nexus? Он же умеет быть реестром даже в OSS версии. При этом заодно и репозиторием maven, npm, и для pip тоже.
                    0
                    Никто не говорит, что Harbor — единственное решение, а выше в комментариях приведена ссылка на (лаконичный, но хороший в плане охвата) обзор с большим количеством альтернатив.

                    Конкретно Nexus — куда более разносторонний комбайн, что говорит об очевидных плюсах и минусах сразу. Много ли специфики конкретно Docker-образов там учтено? Например, поддерживаются ли те фичи безопасности, на которые сделан упор в последних релизах Harbor?
                      0
                      >Конкретно Nexus — куда более разносторонний комбайн

                      Так я тоже не говорю, что он единственный и идеальный. Ну то есть это не агитация была, а скорее попытка понять, есть ли что-то такое, чего в нем не хватает. Мне когда вообще встал вопрос со внутренним реестром (в интранете), первое что пришло в голову — это развернуть еще один nexus. Ну и на все про все ушло максимум час — от скачать до создать первый свой docker registry.

                      >обзор с большим количеством альтернатив

                      В котором, кстати, нет нексуса, зато есть еще один представитель мира maven — артифактори.

                      В целом же я думаю, что Nexus куда более разносторонне используемый комбайн. На нем уже с десяток лет строится такое множество репозиториев maven, которое, как я подозреваю, пока не снилось пользователям докера. Да и размеры в общем весьма впечатляющие. О безопасности авторы думают, в этом можно легко убедиться, почитав хотя бы их блог — там большая часть постов на эту тему. Т.е. про аудит репозиториев, например, они уже думали много лет назад. И уж всяко там с аутентификацией и авторизацией все нормально, AD поддерживается, например.

                      Понятно что у докера есть специфика. Но как вы понимаете, если туда смогли впилить npm, pip, maven и докер одновременно, поддерживать разную специфику Sonatype умеет.
                        0
                        > В котором, кстати, нет нексуса

                        Он там тоже есть: «Sonatype Nexus, which supports hosted and on-premises deployments, is a general-purpose repository. It supports much more than Docker image hosting…».

                        Про общие фичи (вроде авторизации) вы рассказали — это я под сомнение и не ставил. Но про специфику всё-таки явного ответа не увидел… Ниже в комментариях пользователь Nexus указывает конкретные минусы, заодно отвечая и на вопрос про фичи в безопасности.
                      +1
                      Nexus не умеет сканировать на уязвимости и подписывать образы. И High Availability у него только в платной версии.
                      +1
                      > Там же можно найти ссылки на инструкции по установке Harbor и его деплою в Kubernetes.
                      Что-то там какая-то урезанная инструкция: «Current deployment does not include Clair and Notary, which are supported in docker-compose deployment. They will be supported in near future, stay tuned.»

                      Вот вроде бы есть Helm chart: github.com/goharbor/harbor/tree/master/contrib/helm/harbor

                      Вообще интересная штука. Сейчас пользуемся Нексусом, но надо эту штуку попробовать.
                        0
                        Точно, не заметил — большое спасибо за полезное уточнение! Добавил в статью.
                        +1

                        Меня попросили сравнить с Artifactory, так что я прям тут и напишу.


                        управление доступом на основе ролей

                        Есть.


                        пользовательский веб-интерфейс для просмотра репозиториев, поиска по ним, управления проектами;

                        Есть.


                        аудит всех операций;

                        Есть.


                        REST API для управления.

                        Есть.


                        Сканирование уязвимостей.

                        Есть, причем не только os level, но и вся аппликативная часть, вне зависимости от того, на чем написана.


                        Подпись образов.

                        Из коробки нет, но нет никаких проблем вызывать notary из beforeDownload user plugin–a, если надо.


                        Теперь, о главном. Никто, и вы в том числе не используете в организации только докер. В контейнеры вы заворачиваете код, при написании которого используется дофига всего, всякие джавы, питоны, сишарпы, гошечки, и даже, возможно, джаваскрипт. Весь этот зоопарк тоже требует управиления зависимостями, и если вы смотрите на Харбор, то даже энтерпрайзного уровня. Вы, конечно, можете, притащить для каждого элемента стэка свою балалайку, и даже, допустим, она будет отлично работать, но как вы сможете коррелировать между зависимостями и артифактами аппликативного уровня, образами Докера и чартами Хелма? Как вы сможете сказать "мне в продакшн нужен последний чарт, в образе которого нет никаких уязвимостей, и джавовый код которого прошёл все проверки в своем джавовом пайплайне"?


                        Ну, и пожалуй спрошу у вас вот еще что, неужели вам бы не хотелось иметь более строгие границы между этапами пайплайна для контейнеров, чем просто директории внутри regisry? Например, отдельные registry для dev и prod? Если да, то может не стоит ставить по registry для каждой среды, а вместо этого пользоваться тулом, в котором можно сделать сколько хочешь таких registry, опять же с promotion и связью между ними?


                        Ну и напоследок, я не знаю, как в Харборе с такими enterprise фичами как high availibilty, replication и подключаемым любым storage? Потому что это обязательные штуки для того, чтобы называться "registry-сервером корпоративного класса".

                          0
                          На днях Harbor «повысили» — перенесли в CNCF Incubator.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое