NebulaCR: Registro, observabilidade e conformidade do Enterprise OCI sem compromisso
Arquitetura, autenticação de confiança zero, observabilidade e operações Kubernetes
Resumo executivo
NebulaCRé um registro de contêinerOCI de código aberto e nativo da nuvemescrito em Rust. Ele combina um serviçode registro de nebulosacompatível com os padrões (porta 5000) com um serviço de tokende autenticação de nebulosadedicado (porta 5001), integração opcionalHashiCorp Vaultpara assinatura de chaves, armazenamento de objetoconectável(sistema de arquivos, S3, GCS, Azure Blob) e embalagensKubernetesde primeira classe com CRDs para locatários, projetos e políticas. O projeto upstream posiciona o produto em torno da distribuição de imagens privadas, observáveis e governáveis; consultenebulacr.orgpara a página de destino pública egithub.com/bwalia/nebulacrpara fontes e lançamentos.
Por que as empresas adotam um registro OCI privado
As imagens de contêiner são agora a unidade de implantação para a maioria das equipes nativas da nuvem. Um registro que reside apenas dentro do seu limite de segurança permite impor a residência de dados, controles da cadeia de suprimentos,RBAC refinadoede custo previsível(especialmente quando combinado com cache pull-through para registros upstream). O NebulaCR é direcionado a operadoras que precisam de fluxos de trabalho compatíveis com Docker sem abrir mão de identidade, auditabilidade ou resiliência multirregional.
Rust espaço de trabalho (Cargo.toml)
UpstreamCargo.tomldeclara um espaço de trabalho de sete caixas:nebula-common,nebula-auth,nebula-registry,controlador de nebulosa,resiliência de nebulosa,espelho de nebulosae replicação de nebulosa. A árvore do projeto README mapeia cada caixa para binários ou bibliotecas – serviços de registro e autenticação, reconciliador Kubernetes, mecanismo de cache pull-through, auxiliares de resiliência e replicação multirregional. A partir da origem, executecargo build --workspace --releaseecargo test --workspaceantes de colocar em contêiner com oDockerfileraiz ou oDockerfile.scratchotimizado.
Arquitetura destilada da documentação do projeto
Além dos três binários/bibliotecas principais descritos acima, o controlador de nebulosareconcilia Tenant/Project/AccessPolicy/TokenPolicy CRDs, espelho de nebulosaimplementa cache pull-through para registros upstream, resiliência de nebulosacarrega novas tentativas e disjuntores para caminhos de replicação e replicação de nebulosasuporta modos assíncronos ou semi-sincronizados multirregionais com failover descrito emdocs/architecture.md. Registro de nebulosapermanece baseado em Axum com aplicação de JWT por solicitação;nebula-authvalida tokens de identidade OIDC e emite JWTs de registro de curta duração. O armazenamento permanece hierárquico por locatário/projeto enquanto os back-ends permanecem conectáveis.
Rotas de entrada, verificações de integridade e métricas
A arquitetura ASCII do README mostra a divisão de tráfego:/v2para o serviço de registro (5000) e fluxos de autenticação (geralmente sob/auth) paranebula-auth(5001), com provedores OIDC externos a ambos. Os gráficos Helm expõem métricas Prometheus (exemplos incluemnebulacr_http_requests_total,nebulacr_http_request_duration_seconds,nebulacr_storage_operations_total,nebulacr_auth_tokens_issued_total) e documentamcurl http://localhost:5000/healthapóskubectl port-forwardpara o serviço de registro.
Autenticação de confiança zero e integração de CI
NebulaCR enfatizasem senhas de registro de longa duraçãopara automação. Os sistemas CI apresentam tokens de identidade OIDC de emissores confiáveis; nebula-auth valida assinaturas, aplica políticas e retorna JWTs com escopo definido com padrões TTL rígidos (geralmente em torno de cinco minutos). Os operadores humanos autenticam por meio de fluxos de código de autorização OIDC padrão com PKCE em provedores como Azure AD, Okta ou Google Workspace.
CRDs, cache pull-through e limites de taxa
Operadores Kubernetes gerenciamTenant(cotas, ligações OIDC),Project(grupos de repositórios e políticas),AccessPolicy(RBAC) eTokenPolicy(TTL e contas de robô). O README documenta pull-through pulls comodocker pull <host>:5000/library/nginx:latest, GHCR e prefixos Quay, e uma estrofe de espelhocontainerdapontandodocker.iopara NebulaCR. A limitação de taxa se aplica por IP e por locatário usando a caixagovernor.
Observabilidade, auditoria e conformidade
De acordo com a documentação do projeto definida emdocs/, NebulaCR expõemétricas Prometheusde serviços de registro e autenticação, emiteestruturado JSON registrae suporta rastreamentoOpenTelemetrypara análises mais profundas. O painel integrado apresenta CPU, memória, disco, integridade de replicação, navegação em repositórios e trilhas de auditoria filtradas para push, pull e exclusões – evidências materiais para análises de segurança.SCIM 2.0 O provisionamentoautomatiza os ciclos de ingresso-mover-deixar com provedores de identidade, diminuindo a janela onde ex-funcionários mantêm acesso latente.
Alta disponibilidade, multirregião e cache pull-through
O README destaca os serviços sem estado docom escalonamento automático de pod horizontal, orçamentos de interrupção de pod e disjuntores para caminhos de replicação. A replicação multirregional é descrita como assíncrona com controles de resiliência para que as leituras possam falhar quando uma região se degrada. O cache pull-through reduz a largura de banda e a latência de pull para registros upstream, incluindo Docker Hub, GHCR, GCR, Quay.io e Registry.k8s.io.
Introdução
Para uma avaliação local mínima, os documentos READMEdocker run -p 5000:5000 bwalia/nebulacr:latest,docker compose up -dpara registro mais autenticação em 5001 com chaves JWT geradas e instalações Helm dooci://ghcr.io/bwalia/charts/nebulacrou do repositório GitHub Pages. As imagens multiarquitetura são fornecidas comolinux/amd64elinux/arm64no Docker Hub e GHCR. As equipes de produção conectam odeploy/helm/nebulacrcom entrada TLS, OIDC e S3 opcionais, raspagem de ServiceMonitor e modelos NetworkPolicy do gráfico.
Como o Workstation pode ajudar
Workstation projeta e implementa padrões de engenharia de plataforma segura — registros privados, pipelines de promoção GitOps, política como código e observabilidade SRE — em ambientes de nuvem e locais. Para análises de arquitetura ou suporte de entrega, entre em contato cominfo@workstation.co.uk.