NebulaCR: корпоративный реестр OCI, наблюдаемость и соответствие требованиям без компромиссов

Краткое описание

NebulaCR— это облачный реестр контейнеровOCI с открытым исходным кодом OCI, написанный на Rust. Он сочетает в себе соответствующую стандартам службу регистрации туманностей(порт 5000) со специальной службой токеновс аутентификацией по туманности (порт 5001), дополнительную интеграциюHashiCorp Vaultдля подписи ключей, подключаемое объектное хранилище(файловая система, S3, GCS, Azure Blob) и первоклассную упаковкуKubernetesс CRD для арендаторов, проектов и политик. Первоначальный проект позиционирует продукт вокруг частного, наблюдаемого и управляемого распространения изображений; см. общедоступную целевую страницуnebulacr.orgи исходный код и выпускиgithub.com/bwalia/nebulacr.

Почему предприятия используют частный реестр OCI

Образы контейнеров теперь являются единицей развертывания для большинства облачных команд. Реестр, который находится только внутри вашей границы безопасности, позволяет вам обеспечить резидентность данных,контролирует цепочку поставок,детализированную RBACипрогнозируемую стоимость(особенно в сочетании с сквозным кэшированием для вышестоящих реестров). NebulaCR предназначен для операторов, которым нужны рабочие процессы, совместимые с Docker, без отказа от идентификации, возможности аудита или устойчивости в нескольких регионах.

Рабочая область Rust (Cargo.toml)

UpstreamCargo.tomlобъявляет рабочую область из семи ящиков:nebula-common,nebula-auth,nebula-registry,контроллер туманности,устойчивость к туманности,туманность-зеркалоирепликация туманности. В дереве проекта README каждый контейнер сопоставлен с двоичными файлами или библиотеками — службами реестра и аутентификации, механизмом согласования Kubernetes, механизмом сквозного кэширования, помощниками обеспечения устойчивости и репликацией в нескольких регионах. Из исходного кода запуститеcargo build --workspace --releaseиcargo test --workspaceперед контейнеризацией с корневымDockerfileили оптимизированнымDockerfile.scratch.

Архитектура, взятая из проектной документации

Помимо трех основных двоичных файлов/библиотек, описанных выше, контроллер туманностисогласовывает Tenant/Project/AccessPolicy/TokenPolicy CRDs,Nebula-Mirrorреализует сквозное кэширование для вышестоящих реестров,Nebula-Resilenceосуществляет повторные попытки и автоматические выключатели для путей репликации, аNebula-Replicationобеспечивает обратную связь многорегиональные асинхронные или полусинхронные режимы с аварийным переключением, описанные вdocs/architecture.md. Реестр туманностейостается на базе Axum с применением JWT для каждого запроса;nebula-authпроверяет токены идентификации OIDC и выдает кратковременные JWT реестра. Хранилище остается иерархическим для каждого арендатора/проекта, а серверные части остаются подключаемыми.

Входные маршруты, проверки работоспособности и метрики

ASCII-архитектура README показывает разделение трафика:/v2к службе реестра (5000) и потоки аутентификации (часто под/auth) кnebula-auth(5001) с внешними поставщиками OIDC оба. Диаграммы Helm отображают метрики Prometheus (примеры включаютnebulacr_http_requests_total,nebulacr_http_request_duration_seconds,nebulacr_storage_operations_total,nebulacr_auth_tokens_issued_total) и документируютcurl http://localhost:5000/healthпослеkubectl port-forwardв Службу реестра.

Аутентификация с нулевым доверием и интеграция CI

NebulaCR подчеркиваетотсутствие долговременных паролей реестрадля автоматизации. Системы CI предоставляют идентификационные токены OIDC от доверенных эмитентов; nebula-auth проверяет подписи, применяет политику и возвращает JWT с ограниченной областью действия с жесткими значениями TTL по умолчанию (обычно около пяти минут). Операторы-люди проходят аутентификацию через стандартные потоки кодов авторизации OIDC с помощью PKCE от таких поставщиков, как Azure AD, Okta или Google Workspace.

CRD, сквозной кэш и ограничения скорости

Операторы Kubernetes управляютTenant(квоты, привязки OIDC),Project(группы репозитория и политики),AccessPolicy(RBAC) иTokenPolicy(TTL и учетные записи роботов). В документах README есть такие префиксыdocker pull <host>:5000/library/nginx:latest, GHCR и Quay, а также зеркальный разделcontainerd, указывающийdocker.ioна NebulaCR. Ограничение скорости применяется для каждого IP-адреса и каждого арендатора при использовании крейтаgovernor.

Наблюдение, аудит и соответствие

Согласно проектной документации, установленной вdocs/, NebulaCR предоставляетметрики Prometheusиз реестра и служб аутентификации, выдаетструктурированный журнал JSON регистрируети поддерживает трассировкуOpenTelemetryдля более глубокого анализа. Встроенная панель мониторинга отображает CPU, память, диск, состояние репликации, просмотр репозитория и отфильтрованные журналы аудита для отправки, получения и удаления — существенное доказательство для проверок безопасности.SCIM 2.0. Обеспечениеавтоматизирует циклы «приход-переезд-увольнение» с помощью поставщиков удостоверений, сокращая окно, в котором бывшие сотрудники сохраняют скрытый доступ.

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

В README описаны сервисы без сохранения состоянияс горизонтальным автоматическим масштабированием модулей, бюджетами на прерывание работы модулей и автоматическими выключателями для путей репликации. Репликация в нескольких регионах описывается как асинхронная с элементами управления устойчивостью, поэтому операции чтения могут переключаться при сбое в работе региона. Сквозное кэширование снижает пропускную способность и задержку получения для вышестоящих реестров, включая Docker Hub, GHCR, GCR, Quay.io и Registry.k8s.io.

Начало работы

Для минимальной локальной пробной версии документы READMEdocker run -p 5000:5000 bwalia/nebulacr:latest,docker compose up -dдля реестра плюс аутентификация на 5001 с сгенерированными ключами JWT, а Helm устанавливается изoci://ghcr.io/bwalia/charts/nebulacrили репозитория GitHub Pages. Изображения с несколькими арками поставляются какlinux/amd64иlinux/arm64на Docker Hub и GHCR. Производственные группы подключаютdeploy/helm/nebulacrк входному TLS, дополнительному OIDC и S3, очистке ServiceMonitor и шаблонам NetworkPolicy из диаграммы.

Как Workstation может помочь

Workstation разрабатывает и реализует шаблоны проектирования безопасных платформ — частные реестры, конвейеры продвижения GitOps, политику как код и возможность наблюдения за SRE — в облачных и локальных средах. Для обзора архитектуры или поддержки доставки обращайтесь кпо адресу info@workstation.co.uk.