NebulaCR : registre Enterprise OCI, observabilité et conformité sans compromis

Résumé

NebulaCRest un registre de conteneursOCI open source et natif cloudécrit en Rust. Il associe un servicede registre de nébuleuseconforme aux normes (port 5000) avec un service de jetond'authentification de nébuleusedédié (port 5001), une intégrationHashiCorp Vaulten option pour la signature des clés, un stockage d'objetsenfichable(système de fichiers, S3, GCS, Azure Blob) et un stockage d'objets enfichable (système de fichiers, S3, GCS, Azure Blob)Kubernetes Emballageavec CRD pour les locataires, les projets et les politiques. Le projet en amont positionne le produit autour d'une distribution d'images privée, observable et gouvernable ; voirnebulacr.orgpour la page de destination publique etgithub.com/bwalia/nebulacrpour la source et les versions.

Pourquoi les entreprises adoptent un registre OCI privé

Les images de conteneurs constituent désormais l'unité de déploiement de la plupart des équipes cloud natives. Un registre qui réside uniquement à l'intérieur de votre limite de sécurité vous permet d'appliquer la résidence des données, les contrôles de chaîne d'approvisionnement,RBAC à granularité fineet le coût prévisible(en particulier lorsqu'ils sont combinés avec une mise en cache pull-through pour les registres en amont). NebulaCR cible les opérateurs qui ont besoin de flux de travail compatibles Docker sans renoncer à l'identité, à l'auditabilité ou à la résilience multirégionale.

Espace de travail Rust (Cargo.toml)

En amontCargo.tomldéclare un espace de travail de sept caisses :nebula-common,nebula-auth,nebula-registry,nebula-controller,nébuleuse-résilience,nébuleuse-miroiretnébuleuse-réplication. L'arborescence du projet README mappe chaque caisse à des binaires ou des bibliothèques : services de registre et d'authentification, le réconciliateur Kubernetes, le moteur de cache pull-through, les assistants de résilience et la réplication multirégionale. À partir des sources, exécutezcargo build --workspace --releaseetcargo test --workspaceavant de conteneuriser avec la racineDockerfileouDockerfile.scratchoptimisé.

Architecture distillée à partir de la documentation du projet

Au-delà des trois binaires/bibliothèques de base décrits ci-dessus, le contrôleur de nébuleuseréconcilie locataire/projet/AccessPolicy/TokenPolicy CRDs,Le miroir nébuleuseimplémente la mise en cache pull-through pour les registres en amont, leà résilience nébuleuseeffectue des tentatives et des disjoncteurs pour les chemins de réplication, et leréplication nébuleuseprend en charge les modes asynchrones ou semi-synchronisés multirégions avec basculement décrit dansdocs/architecture.md. Registre de nébuleusereste basé sur Axum avec application JWT par demande ;nebula-authvalide les jetons d'identité OIDC et émet des JWT de registre de courte durée. Le stockage reste hiérarchique par locataire/projet tandis que les backends restent connectables.

Routes d'entrée, contrôles de santé et métriques

L'architecture ASCII du README montre la répartition du trafic :/v2vers le service de registre (5000) et les flux d'authentification (souvent sous/auth) versnebula-auth(5001), avec des fournisseurs OIDC externes aux deux. Les graphiques Helm exposent les métriques Prometheus (les exemples incluentnebulacr_http_requests_total,nebulacr_http_request_duration_seconds,nebulacr_storage_operations_total,nebulacr_auth_tokens_issued_total) et documententcurl http://localhost:5000/healthaprèskubectl port-forwardau service de registre.

Authentification zéro confiance et intégration CI

NebulaCR met l'accent sursans mots de passe de registre de longue duréepour l'automatisation. Les systèmes CI présentent des jetons d'identité OIDC provenant d'émetteurs de confiance ; nebula-auth valide les signatures, applique la politique et renvoie les JWT étendus avec des valeurs de durée de vie par défaut strictes (généralement environ cinq minutes). Les opérateurs humains s'authentifient via des flux de codes d'autorisation OIDC standard avec PKCE auprès de fournisseurs tels que Azure AD, Okta ou Google Workspace.

CRD, cache pull-through et limites de débit

Les opérateurs Kubernetes gèrentTenant(quotas, liaisons OIDC),Project(groupes de référentiels et politiques),AccessPolicy(RBAC) etTokenPolicy(TTL et robots). comptes). Le README documente les extraits tels que les préfixesdocker pull <host>:5000/library/nginx:latest, GHCR et Quay, ainsi qu'une strophe miroircontainerdpointantdocker.iovers NebulaCR. La limitation du débit s'applique par IP et par locataire utilisant la caissegovernor.

Observabilité, audit et conformité

Selon la documentation du projet définie sousdocs/, NebulaCR expose les métriquesPrometheusdes services de registre et d'authentification, émet des journaux JSON structuréset prend en charge le traçageOpenTelemetrypour une analyse plus approfondie. Le tableau de bord intégré présente CPU, la mémoire, le disque, l'état de réplication, la navigation dans les référentiels et les pistes d'audit filtrées pour les push, pulls et suppressions – des preuves matérielles pour les examens de sécurité.SCIM 2.0 Le provisioningautomatise les cycles d'arrivée, de déménagement et de départ avec les fournisseurs d'identité, réduisant ainsi la fenêtre pendant laquelle les anciens employés conservent un accès latent.

Cache haute disponibilité, multirégion et pull-through

Le fichier README met en évidence les services sans étatavec mise à l'échelle automatique des pods horizontaux, budgets de perturbation des pods et disjoncteurs pour les chemins de réplication. La réplication multirégionale est décrite comme asynchrone avec des contrôles de résilience, de sorte que les lectures peuvent basculer lorsqu'une région se dégrade. La mise en cache pull-through réduit la bande passante et la latence d'extraction pour les registres en amont, notamment Docker Hub, GHCR, GCR, Quay.io et Registry.k8s.io.

Mise en route

Pour un essai local minimal, les documents READMEdocker run -p 5000:5000 bwalia/nebulacr:latest,docker compose up -dpour le registre plus l'authentification sur 5001 avec les clés JWT générées et les installations Helm à partir deoci://ghcr.io/bwalia/charts/nebulacrou du dépôt GitHub Pages. Les images multi-arcades sont livrées sous les nomslinux/amd64etlinux/arm64sur Docker Hub et GHCR. Les équipes de production connectent ledeploy/helm/nebulacrà l'entrée TLS, aux modèles OIDC et S3 en option, au scraping ServiceMonitor et aux modèles NetworkPolicy à partir du graphique.

Comment Workstation peut aider

Workstation conçoit et met en œuvre des modèles d'ingénierie de plateforme sécurisée (registres privés, pipelines de promotion GitOps, politique en tant que code et observabilité SRE) dans les environnements cloud et sur site. Pour des révisions d'architecture ou une assistance à la livraison, contactezinfo@workstation.co.uk.