NebulaCR: Registro, observabilidad y cumplimiento de Enterprise OCI sin concesiones

Resumen ejecutivo

NebulaCRes un registro de contenedorOCIde código abierto y nativo de la nube escrito en Rust. Combina un serviciode registro de nebulosacompatible con los estándares (puerto 5000) con un servicio de tokende autenticación de nebulosadedicado (puerto 5001), integración opcional deHashiCorp Vaultpara firmar claves, almacenamiento de objetosconectable(sistema de archivos, S3, GCS, Azure Blob) y paquetesKubernetesde primera clase con CRD para inquilinos, proyectos y políticas. El proyecto upstream posiciona el producto en torno a una distribución de imágenes privada, observable y gobernable; consultenebulacr.orgpara ver la página de inicio pública ygithub.com/bwalia/nebulacrpara obtener fuentes y versiones.

Por qué las empresas adoptan un registro OCI privado

Las imágenes de contenedor son ahora la unidad de implementación para la mayoría de los equipos nativos de la nube. Un registro que solo se encuentra dentro de su límite de seguridad le permite aplicar la residencia de datos, los controles de la cadena de suministro, eldetallado RBACy el costo predecible(especialmente cuando se combina con el almacenamiento en caché extraíble para registros ascendentes). NebulaCR está dirigido a operadores que necesitan flujos de trabajo compatibles con Docker sin renunciar a la identidad, la auditabilidad o la resiliencia multirregional.

Espacio de trabajo de Rust (Cargo.toml)

UpstreamCargo.tomldeclara un espacio de trabajo de siete cajas:nebula-common,nebula-auth,nebula-registry,controlador de nebulosa,resistencia de nebulosa, espejo de nebulosay replicación de nebulosa. El árbol de proyectos del README asigna cada caja a archivos binarios o bibliotecas: servicios de registro y autenticación, el reconciliador Kubernetes, motor de caché extraíble, ayudas de resiliencia y replicación multirregional. Desde la fuente, ejecutecargo build --workspace --releaseycargo test --workspaceantes de crear contenedores con elDockerfileraíz o elDockerfile.scratchoptimizado.

Arquitectura extraída de la documentación del proyecto

Más allá de los tres binarios/bibliotecas principales descritos anteriormente, el controlador de nebulosaconcilia Inquilino/Proyecto/AccessPolicy/TokenPolicy CRDs,nebula-mirrorimplementa almacenamiento en caché pull-through para registros ascendentes,nebula-resiliencelleva reintentos y disyuntores para rutas de replicación, ynebula-replicationrespalda modos asíncronos o semisincronizados multirregionales con conmutación por error descrita endocs/architecture.md.nebula-registrysigue basado en Axum con aplicación JWT por solicitud;nebula-authvalida tokens de identidad OIDC y emite JWT de registro de corta duración. El almacenamiento permanece jerárquico por inquilino/proyecto, mientras que los backends siguen siendo conectables.

Rutas de ingreso, comprobaciones de estado y métricas

La arquitectura ASCII del README muestra la división del tráfico:/v2al servicio de registro (5000) y flujos de autenticación (a menudo bajo/auth) anebula-auth(5001), con proveedores OIDC externos a ambos. Los gráficos Helm exponen las métricas de Prometheus (los ejemplos incluyennebulacr_http_requests_total,nebulacr_http_request_duration_seconds,nebulacr_storage_operations_total,nebulacr_auth_tokens_issued_total) y documentancurl http://localhost:5000/healthdespués dekubectl port-forwarden el servicio de registro.

Autenticación de confianza cero e integración de CI

NebulaCR enfatizasin contraseñas de registro de larga duraciónpara la automatización. Los sistemas de CI presentan tokens de identidad OIDC de emisores confiables; nebula-auth valida firmas, aplica políticas y devuelve JWT con alcance con valores predeterminados de TTL estrictos (comúnmente alrededor de cinco minutos). Los operadores humanos se autentican a través de flujos de códigos de autorización OIDC estándar con PKCE contra proveedores como Azure AD, Okta o Google Workspace.

CRD, caché de extracción y límites de velocidad

Los operadores de Kubernetes administranTenant(cuotas, enlaces OIDC),Project(políticas y grupos de repositorio),AccessPolicy(RBAC) yTokenPolicy(TTL y cuentas robot). El archivo README documenta extracciones como los prefijosdocker pull <host>:5000/library/nginx:latest, GHCR y Quay, y una estrofa de espejocontainerdque apunta adocker.ioa NebulaCR. La limitación de velocidad se aplica por IP y por inquilino utilizando la cajagovernor.

Observabilidad, auditoría y cumplimiento

Según la documentación del proyecto establecida endocs/, NebulaCR exponeMétricas de Prometheusde servicios de registro y autenticación, emiteJSON estructurado registray admite el rastreoOpenTelemetrypara un análisis más profundo. El panel integrado muestra CPU, memoria, disco, estado de replicación, exploración de repositorios y pistas de auditoría filtradas para envíos, extracciones y eliminaciones: evidencia material para revisiones de seguridad.SCIM 2.0 El aprovisionamientoautomatiza los ciclos de entrada, salida y salida con proveedores de identidad, reduciendo la ventana donde los antiguos empleados retienen el acceso latente.

Caché pull-through, multirregional y de alta disponibilidad

El README destaca los servicios sin estadocon escalado automático de pod horizontal, presupuestos de interrupción de pod y disyuntores para rutas de replicación. La replicación multirregional se describe como asincrónica con controles de resiliencia, por lo que las lecturas pueden fallar cuando una región se degrada. El almacenamiento en caché de extracción reduce el ancho de banda y la latencia de extracción para los registros ascendentes, incluidos Docker Hub, GHCR, GCR, Quay.io y registro.k8s.io.

Introducción

Para una prueba local mínima, los documentos READMEdocker run -p 5000:5000 bwalia/nebulacr:latest,docker compose up -dpara el registro más autenticación en 5001 con claves JWT generadas y Helm se instalan desdeoci://ghcr.io/bwalia/charts/nebulacro el repositorio de GitHub Pages. Las imágenes de múltiples arcos se envían comolinux/amd64ylinux/arm64en Docker Hub y GHCR. Los equipos de producción conectandeploy/helm/nebulacrcon ingreso TLS, OIDC y S3 opcionales, raspado de ServiceMonitor y plantillas de NetworkPolicy del gráfico.

Cómo puede ayudar Workstation

Workstation diseña e implementa patrones de ingeniería de plataformas seguras (registros privados, canales de promoción de GitOps, políticas como código y observabilidad de SRE) en entornos locales y de nube. Para revisiones de arquitectura o soporte de entrega, comuníquese coninfo@workstation.co.uk.