|Index|Primeiros passos com SUSE Private Registry
SUSE Private Registry

Primeiros passos com SUSE Private Registry

Publication Date: 2026-05-04

Release notes

SUSE Private Registry is an on-premises container registry. It is designed for SUSE customers who need a container registry that works well with other SUSE services and products.

This document provides a high-level overview of the features, capabilities and limitations of SUSE Private Registry, and highlights important product updates.

1 Release 1.2.0

Security updates:

Component updates:

  • Updates k8s.io/client-go to 0.34.1.

  • Updates aws-sdk-go to 1.55.8.

  • Updates go-ldap to 3.4.11.

  • Updates Go to 1.25.9.

New features and performance:

  • Adds support for the Cosign v3 Bundle signature format.

  • Introduces an option to disable audit log recording to the database during initialization.

  • Enables pprof support and the ability to export the Harbor version via the Prometheus exporter binary.

  • Replaces the existing pull-through cache with a new proxy cache implementation.

  • Improves general performance through code refactoring (for example, by using strings.Builder and strings.CutPrefix).

Key fixes:

  • Implements a security fix to reject bearer tokens issued before project creation.

  • Fixes issues related to OpenID Connect (OIDC) integration for users with a single group.

  • Corrects errors in user and group search functionality.

  • Resolves various user interface (UI) issues, including an unwanted scrollbar in tag retention and issues with the "Copy Pull Button" when tags are undefined.

  • Adds support for both docker-compose v1 and docker-compose v2.

  • Calls the /v2/auth/token application programming interface (API) to get a bearer token for the Docker Hub adapter.

Container image updates:

  • private-registry/harbor-core:1.1.2 ➡ private-registry/1.2/harbor-core:1.2.0

  • private-registry/harbor-exporter:1.1.2 ➡ private-registry/1.2/harbor-exporter:1.2.0

  • private-registry/harbor-jobservice:1.1.2 ➡ private-registry/1.2/harbor-jobservice:1.2.0

  • private-registry/harbor-portal:1.1.2 ➡ private-registry/1.2/harbor-portal:1.2.0

  • private-registry/harbor-registry:1.1.2 ➡ private-registry/1.2/harbor-registry:1.2.0

  • private-registry/harbor-registryctl:1.1.2 ➡ private-registry/1.2/harbor-registryctl:1.2.0

  • private-registry/harbor-trivy-adapter:1.1.2 ➡ private-registry/1.2/harbor-trivy-adapter:1.2.0

Helm chart updates:

  • The chart is the version 1.2.x will be in oci://registry.suse.com/private-registry/1.2/private-registry-helm

  • Makes health probe timeoutSeconds and failureThreshold configurable via values.

  • Fixes extra environment variables for the exporter.

  • Installs PodDisruptionBudget resources when the replica count is greater than one.

Upgrade notes:

  • No breaking changes in this release.

2 Release 1.1.3

Security updates:

Key fixes:

  • Fixed SessionRegenerate arguments/lifetime and prevented background polling from artificially renewing session TTLs.

  • Fixes scanner application programming interface (API) issues and resolves an issue that occurs when editing distribution instances without credentials.

  • Calls the /v2/auth/token API to get a bearer token for the Docker Hub adapter.

  • Bumped Go to version 1.25.9 and upgraded the OpenTelemetry SDK and go-jose packages.

Container image updates:

  • private-registry/harbor-core:1.1.2 ➡ private-registry/harbor-core:1.1.3

  • private-registry/harbor-exporter:1.1.2 ➡ private-registry/harbor-exporter:1.1.3

  • private-registry/harbor-jobservice:1.1.2 ➡ private-registry/harbor-jobservice:1.1.3

  • private-registry/harbor-portal:1.1.2 ➡ private-registry/harbor-portal:1.1.3

  • private-registry/harbor-registry:1.1.2 ➡ private-registry/harbor-registry:1.1.3

  • private-registry/harbor-registryctl:1.1.2 ➡ private-registry/harbor-registryctl:1.1.3

  • private-registry/harbor-trivy-adapter:1.1.2 ➡ private-registry/harbor-trivy-adapter:1.1.3

  • suse/postgres:17.9 ➡ suse/postgres:17.10

  • suse/nginx:1.21 ➡ suse/nginx:1.27

Upgrade notes:

  • No breaking changes in this release.

3 Release 1.1.2

Security Updates:

  • CVE-2026-4404: Use of hard coded credentials allows attackers to use the default password and gain access to the Web UI, if not set during installation or upgrade.

Now if the HARBOR_ADMIN_PASSWORD is not set during the installation or upgrade, it will be generated randomly and stored in a Kubernetes secret. This change mitigates the risk of using a default password and enhances the security of the installation.

Upgrade Notes:

No breaking changes in this release.

4 Release 1.1.1

Security Updates:

Container Image Updates:

  • private-registry/harbor-core:1.1.0 ➡ private-registry/harbor-core:1.1.1

  • private-registry/harbor-exporter:1.1.0 ➡ private-registry/harbor-exporter:1.1.1

  • private-registry/harbor-jobservice:1.1.0 ➡ private-registry/harbor-jobservice:1.1.1

  • private-registry/harbor-portal:1.1.0 ➡ private-registry/harbor-portal:1.1.1

  • private-registry/harbor-registry:1.1.0 ➡ private-registry/harbor-registry:1.1.1

  • private-registry/harbor-registryctl:1.1.0 ➡ private-registry/harbor-registryctl:1.1.1

  • private-registry/harbor-trivy-adapter:1.1.0 ➡ private-registry/harbor-trivy-adapter:1.1.1

Upgrade Notes:

No breaking changes in this release.

5 Release 1.1.0

Security Updates:

Container Image Updates:

  • Update the base image bci/bci-micro:15.6 to bci/bci-micro:15.7

  • Updated images:

    • private-registry/harbor-valkey:8.0.6 ➡ suse/valkey:8.0.6

    • private-registry/harbor-db:2.13.2 (postgres 17) ➡ suse/postgres:17.6

    • private-registry/harbor-nginx:1.21 ➡ suse/nginx:1.21

Upgrade Notes:

Images are now tagged with the SUSE Private Registry version instead of the corresponding Harbor version. The change in image versioning scheme is handled by Helm when upgrading the installation using the chart:

  • private-registry/harbor-core:1.1.0

  • private-registry/harbor-exporter:1.1.0

  • private-registry/harbor-jobservice:1.1.0

  • private-registry/harbor-portal:1.1.0

  • private-registry/harbor-registry:1.1.0

  • private-registry/harbor-registryctl:1.1.0

  • private-registry/harbor-registryctl:1.1.0

No breaking changes in this release.

6 Release 1.0.1

Security updates:

  • CVE-2025-55198: Helm may panic due to incorrect YAML content.

  • CVE-2025-55199: Helm charts with specific JSON schema values can cause memory exhaustion.

  • CVE-2025-54410: Moby versions before 25.0.13, when firewall reloads, Docker fails to re-create iptables rules isolating bridge networks. This allows any container to access all ports on any other container across different bridge networks on the same host and breaks network segmentation in multi-tenant environments (only --internal networks remain protected).

  • CVE-2025-29923: go-redis allows potential out of order responses when CLIENT SETINFO times out during connection establishment.

  • CVE-2025-54388: Moby versions 28.2.0–28.3.2 fails to re-create iptables rules after a firewall reloads. This exposes containers with localhost-published ports (e.g., 127.0.0.1:8080) to remote access via the Docker bridge, while unpublished ports remain protected; fixed in version 28.3.3.

  • GHSA-2464-8j7c-4cjm: go-viper’s map structure may leak sensitive information in logs when processing malformed data.

  • CVE-2025-8959: HashiCorp go-getter vulnerable to arbitrary read through a symlink attack.

  • CVE-2025-58058: github.com/ulikunitz/xz leaks memory when decoding a corrupted multiple LZMA archives.

  • CVE-2025-53547: Helm chart dependency updating with malicious Chart.yaml content and symlink can lead to code execution.

Bugs fixed:

  • Trivy: the correct version is shown when calling trivy version.

Container image updates:

  • Valkey updated from 8.0.2 ➡ 8.0.6.

Upgrade notes:

  • No breaking changes in this release.

7 Release 1.0

Key features:

  • SUSE Private Registry is based on Harbor 2.13.2

    • Integration with Model Spec for first-class handling of AI models

    • Enhanced audit logging

  • Predictable release cycle aligned with SUSE Rancher Prime. SUSE Private Registry will be updated every 4 months

  • Each release is supported by SUSE for 18 months from the date of release

    • 6 months of security and bug fix maintenance, followed by

    • 12 months of security-only maintenance

  • Can be used to mirror SUSE Coleção de Aplicativos

  • Supports SUSE Segurança as an external scanner

SUSE Private Registry includes all the features of Harbor:

  • On-premises private container image and OCI artifact registry

  • Web interface for administration

  • Role-based Access Control

  • Fine-grained project configuration for image and artifact storage

  • Mirroring and pull-through caching of upstream registries' artifacts

  • Image retention and garbage collection controls

  • Scanning images for security vulnerabilities with the Trivy scanner

  • Generate SBOMs for stored images

  • Content trust with Cosign (Notary is not included)

Lei de direito autoral

Copyright © 20XX–2026-07-09 SUSE LLC e colaboradores. Todos os direitos reservados.

Permissão concedida para copiar, distribuir e/ou modificar este documento sob os termos da Licença GNU de Documentação Livre, Versão 1.2 ou (por sua opção) versão 1.3; com a seção invariante sendo estas informações de copyright e licença. Uma cópia da versão 1.2 da licença está incluída na seção intitulada 'GNU Free Documentation License'.

Para marcas SUSE, veja https://www.suse.com/company/legal/. Todas as marcas registradas de terceiros pertencem aos seus respectivos proprietários. Os símbolos de marca registrada (®, ™ etc.) indicam marcas registradas de SUSE e de suas afiliadas. Os asteriscos (*) indicam marcas registradas de terceiros.

Todas as informações deste manual foram compiladas com a maior atenção possível aos detalhes. Entretanto, isso não garante uma precisão absoluta. Nem SUSE LLC, nem suas afiliadas, nem os autores, nem os tradutores serão responsabilizados por possíveis erros ou pelas consequências resultantes.

1 Introdução

1.1 O que é o comando SUSE Private Registry?

SUSE Private Registry (Registro Privado) é um registro de contêiner no local. Registro Privado é projetado para clientes SUSE que precisam de um registro de contêiner que funcione bem com outros serviços e produtos SUSE.

1.2 Quais são os benefícios de SUSE Private Registry?

Registro Privado é baseado no projeto Harbor e inclui todos os seus recursos principais, além de benefícios adicionais. Por exemplo:

  • Registro de contêiner no local. Registro Privado é um registro de contêiner hospedado localmente com acesso a serviços de registro SUSE online.

  • Segurança. Registro Privado oferece considerações de segurança para ambientes conteinerizados. Inclui autenticação, autorização e varredura de vulnerabilidades.

  • Flexibilidade de implantação. Você pode instalar Registro Privado em um ambiente Kubernetes como SUSE Rancher Prime: RKE2. Você também pode implantar Registro Privado com configuração de alta disponibilidade.

  • Gerenciamento de usuários. Registro Privado fornece um mecanismo de autenticação e autorização com controle de acesso com base em função (RBAC).

  • Interface do usuário. Além de uma interface de linha de comando, você pode administrar Registro Privado via interface web do usuário.

1.3 Como funciona o SUSE Private Registry?

Registro Privado é entregue como Open Container Initiative (OCI) containers e é esperado que seja implantado em um cluster Kubernetes. Registro Privado consiste nos seguintes contêineres:

  • harbor-core: o componente principal do registro Harbor, responsável por gerenciar funcionalidades principais, como gerenciamento de projetos, repositórios e interações de usuários.

  • harbor-db: o contêiner de banco de dados que armazena todos os metadados relacionados a imagens, usuários e configurações para o registro Harbor.

  • harbor-jobservice: um serviço que gerencia trabalhos em segundo plano, como replicação de imagens e tarefas agendadas, garantindo processamento eficiente de operações dentro do registro.

  • harbor-nginx: o proxy reverso e balanceador de carga que roteia solicitações recebidas para os serviços Harbor apropriados, fornecendo um único ponto de entrada para os usuários.

  • harbor-portal: a interface web que permite aos usuários interagir com o registro Harbor, gerenciar imagens e configurar as configurações por meio de uma interface gráfica.

  • harbor-registry: o contêiner que serve como o back end de armazenamento real de imagens, lidando com o armazenamento e recuperação de imagens de contêiner.

  • harbor-registryctl: uma ferramenta de linha de comando para gerenciar o registro Harbor, permitindo que os usuários realizem tarefas administrativas e configurações diretamente do terminal.

  • harbor-trivy-adapter: um contêiner que integra o Trivy scanner de vulnerabilidades com Harbor, permitindo a varredura de segurança automatizada de imagens de contêiner em busca de vulnerabilidades.

  • harbor-exporter: o contêiner que exporta Harbor métricas em um formato que pode ser coletado por Prometheus para monitoramento e observabilidade.

  • harbor-valkey: um armazenamento de chave-valor em memória.

Após a implantação, você pode fazer login via interface web. Após a autenticação e autorização bem-sucedidas, você pode configurar múltiplos aspectos do produto, por exemplo:

  • Configure configurações globais, como definir o registro para modo somente leitura ou restringir quem pode criar projetos.

  • Selecione um método de autenticação.

  • Adicione usuários quando estiver no modo de autenticação de banco de dados e atribua o papel de administrador a outros usuários.

  • Aplique quotas de recursos aos projetos.

  • Configure a replicação de imagens entre instâncias Registro Privado.

1.4 Para obter mais informações

Consulte as seguintes fontes para obter mais detalhes:

2 Requisitos

Esta seção descreve os pré-requisitos mínimos da plataforma e o dimensionamento de produção recomendado para SUSE Private Registry.

2.1 Pré-requisitos

  • Versão 1.20 ou superior do Kubernetes cluster

  • HelmVersão 3.2.0 ou superior

  • Suporte a provisionador de Volume Persistente (PV) em sua infraestrutura

  • Uma assinatura ativa para SUSE Private Registry

2.2 Recomendações de hardware e dimensionamento

Use esses valores como um ponto de partida para a produção. Ajuste com base na política de retenção, rotatividade de imagens, concorrência de varredura e tráfego de replicação. ==== Linha de Base do Cluster

EscopoPonto de partida recomendado

Nós de trabalho

Mínimo de 3 nós de trabalho

Formato do nó

Mínimo de 4 vCPU e 16 GiB de RAM por nó

Formato de nó preferido

8 vCPU e 32 GiB de RAM por nó para maior concorrência de varredura e de push

Essas recomendações estão alinhadas com a orientação do Rancher para o RKE2 Kubernetes. Para detalhes, veja Requisitos de instalação do RKE2 Kubernetes.

2.2.1 Linha de Base de Armazenamento Persistente

ComponenteTamanho padrão do gráficoTamanho de partida recomendado

Dados do registro

5 Gi

500 Gi a 1 Ti

Cache e DB do Trivy

5 Gi

20 Gi a 50 Gi

Registros do Jobservice

1 Gi

10 Gi

PostgreSQL Interno (se utilizado)

1 Gi

Mínimo de 20 Gi

Valkey Interno (se utilizado)

1 Gi

Mínimo de 20 Gi

Os padrões do gráfico são orientados para instalação e não devem ser usados como valores de capacidade de produção a longo prazo.

3 Instalação usando o Rancher UI

Para instalar SUSE Private Registry usando o Rancher UI, você deve atender aos seguintes requisitos e seguir os passos abaixo.

3.1 Quais requisitos preciso atender?

  • Um ambiente com um ou mais clusters Kubernetes suportados em execução e Rancher implantado. Consulte Rancher requisitos de instalação para mais detalhes.

  • Credenciais SUSE Registro para uma conta com uma assinatura SUSE Private Registry (um nome de usuário e uma senha/token). Consulte Obtendo Kubernetes segredos de SCC para mais detalhes.

3.2 Quais são os passos para instalar SUSE Private Registry usando o Rancher UI?

ETAPA 1: Diga ao Rancher onde o repositório SUSE Private Registry está localizado para procurar o chart de instalação.
  1. Faça login no Rancher.

  2. Clique no menu de três linhas (☰) no canto superior esquerdo, selecione Gerenciamento de Cluster, e clique no nome do seu cluster, geralmente local.

  3. No menu à esquerda, selecione Apps › Repositórios.

  4. Clique no botão Criar no canto superior direito e preencha o formulário que se abre:

    1. Destino: Selecione Repositório OCI.

    2. Nome: Digite um nome para o repositório, como SUSE Private Registry.

    3. Descrição: Opcionalmente, adicione uma descrição do repositório.

    4. URL do Host do Repositório OCI: Enter `oci://registry.suse.com/private-registry/private-registry-helm`.

    5. Autenticação: Altere para Create an HTTP Basic Auth Secret e insira o nome de usuário e a senha das credenciais do registro.

  5. Confirme com Criar.

Uma captura de tela mostrando como adicionar um repositório SUSE Private Registry ao Rancher
Figure 3.1: Adicionando um repositório SUSE Private Registry
ETAPA 2: Crie um segredo para acessar as imagens no `registry.suse.com`.
  1. Clique no menu de três linhas (☰) no canto superior esquerdo e selecione Gerenciamento de Cluster.

  2. Mude para o cluster ao qual você deseja adicionar o segredo e clique em Explorar.

  3. Para navegar até o gerenciamento de segredos, selecione Armazenamento › Segredos e clique em Criar no canto superior direito.

  4. Selecione o segredo HTTP Basic Auth e, em seguida, o namespace private-registry.

  5. Digite suse-registry como o nome do segredo.

  6. Preencha os campos username e password com as credenciais SUSE obtidas em Section 3.1, “Quais requisitos preciso atender?”.

Uma captura de tela mostrando como adicionar segredos SUSE Private Registry ao Rancher
Figure 3.2: Adicionando segredos SUSE Private Registry
ETAPA 3: Instale o Helm chart.
  1. No menu principal à esquerda, selecione Apps › Charts.

  2. Digite o nome do SUSE Private Registry repositório atribuído na caixa de pesquisa. Por exemplo, SUSE Private Registry. Se não aparecer na lista, clique em Atualizar todos os repositórios.

  3. Clique no chart e visualize o README.md.

  4. Opcionalmente, você pode personalizar os valores de instalação. Ou clique nas seções do lado esquerdo do painel Edit Options para visualizar todos os valores que você pode configurar, ou edite os valores diretamente no arquivo YAML do chart.

  5. No canto superior direito, clique em Instalar esta versão.

Uma captura de tela mostrando a tela de instalação do SUSE Private Registry em Rancher
Figure 3.3: Instalando SUSE Private Registry

4 Instalação usando a linha de comando

Os seguintes procedimentos descrevem como implantar SUSE Private Registry (Registro Privado) em um cluster Kubernetes.

4.1 Obtendo segredos de Kubernetes do SUSE Atendimento ao Cliente

Para baixar e instalar as imagens de Registro Privado do SUSE Registro, você precisa de um segredo Kubernetes com as credenciais de espelhamento SUSE Atendimento ao Cliente (SCC). Para obter as credenciais de SCC, siga estes passos:

  1. Visite SUSE Atendimento ao Cliente em https://scc.suse.com e faça login.

  2. Selecione a organização com uma assinatura ativa de Registro Privado na barra lateral esquerda.

  3. Selecione Proxies no menu superior. As credenciais são exibidas no canto superior direito.

  4. Para ver a senha, clique no ícone de 'olho'.

  5. Crie um arquivo password.txt contendo a senha obtida.

    >head -1 ./password.txt | helm registry login registry.suse.com \
      --username <PRIVATE_REGISTRY_USERNAME> --password-stdin
  6. Crie um namespace para SUSE Registro.

    >kubectl create namespace <PRIVATE_REGISTRY_NAMESPACE>
  7. Armazene as credenciais de espelhamento recuperadas de SCC como segredos Kubernetes executando o seguinte comando:

    >kubectl create secret docker-registry suse-registry \
      --namespace <PRIVATE_REGISTRY_NAMESPACE> \
      --docker-server=registry.suse.com \
      --docker-username=<PRIVATE_REGISTRY_USERNAME> \
      --docker-password=$(head -1 ./password.txt)
  8. Opcionalmente, para usar comunicação criptografada por TLS, crie um segredo TLS a partir de seus arquivos de chave privada e certificado.

    >kubectl create secret tls suse-registry-tls \
      --namespace <PRIVATE_REGISTRY_NAMESPACE> \
      --cert=<CERTIFICATE>.pem \
      --key=<PRIVATE_KEY>.pem

4.2 Instalando e executando Registro Privado usando Helm

O seguinte procedimento descreve como instalar Registro Privado usando Helm. Substitua <RELEASE_NAME> pelo seu nome de lançamento personalizado para a implantação do gráfico Helm.

  1. Faça login em SUSE Registro usando as credenciais de espelhamento SCC obtidas.

    >head -1 ./password.txt | helm registry login registry.suse.com \
      --username <SUSE_REGISTRY_USERNAME> --password-stdin
  2. Instale a versão mais recente do gráfico Registro Privado Helm.

    >helm install <RELEASE_NAME> \
      oci://registry.suse.com/private-registry/private-registry-helm \
      --namespace <PRIVATE_REGISTRY_NAMESPACE>

    Quando você instala o gráfico Registro Privado Helm, ele exibe a seguinte saída:

    NOTES:
    CHART VERSION: 1.1.6
    It may take several minutes for the SUSE Private Registry  1.1.2 deployment to complete.
    
    Once the deployment has finished, you will be able to open the SUSE Private Registry portal at https://core.harbor.domain
    
    To get the admin credentials, copy and run the following commands:
    
    echo Username: "admin"
    echo Password: $(kubectl get secret --namespace <PRIVATE_REGISTRY_NAMESPACE>-harbor-core <RELEASE_NAME> -o jsonpath="{.data.HARBOR_ADMIN_PASSWORD}" | base64 -d)

    Com a versão 4 do Helm, você pode usar um digest para especificar o gráfico a ser instalado:

    >helm install <RELEASE_NAME> \
      oci://registry.suse.com/private-registry/private-registry-helm@sha256:<DIAGEST_OF_CHART_TO_INSTALL> \
      --namespace <PRIVATE_REGISTRY_NAMESPACE>
Tip
Tip
  • Para obter a senha do usuário administrador, você também pode executar o seguinte comando:

    >kubectl get secret \
      --namespace <PRIVATE_REGISTRY_NAMESPACE> \
      --harbor-core <RELEASE_NAME> \
      -o jsonpath="{.data.HARBOR_ADMIN_PASSWORD}" | base64 -d; echo
  • É possível usar o kstatus watcher com a flag '--wait=watcher' para garantir que todos os objetos estejam prontos para finalizar a instalação. Usar o watcher pode fazer com que o comando demore mais.

Para substituir a instalação padrão por valores personalizados do arquivo suse_registry_override.yaml, consulte Appendix A, Substituindo o gráfico SUSE Private Registry Helm.

O comando começa a implantar vários contêineres relacionados e pode levar vários minutos para ser concluído. Ele também imprime uma mensagem com a URL do Registro Privado portal Web e comandos para obter as credenciais do administrador.

4.3 Fazer upgrade de Registro Privado

Para fazer upgrade da versão do gráfico Helm para uma versão mais nova específica, execute o seguinte comando:

>helm upgrade <RELEASE_NAME> \
  oci://registry.suse.com/private-registry/private-registry-helm \
  --version <NEW_VERSION_OF_HELM_CHART> \
  --namespace <PRIVATE_REGISTRY_NAMESPACE> \

O digest só é possível com a versão 4 do Helm.

>helm update <RELEASE_NAME> \
  oci://registry.suse.com/private-registry/private-registry-helm@sha256:<DIAGEST_OF_CHART_TO_INSTALL> \
  --namespace <PRIVATE_REGISTRY_NAMESPACE> \

5 Alta Disponibilidade configuração

Você pode usar Helm para implantar o altamente disponível (HA) Registro Privado em um cluster Kubernetes. O configuração de HA garante que os usuários não experimentem interrupções de serviço se um dos nós em que Registro Privado está sendo executado se tornar indisponível.

5.1 Arquitetura do configuração de HA

A maioria dos componentes do Registro Privado agora é sem estado. Portanto, podemos escalá-los aumentando as réplicas de pod, garantindo que eles sejam executados em vários nós de trabalho. Kubernetes Os serviços garantem conectividade entre os pods.

Para armazenamento, os usuários devem fornecer um HA PostgreSQL e um cluster Valkey ou Redis para os dados da aplicação, juntamente com PVCs ou armazenamento de objetos para armazenar imagens e gráficos.

image::private-registry-ha.png[Registro Privado configuração de HA, width=100%]. Registro Privado configuração de HA Kubernetes cluster com Ingress em configuração de HA usando HA PostgreSQL e HA Valkey.

5.2 Pré-requisitos

  • Um Kubernetes cluster com versão 1.20 ou superior

  • Helm com versão 3.2.0 ou superior

  • Controlador HA Ingress (Registro Privado não gerencia o endpoint externo)

  • HA PostgreSQL 9.6+ (Registro Privado não gerencia a implantação do banco de dados HA)

  • HA Valkey ou Redis (Registro Privado não gerencia a implantação do HA Valkey ou Redis)

  • Reivindicação de Volume Persistente (PVC) que pode ser compartilhada entre os nós ou armazenamento de objetos externo

  • Uma assinatura ativa para SUSE Private Registry

5.3 Implantando Registro Privado com HA

  1. Baixe o gráfico Registro Privado Helm.

      $ helm pull oci://registry.suse.com/private-registry/private-registry-helm --untar
  2. Update the deployment parameters to match your requirements. Refer to Appendix B, Exemplo de um Registro Privado gráfico de configuração HA Helm for an example Helm chart for Registro Privado HA setup. Refer to Appendix A, Substituindo o gráfico SUSE Private Registry Helm for a complete list of values to specify or override.

  3. Install the Registro Privado Helm chart. Replace <RELEASE_NAME> with your custom release name for the Helm chart deployment.

      $ helm install <RELEASE_NAME> private-registry-helm/

6 Configure Rancher como um Provedor de Identidade OIDC

Este guia explica como configurar Rancher para atuar como um Provedor de Identidade OIDC, permitindo que os usuários se autentiquem em aplicativos externos como SUSE Private Registry usando suas credenciais Rancher.

6.1 Etapa 1: Ative a flag de recurso oidc-provider

  1. Efetue login na interface do Rancher como administrador.

  2. Clique no menu de três linhas (☰) no canto superior esquerdo e vá para Configurações Globais › Flags de Recursos.

  3. Encontre a flag oidc-provider, clique no ícone Ações Adicionais (⋮) e clique em Ativar.

Configure Rancher como um Provedor de Identidade OIDC

6.2 Etapa 2: Crie um recurso OIDCClient

Rancher usa um recurso OIDCClient personalizado para registrar aplicativos downstream.

  1. Crie um arquivo chamado rancher-oidc-client.yaml com o seguinte conteúdo:

    apiVersion: management.cattle.io/v3
    kind: OIDCClient
    metadata:
      name: spr-client
    spec:
      tokenExpirationSeconds: 600
      refreshTokenExpirationSeconds: 3600
      redirectURIs:
        # Replace this with the actual callback URL of your SUSE private registry instance
        - "https://<SUSE_PRIVATE_REGISTR_URL>/c/oidc/callback"
  2. Aplique o arquivo no cluster onde Rancher está em execução:

    >kubectl apply -f rancher-oidc-client.yaml

6.3 Etapa 3: Recupere o ID do Cliente e o Segredo

Uma vez que o recurso é criado, Rancher preenche automaticamente o clientID e provisiona um Segredo Kubernetes contendo o clientSecret.

  1. Obtenha o ID do Cliente gerado:

    >kubectl get oidcclient spr-client -o jsonpath="{.status.clientID}"
  2. Recupere o Segredo do Cliente. Lembre-se de substituir <YOUR_CLIENT_ID> pelo ID recuperado na etapa anterior:

    >kubectl get secret <YOUR_CLIENT_ID>
      -n cattle-oidc-client-secrets
      -o jsonpath="{.data.client-secret-1}" | base64 -d

6.4 Etapa 4: Configure SUSE Private Registry

Você pode configurar SUSE Private Registry para usar Rancher como seu provedor OIDC passando os valores via Helm. Use o bloco core.configureUserSettings na sua configuração values-oidc.yaml.

O seguinte é um bloco de exemplo usando seu Rancher ponto de extremidade e as credenciais recuperadas acima. Substitua os valores de <YOUR_CLIENT_ID> e <YOUR_CLIENT_SECRET>.

core:
  configureUserSettings: |
    {
      "auth_mode": "oidc_auth",
      "oidc_name": "Rancher",
      "oidc_endpoint": "<RANCHER_URL>/oidc",
      "oidc_client_id": "<YOUR_CLIENT_ID>",
      "oidc_client_secret": "<YOUR_CLIENT_SECRET>",
      "oidc_scope": "openid,profile,offline_access",
      "oidc_verify_cert": false,
      "oidc_auto_onboard": true,
      "oidc_user_claim": "preferred_username",
      "oidc_groups_claim": "groups",
      "oidc_admin_group": "spr-admins"
    }
Note
Note

Certifique-se de que oidc_verify_cert esteja definido como false se sua instância Rancher estiver usando certificados autoassinados. Ao especificar oidc_admin_group, qualquer usuário Rancher pertencente ao grupo spr-admins receberá automaticamente privilégios de administrador do sistema em SUSE Private Registry.

7 Perguntas frequentes

7.1 Visão geral do produto e diferenciais

Que tipo de assinatura os clientes precisam para SUSE Private Registry?

Está incluído no Rancher Suite e oferecido como um complemento para Rancher Prime.

O preço do complemento é o mesmo que outros complementos.

Quais são os diferenciais com Harbor (da Coleção de Aplicativos ou upstream)?

Use SUSE Private Registry se você precisar:

  • Suporte de Nível 3 (L3) para problemas de produto.

  • Um ciclo de lançamento previsível.

  • Imagens corrigidas para vulnerabilidades conhecidas. Imagens upstream Harbor de Docker Hub frequentemente contêm várias vulnerabilidades não corrigidas.

    Com o tempo, SUSE também adicionará integrações prontas para uso com Rancher e priorizará solicitações de funcionalidades dos clientes.

Os clientes precisam comprar o mesmo número de assinaturas de complemento SUSE Private Registry que assinaturas Rancher Prime?

Sim, assim como outros complementos, como SUSE Segurança. Uma vantagem adicional do modelo de assinatura SUSE Private Registry é que ele permite que os clientes realizem quantas implantações precisarem.

7.2 Relação com upstream Harbor

Como o ciclo de lançamento se alinha com upstream Harbor?

O ciclo de lançamento de SUSE Private Registry é independente do ciclo de lançamento de upstream Harbor.

Ao lançar novas versões de SUSE Private Registry, SUSE visa incluir a versão mais recente do projeto upstream Harbor que atende aos requisitos de garantia de qualidade e manutenção da SUSE.

Você publicará considerações sobre migração para clientes que executam Harbor de outras fontes?

Não neste momento.

7.3 Implantação e instalação

Você suporta a instalação do SUSE Private Registry via docker-compose?

Não. Você deve instalar e configurar o SUSE Private Registry usando seu gráfico Helm. Este gráfico também é usado para gerenciamento contínuo (operações do Dia 2) e pode ser integrado com fluxos de trabalho GitOps.

Você recomenda implantações no cluster local (Rancher Manager)?

Não. A SUSE recomenda implantar o SUSE Private Registry em um cluster downstream. Isso torna o registro acessível a outros clusters downstream que precisam consumir imagens.

Quais são as melhores práticas de implantação para um ambiente de alta disponibilidade (HA)?

Para HA, não implante o SUSE Private Registry no cluster de gerenciamento Rancher para evitar contenção de recursos.

Você pode implantar o SUSE Private Registry em um cluster dedicado ou em um ou mais de seus clusters de aplicativos.

Para obter instruções, consulte Chapter 5, Alta Disponibilidade configuração. Observe que você deve fornecer seus próprios componentes de HA para o banco de dados Postgres, servidor Valkey ou Redis, e controlador Ingress. Esses componentes não são implantados pelo gráfico SUSE Private Registry Helm e não são suportados pelo SUSE.

O gráfico SUSE Private Registry Helm será adicionado à Coleção de Aplicativos eventualmente?

Sim, a SUSE planeja publicar o gráfico lá no futuro.

Você fornece um operador Kubernetes?

O SUSE Private Registry não vem com um operador dedicado. Ele é instalado e gerenciado usando seu gráfico Helm, que pode ser integrado com GitOps. SUSE continua a avaliar a gestão baseada em operadores para lançamentos futuros.

7.4 Segurança, escaneamento e assinatura

Você integra alguma ferramenta de assinatura dentro de SUSE Private Registry?

SUSE Private Registry não assina imagens por si só, mas pode armazenar, distribuir e verificar assinaturas compatíveis com a Open Container Initiative (OCI).

Uma ferramenta amplamente utilizada é cosign, que pode assinar imagens e armazenar as assinaturas em SUSE Private Registry.

As assinaturas de cosign anexadas às imagens são visíveis e podem ser baixadas do portal SUSE Private Registry.

É possível assinar imagens com Notary ou Cosign para aprovação durante o processo de implantação?

SUSE Private Registry pode armazenar, distribuir e verificar assinaturas de cosign.

SUSE Private Registry não assina imagens por si só. Você deve assinar as imagens durante o processo de construção e, em seguida, fazer o upload da assinatura para o registro junto com a imagem.

Notary não está incluído ou suportado com SUSE Private Registry.

As imagens são escaneadas para Vulnerabilidades e Exposições Comuns (CVEs) apenas com Trivy, ou pode usar SUSE Security (NeuVector) também?

As imagens são escaneadas com Trivy, que vem pronto para uso. SUSE Security pode ser adicionado além de ou como substituto do Trivy.

É possível executar ClamAV ou varreduras de malware semelhantes?

Por padrão, SUSE Private Registry escaneia imagens usando Trivy. Você também pode configurar SUSE Security (NeuVector) como um scanner.

No cenário de cache de pull-through, os critérios de vulnerabilidade serão aplicados?

Sim, mas com uma limitação conhecida. Devido aos Harbor issues conhecidos, os critérios de vulnerabilidade não são aplicados na primeira extração de uma imagem porque a varredura ainda não foi concluída.

Para cobertura completa, combine SUSE Private Registry com SUSE Security controles de admissão.

As imagens de SUSE Private Registry estão endurecidas?

Sim. As imagens de contêiner para SUSE Private Registry estão endurecidas. Elas são baseadas em SUSE Linux Enterprise Base Container Images (SLE BCI) e construídas no mesmo Serviço de Construção da SUSE de nível empresarial usado para o SUSE Linux Enterprise. Isso garante uma cadeia de suprimento segura. As imagens também são assinadas, e a SUSE publica suas Atestações de Níveis de Cadeia de Suprimento para Artefatos de Software (SLSA).

As imagens de SUSE Private Registry estão assinadas? Como?

As imagens estão assinadas com cosign. Você pode verificá-las salvando a chave de assinatura no formato PEM publicada em KB 000021411.

Então execute, por exemplo:

cosign verify --key container-key.pem registry.suse.com/private-registry/harbor-portal:latest

7.5 Replicação e sincronização

Há um plano para um plug-in para sincronizar com SUSE Registro e SUSE Coleção de Aplicativos?

Sim, tal recurso está planejado.

O SUSE Private Registry oferece replicação em múltiplos sites?

Sim. O SUSE Private Registry suporta replicação de imagens em múltiplos sites, baseada em políticas (pull e push). Você pode sincronizar imagens em várias implantações de SUSE Private Registry enquanto mantém cada registro independente.

7.6 Recursos e integração com Rancher

Há um plano para integrar o Registro dentro do Rancher usando uma extensão?

Sim. O SUSE planeja uma integração mais profunda com o Rancher Prime e outras ofertas. As melhorias futuras em consideração incluem integração de single sign-on (SSO), configuração simplificada para scanners de SUSE Segurança e espelhamento da Coleção de Aplicativos, monitoramento com SUSE Observabilidade e uma extensão de UI Rancher.

O SUSE adicionará o Registro ao Catálogo de Treinamento?

Isso ainda não está planejado. Se você estiver interessado em material de treinamento, entre em contato com SUSE para discutir possibilidades com a equipe de Treinamento.

7.7 Suporte e documentação

Há uma política de suporte para SUSE Private Registry?

Sim. A política de suporte de SUSE Private Registry é a mesma de qualquer outro complemento Prime Rancher.

Se a documentação de SUSE Private Registry estiver faltando informações, posso me referir à documentação oficial de Harbor?

Sim. Como SUSE Private Registry é baseado em Harbor, a documentação oficial de Harbor é um recurso útil. Para recursos específicos da versão SUSE, consulte a documentação de SUSE Private Registry.

Os Release notes especificam qual versão do Harbor upstream corresponde à sua versão de SUSE Private Registry.

8 Solução de problemas

Esta seção fornece soluções para problemas que você pode encontrar ao implantar ou usar SUSE Private Registry.

Estou encontrando o erro 401 unauthorized ao tentar instalar SUSE Private Registry.

A versão completa da mensagem de erro é a seguinte:

Error: INSTALLATION FAILED:
GET "https://registry.suse.com/v2/private-registry/private-registry-helm/tags/list":
response status code 401: unauthorized:
authentication required:
[map[Action:pull Class: Name:private-registry/private-registry-helm Type:repository]]

Para instalar e usar SUSE Private Registry, você precisa do seguinte:

  • Uma assinatura qualificada que inclua este produto, como uma assinatura do Rancher Suite ou uma assinatura do SUSE Private Registry complemento. Se você não tiver uma assinatura qualificada, entre em contato com seu representante SUSE.

  • Faça login no SUSE Registro com Helm usando as credenciais de espelhamento SCC da organização SCC que possui a assinatura. Consulte Section 4.1, “Obtendo segredos de Kubernetes do SUSE Atendimento ao Cliente” para obter mais detalhes.

A Substituindo o gráfico SUSE Private Registry Helm

O gráfico SUSE Private Registry (Registro Privado) Helm é entregue com valores padrão. Você pode ajustar a instalação do gráfico Helm de uma das seguintes maneiras:

  • Anexe parâmetros específicos às flags --set na linha de comando helm install, por exemplo:

    $ helm install <RELEASE_NAME> \
    oci://registry.suse.com/private-registry/private-registry-helm \
    --namespace <PRIVATE_REGISTRY_NAMESPACE> \
    --set harborAdminPassword=<MY_PASSWORD> \
    --set externalURL=https://<PRIVATE_REGISTRY_FQDN> \
    --set expose.ingress.hosts.core=<PRIVATE_REGISTRY_FQDN>
  • Create a SUSE custom suse_registry_override.yaml file and pass it to the --f flag, for example:

      $ helm install <RELEASE_NAME> \
      oci://registry.suse.com/private-registry/private-registry-helm \
      --namespace <PRIVATE_REGISTRY_NAMESPACE>
      -f suse_registry_override.yaml

A1 Exemplos de arquivos de substituição SUSE Registro Helm

Example A1: Implantação mínima com Ingress
expose:
  type: ingress 1
  ingress:
    hosts:
      core: <PRIVATE_REGISTRY_FQDN> 2

externalURL: https://<PRIVATE_REGISTRY_FQDN> 3

harborAdminPassword: "<MY_PASSWORD>" 4

database:
  internal:
    password: "<MY_PASSWORD_POSTGRESQL>"

redis:
  internal:
   password: "<MY_PASSWORD_REDIS>"

1

Como SUSE Registro é exposto. Pode ser ingress, loadBalancer, nodePort ou clusterIPhis. O padrão é ingress.

2

Nome de host para a configuração de rede interna do Kubernetes.

3

URL onde o aplicativo SUSE Registro é executado. É usado para gerar links na interface do usuário, redirecionamentos e também para respostas da API.

4

A senha do administrador para o aplicativo.

Example A2: Implantação típica com loadBalancer
expose:
  type: loadBalancer 1
  tls:
    enabled: true
    certSource: secret 2
    secret:
      secretName: <SECRET_NAME>

    auto:
      commonName: <PRIVATE_REGISTRY_FQDN> 3

externalURL: https://<PRIVATE_REGISTRY_FQDN> 4

harborAdminPassword: "<MY_PASSWORD>" 5

database:
  internal:
    password: "<MY_PASSWORD_POSTGRESQL>"

redis:
  internal:
   password: "<MY_PASSWORD_REDIS>"

1

Como SUSE Registro é exposto. Pode ser ingress, loadBalancer, nodePort ou clusterIP. O padrão é ingress.

2

Pode ser auto, secret ou none. Dependendo da opção, pode ser necessário incluir valores adicionais.

3

Ao usar a criptografia TLS, este campo deve corresponder ao valor externalURL.

4

URL onde o aplicativo SUSE Registro é executado. É usado para gerar links na interface do usuário, redirecionamentos e também para respostas da API.

5

A senha do administrador para o aplicativo.

A2 Substituindo os parâmetros e valores do gráfico Helm

As tabelas a seguir listam todos os parâmetros com descrições que você pode usar para substituir os valores de instalação padrão.

Parâmetros globais
global.imageRegistry

Define uma substituição global para o registro de imagens do contêiner usado para todas as imagens.

global.imagePullSecrets

Define segredos globais de pull para acessar o registro de imagens do contêiner.

Parâmetros comuns
harborAdminPassword

Define a senha inicial para o administrador Harbor. Altere-a pelo portal após a implantação. O padrão é Harbor12345.

externalURL

Especifica a URL externa para o serviço harbor-core. O padrão é https://core.harbor.domain.

existingSecretAdminPasswordKey

Define o nome da chave no segredo que contém a senha do administrador Harbor. O padrão é HARBOR_ADMIN_PASSWORD.

imagePullSecrets

Define os nomes imagePullSecrets para todas as implantações.

updateStrategy.type

Define a estratégia de atualização para implantações com volumes persistentes. Aceita RollingUpdate ou Recreate. Use Recreate quando RWM para volumes não for suportado. O padrão é RollingUpdate.

logLevel

Define o nível de log para os serviços Harbor. Aceita fatal, error, warn, info, debug ou trace. O padrão é debug.

enableMigratehelmHook

Executa a tarefa de migração do banco de dados via o gancho Helm. Quando true, separa a tarefa de migração de harbor-core. O padrão é false.

caSecretName

Especifica o nome do segredo que contém a chave ca.crt.

Parâmetros de proxy
proxy.httpProxy

Especifica a URL do servidor proxy HTTP. O padrão é "".

proxy.httpsProxy

Especifica a URL do servidor proxy HTTPS. O padrão é "".

proxy.noProxy

Define URLs que ignoram a configuração do proxy. O padrão é 127.0.0.1,localhost,.local,.internal.

proxy.components

Define componentes que utilizam a configuração do proxy. O padrão é ["core","jobservice","trivy"].

Parâmetros de exposição
expose.type

Especifica o tipo de exposição do serviço: ingress, clusterIP, nodePort ou loadBalancer. O padrão é ingress.

expose.tls.enabled

Habilita TLS. O padrão é true.

expose.tls.certSource

Define a fonte do certificado TLS como auto, secret ou none. O padrão é auto.

expose.tls.auto.commonName

Define o nome comum do certificado quando o tipo não é ingress.

expose.tls.secret.secretName

Especifica o nome do segredo que contém tls.crt (certificado) e tls.key (chave privada).

expose.ingress.hosts.core

Define o host do serviço kernel Harbor na regra Ingress. O padrão é core.harbor.domain.

expose.ingress.controller

Define o tipo de controlador Ingress. Suporta default, gce, alb, f5-bigip e ncp. O padrão é default.

expose.ingress.kubeVersionOverride

Substitui a versão Kubernetes para a template Ingress.

expose.ingress.annotations

Define as anotações Ingress.

expose.ingress.labels

Define os rótulos específicos de Ingress. O padrão é {}.

expose.clusterIP.name

Define o nome do serviço ClusterIP. O padrão é harbor.

expose.clusterIP.annotations

Define as anotações do serviço ClusterIP. O padrão é {}.

expose.clusterIP.ports.httpPort

Define a porta do serviço HTTP. O padrão é 80.

expose.clusterIP.ports.httpsPort

Define a porta do serviço HTTPS. O padrão é 443.

expose.clusterIP.labels

Define os rótulos específicos do ClusterIP. O padrão é {}.

expose.nodePort.name

Define o nome do serviço NodePort. O padrão é harbor.

expose.nodePort.ports.http.port

Define a porta do serviço HTTP. O padrão é 80.

expose.nodePort.ports.http.nodePort

Define a porta do nó HTTP. O padrão é 30002.

expose.nodePort.ports.https.port

Define a porta do serviço HTTPS. O padrão é 443.

expose.nodePort.ports.https.nodePort

Define a porta do nó HTTPS. O padrão é 30003.

expose.nodePort.annotations

Define as anotações do NodePort.

expose.nodePort.labels

Define os rótulos específicos do NodePort. O padrão é {}.

expose.loadBalancer.name

Define o nome do serviço. O padrão é harbor.

expose.loadBalancer.IP

Define o IP do loadBalancer quando a atribuição de IP é suportada. O padrão é "".

expose.loadBalancer.ports.httpPort

Define a porta do serviço HTTP. O padrão é 80.

expose.loadBalancer.ports.httpsPort

Define a porta do serviço HTTPS. O padrão é 30002.

expose.loadBalancer.annotations

Define as anotações do serviço loadBalancer. O padrão é {}.

expose.loadBalancer.labels

Define os rótulos específicos do loadBalancer. O padrão é {}.

expose.loadBalancer.sourceRanges

Especifica intervalos de endereços IP para loadBalancerSourceRanges. O padrão é [].

Parâmetros de persistência
persistence.enabled

Habilita ou desabilita a persistência de dados. O padrão é true.

persistence.resourcePolicy

keep impede a remoção de PVCs durante uma operação de exclusão Helm. Valor vazio exclui PVCs após a exclusão do gráfico. O padrão é keep.

persistence.persistentVolumeClaim.registry.existingClaim

O PVC existente que deve ser criado manualmente antes da vinculação. Requer uma especificação de subPath se o PVC for compartilhado com outros componentes.

persistence.persistentVolumeClaim.registry.storageClass

O storageClass que provisiona o volume.

persistence.persistentVolumeClaim.registry.subPath

O subpath no volume.

persistence.persistentVolumeClaim.registry.accessMode

O modo de acesso do volume. O padrão é ReadWriteOnce.

persistence.persistentVolumeClaim.registry.size

O tamanho do volume. O padrão é 5Gi.

persistence.persistentVolumeClaim.registry.annotations

As anotações do volume.

persistence.persistentVolumeClaim.jobservice.jobLog.existingClaim

O PVC existente que deve ser criado manualmente antes da vinculação. Requer uma especificação de subPath se o PVC for compartilhado com outros componentes.

persistence.persistentVolumeClaim.jobservice.jobLog.storageClass

O storageClass que provisiona o volume.

persistence.persistentVolumeClaim.jobservice.jobLog.subPath

O subpath no volume.

persistence.persistentVolumeClaim.jobservice.jobLog.accessMode

O modo de acesso do volume. O padrão é ReadWriteOnce.

persistence.persistentVolumeClaim.jobservice.jobLog.size

O tamanho do volume. O padrão é 1Gi.

persistence.persistentVolumeClaim.jobservice.jobLog.annotations

As anotações do volume.

persistence.persistentVolumeClaim.database.existingClaim

O PVC existente que deve ser criado manualmente antes da vinculação. Requer uma especificação de subPath se o PVC for compartilhado com outros componentes.

persistence.persistentVolumeClaim.database.storageClass

O storageClass que provisiona o volume.

persistence.persistentVolumeClaim.database.subPath

O subpath no volume. Ignorado quando um banco de dados externo é utilizado.

persistence.persistentVolumeClaim.database.accessMode

O modo de acesso do volume. Ignorado quando um banco de dados externo é utilizado. O padrão é ReadWriteOnce.

persistence.persistentVolumeClaim.database.size

O tamanho do volume. Ignorado quando um banco de dados externo é utilizado. O padrão é 1Gi.

persistence.persistentVolumeClaim.database.annotations

As anotações do volume.

persistence.persistentVolumeClaim.redis.existingClaim

O PVC existente que deve ser criado manualmente antes da vinculação. Requer uma especificação de subPath se o PVC for compartilhado com outros componentes.

persistence.persistentVolumeClaim.redis.storageClass

O storageClass que provisiona o volume. Usa a StorageClass padrão se não for especificada.

persistence.persistentVolumeClaim.redis.subPath

O subpath no volume. Ignorado quando um Valkey externo é utilizado.

persistence.persistentVolumeClaim.redis.accessMode

O modo de acesso do volume. Ignorado quando um Valkey externo é utilizado. O padrão é ReadWriteOnce.

persistence.persistentVolumeClaim.redis.size

O tamanho do volume. Ignorado quando um Valkey externo é utilizado. O padrão é 1Gi.

persistence.persistentVolumeClaim.redis.annotations

As anotações do volume.

persistence.persistentVolumeClaim.trivy.existingClaim

O PVC existente que deve ser criado manualmente antes da vinculação. Requer uma especificação de subPath se o PVC for compartilhado com outros componentes.

persistence.persistentVolumeClaim.trivy.storageClass

O storageClass que provisiona o volume. Usa a StorageClass padrão se não for especificada.

persistence.persistentVolumeClaim.trivy.subPath

O subpath no volume.

persistence.persistentVolumeClaim.trivy.accessMode

O modo de acesso do volume. O padrão é ReadWriteOnce.

persistence.persistentVolumeClaim.trivy.size

O tamanho do volume. O padrão é 1Gi.

persistence.persistentVolumeClaim.trivy.annotations

As anotações do volume.

persistence.imageChartStorage.disableredirect

Controla a gestão de redirecionamentos de back ends de conteúdo. Defina como verdadeiro para desabilitar redirecionamentos para back ends não suportados. O padrão é false.

persistence.imageChartStorage.caBundleSecretName

O nome do segredo contendo o pacote CA para certificados de serviço de armazenamento autoassinado.

persistence.imageChartStorage.type

O tipo de armazenamento para imagens e gráficos: filesystem, azure, gcs, s3, swift ou oss. O padrão é filesystem.

persistence.imageChartStorage.gcs.existingSecret

O nome do segredo existente contendo a chave JSON da conta de serviço GCS. A chave deve ser gcs-key.json. O padrão é "".

persistence.imageChartStorage.gcs.useWorkloadIdentity

Habilita o uso de identidade de carga de trabalho em um cluster GKE. O padrão é false.

Parâmetros nginx
nginx.image.repository

O repositório de imagens para nginx. O padrão é private-registry/harbor-nginx.

nginx.image.tag

A tag da imagem para nginx.

nginx.replicas

O número de réplicas a serem executadas. O padrão é 1.

nginx.revisionHistoryLimit

O número máximo de revisões antigas de ReplicaSet a serem mantidas. O padrão é 10.

nginx.resources

Os recursos de computação alocados para o contêiner. O padrão é undefined.

nginx.automountServiceAccountToken

Controla a montagem automática do token da conta de serviço. O padrão é false.

nginx.nodeSelector

Os rótulos do nó usados para a atribuição de pods. O padrão é {}.

nginx.tolerations

As tolerâncias de atribuição de pods. O padrão é [].

nginx.affinity

As regras de afinidade de nó ou pod. O padrão é {}.

nginx.topologySpreadConstraints

As regras para espalhar pods por domínios de falha, como regiões ou zonas de disponibilidade. O padrão é [].

nginx.podAnnotations

As anotações adicionadas ao nginx pod. O padrão é {}.

Parâmetros do portal
portal.image.repository

Localização do repositório para a imagem do portal. O padrão é private-registry/harbor-portal.

portal.image.tag

Tag para a imagem do portal. O padrão é 3.11.

portal.replicas

Número de réplicas a serem criadas. O padrão é 1.

portal.revisionHistoryLimit

Número máximo de revisões antigas de ReplicaSet a serem mantidas. O padrão é 10.

portal.resources

Recursos alocados para o contêiner. O padrão é undefined.

portal.automountServiceAccountToken

Controla a montagem automática do token da conta de serviço. O padrão é false.

portal.nodeSelector

Rótulos de nó usados para atribuição de pod. O padrão é {}.

portal.tolerations

Tolerâncias usadas para atribuição de pod. O padrão é [].

portal.affinity

Configurações de afinidade de nó e pod. O padrão é {}.

portal.topologySpreadConstraints

Define a distribuição de pods entre domínios de falha, como regiões ou zonas de disponibilidade. O padrão é [].

portal.podAnnotations

Anotações adicionadas ao pod do portal. O padrão é {}.

portal.serviceAnnotations

Anotações adicionadas ao serviço do portal. O padrão é {}.

portal.priorityClassName

Nome da classe de prioridade para execução do pod.

portal.initContainers

Contêineres init a serem executados antes que o contêiner do controlador inicie. O padrão é [].

Parâmetros principais
core.image.repository

O repositório para a Harbor imagem do kernel. O padrão é private-registry/harbor-core.

core.image.tag

A tag para a Harbor imagem do kernel. O padrão é 2.11.

core.replicas

O número de réplicas. O padrão é 1.

core.revisionHistoryLimit

O limite de histórico de revisões. O padrão é 10.

core.startupProbe.initialDelaySeconds

O atraso inicial em segundos para a verificação de inicialização. O padrão é 10.

core.resources

Os recursos a serem alocados para o contêiner. O padrão é undefined.

core.automountServiceAccountToken

Monta o token da conta de serviço. O padrão é false.

core.nodeSelector

Os rótulos de nó para atribuição de pod. O padrão é {}.

core.tolerations

As tolerâncias para atribuição de pod. O padrão é [].

core.affinity

As afinidades de nó ou pod. O padrão é {}.

core.topologySpreadConstraints

As restrições que definem como os pods são distribuídos entre domínios de falha, como regiões ou zonas de disponibilidade. O padrão é [].

core.podAnnotations

As anotações a serem adicionadas ao pod kernel. O padrão é {}.

core.serviceAnnotations

As anotações a serem adicionadas ao serviço kernel. O padrão é {}.

core.configureUserSettings

Uma string JSON na variável de ambiente CONFIG_OVERWRITE_JSON para configurar as configurações do usuário.

core.quotaUpdateProvider

O provedor para atualizar o uso da cota do projeto, as opções são redis ou db. O padrão é db.

core.secret

Usado quando o servidor kernel se comunica com outros componentes.

core.secretName

O nome de um Kubernetes segredo para usar seu próprio certificado TLS e chave privada para a criptografia ou descriptografia de token.

core.tokenKey

A chave privada RSA formatada em PEM usada para assinar tokens de serviço.

core.tokenCert

O certificado formatado em PEM assinado por core.tokenKey usado para validar tokens de serviço.

core.xsrfKey

A chave XSRF, gerada automaticamente se não for especificada.

core.priorityClassName

A classe de prioridade para executar o pod.

core.artifactPullAsyncFlushDuration

A duração do tempo para atualizar assíncronamente o tempo de pull de artefatos e a contagem de pull do repositório.

core.gdpr.deleteUser

Habilita a exclusão de usuários em conformidade com o GDPR. O padrão é false.

core.gdpr.auditLogsCompliant

Habilita a conformidade com o GDPR para logs de auditoria, alterando o nome de usuário para seu valor CRC32 se esse usuário foi excluído do sistema. O padrão é false.

core.initContainers

Os contêineres init a serem executados antes que o contêiner do controlador inicie. O padrão é [].

Parâmetros do serviço de trabalho.
jobservice.image.repository

O repositório para a imagem do serviço de trabalho. O padrão é private-registry/harbor-jobservice.

jobservice.image.tag

A tag para a imagem do serviço de trabalho. O padrão é 2.11.

jobservice.replicas

O número de réplicas. O padrão é 1.

jobservice.revisionHistoryLimit

O limite de histórico de revisões. O padrão é 10.

jobservice.maxJobWorkers

O número máximo de worker de trabalho. O padrão é 10.

jobservice.jobLoggers

Os registradores para trabalhos: file, database ou stdout. O padrão é [file].

jobservice.loggerSweeperDuration

A duração em dias para manter os logs de trabalho (ignorados se jobLoggers estiver definido como stdout). O padrão é 14.

jobservice.notification.webhook_job_max_retry

O número máximo de tentativas para o envio de notificações via webhook. O padrão é 3.

jobservice.notification.webhook_job_http_client_timeout

O tempo limite do cliente HTTP em segundos para o envio de notificações via webhook. O padrão é 3.

jobservice.reaper.max_update_hours

O tempo máximo em horas para aguardar a conclusão de uma tarefa. Se a tarefa não for concluída após as horas especificadas, ela é marcada como um erro, mas continua em execução. O padrão é 24.

jobservice.reaper.max_dangling_hours

O tempo máximo em horas para execução em estado de execução sem uma nova tarefa criada. O padrão é 168.

jobservice.resources

Os [recursos] a serem alocados para o contêiner. O padrão é undefined.

jobservice.automountServiceAccountToken

Monta o token da conta de serviço. O padrão é false.

jobservice.nodeSelector

Os rótulos de nó para atribuição de pod. O padrão é {}.

jobservice.tolerations

As tolerâncias para atribuição de pod. O padrão é [].

jobservice.affinity

As afinidades de nó ou pod. O padrão é {}.

jobservice.topologySpreadConstraints

As restrições que definem como os pods são distribuídos entre domínios de falha, como regiões ou zonas de disponibilidade. O padrão é [].

jobservice.podAnnotations

As anotações a serem adicionadas ao pod do serviço de trabalho. O padrão é {}.

jobservice.priorityClassName

A classe de prioridade para executar o pod.

jobservice.secret

O segredo usado quando o serviço de trabalho se comunica com outros componentes. Se uma chave secreta não for especificada, Helm a gera. Deve ser uma string de 16 caracteres.

jobservice.initContainers

Os contêineres init a serem executados antes que o contêiner do controlador inicie. O padrão é [].

Parâmetros do registro
registry.registry.image.repository

A localização do repositório para a imagem do registro. O padrão é private-registry/harbor-registry.

registry.registry.image.tag

A tag para a imagem do registro. O padrão é 2.11.

registry.registry.resources

Os [recursos] a serem alocados para o contêiner. O padrão é undefined.

registry.controller.image.repository

A localização do repositório para a imagem do controlador do registro. O padrão é private-registry/harbor-registryctl.

registry.controller.image.tag

A tag para a imagem do controlador do registro. O padrão é 2.11.

registry.controller.resources

Os [recursos] a serem alocados para o contêiner. O padrão é undefined.

registry.replicas

O número de instâncias replicadas. O padrão é 1.

registry.revisionHistoryLimit

O número máximo de revisões a serem mantidas no histórico. O padrão é 10.

registry.nodeSelector

Os rótulos de nó para atribuição de pod. O padrão é {}.

registry.automountServiceAccountToken

Controla se deve montar o token da conta de serviço. O padrão é false.

registry.tolerations

As tolerâncias para atribuição de pod. O padrão é [].

registry.affinity

As afinidades de nó ou pod. O padrão é {}.

registry.topologySpreadConstraints

As restrições que definem a distribuição de pods entre domínios de falha, como regiões ou zonas de disponibilidade. O padrão é [].

registry.middleware

Suporte a middleware para um CDN entre o armazenamento de back end e Docker destinatário de pull.

registry.podAnnotations

As anotações a serem adicionadas ao pod do registro. O padrão é {}.

registry.priorityClassName

A classe de prioridade para a execução do pod.

registry.secret

O segredo que protege o estado de upload entre o cliente e o armazenamento do registro back end.

registry.credentials.username

O nome de usuário para acesso ao registro interno do kernel Harbor. O padrão é harbor_registry_user.

registry.credentials.password

A senha para acesso ao registro interno do kernel Harbor. O padrão é harbor_registry_password.

registry.credentials.existingSecret

Um segredo existente contendo a senha para acesso à instância do registro no modo de autenticação htpasswd. O padrão é "".

registry.credentials.htpasswdString

O login e a senha no formato de string htpasswd. Exclui registry.credentials.username e registry.credentials.password. O padrão é undefined.

registry.relativeurls

Retorna URLs relativas nos cabeçalhos de Localização quando verdadeiro. Necessário se Harbor estiver atrás de um proxy reverso. O padrão é false.

registry.upload_purging.enabled

Habilita a purgação de diretórios de upload. O padrão é true.

registry.upload_purging.age

O período de tempo após o qual os arquivos nos diretórios de upload são removidos, o padrão é uma semana. O padrão é 168h.

registry.upload_purging.interval

O intervalo de tempo entre operações de purgação. O padrão é 24h.

registry.upload_purging.dryrun

Habilita o modo de simulação para purgação de uploads. O padrão é false.

registry.initContainers

Os contêineres init que são executados antes do início do contêiner do controlador. O padrão é [].

Parâmetros Trivy
trivy.enabled

Habilita ou desabilita o Trivy scanner. O padrão é true.

trivy.image.repository

O repositório para a Trivy imagem do adaptador. O padrão é private-registry/harbor-trivy-adapter.

trivy.image.tag

A tag para a Trivy imagem do adaptador. O padrão é 2.11.

trivy.resources

Os recursos a serem alocados para o Trivy contêiner do adaptador. O padrão é undefined.

trivy.automountServiceAccountToken

Se deve montar o token da conta de serviço. O padrão é false.

trivy.replicas

O número de réplicas do Pod. O padrão é 1.

trivy.debugMode

Habilita o modo remover Trivy para solução de problemas. O padrão é false.

trivy.vulnType

Lista de tipos de vulnerabilidades separados por vírgula (os e library). O padrão é os,library.

trivy.severity

Lista de severidades de vulnerabilidades a serem verificadas, separadas por vírgula. O padrão é UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL.

trivy.ignoreUnfixed

Exibe apenas vulnerabilidades corrigidas. O padrão é false.

trivy.insecure

Ignora a verificação do certificado do registro. O padrão é false.

trivy.skipUpdate

Desabilita downloads de banco de dados Trivy do GitHub. O padrão é false.

trivy.skipJavaDBUpdate

Requer download manual do arquivo trivy-java.db quando habilitado. O padrão é false.

trivy.offlineScan

Impede que Trivy envie solicitações de API para identificar dependências. O padrão é false.

trivy.securityCheck

Lista de problemas de segurança a serem detectados, separados por vírgula. O padrão é vuln.

trivy.timeout

O tempo de espera para a conclusão da varredura. O padrão é 5m0s.

trivy.gitHubToken

O token de acesso do GitHub necessário para downloads de banco de dados. O padrão é undefined.

trivy.priorityClassName

A classe de prioridade para executar o pod. O padrão é undefined.

trivy.topologySpreadConstraints

Define restrições de distribuição do pod entre domínios de falha. O padrão é undefined.

trivy.initContainers

Lista de contêineres init a serem executados antes do contêiner principal iniciar. O padrão é [].

Parâmetros do banco de dados
database.type

O tipo de banco de dados. Defina como external ao usar um banco de dados externo. O padrão é internal.

database.internal.image.repository

O repositório para a imagem do banco de dados. O padrão é private-registry/harbor-db.

database.internal.image.tag

A tag para a imagem do banco de dados. O padrão é 2.11.

database.internal.password

A senha para o banco de dados interno. O padrão é changeit.

database.internal.shmSizeLimit

O limite de tamanho da memória compartilhada para PostgreSQL (tipicamente 50% do limite de memória do contêiner). O padrão é 512Mi.

database.internal.resources

Os recursos alocados para o contêiner do banco de dados. O padrão é undefined.

database.internal.automountServiceAccountToken

Controla se o token da conta de serviço é montado. O padrão é false.

database.internal.initContainer.migrator.resources

Os recursos alocados para o contêiner de inicialização do migrador de banco de dados. O padrão é undefined.

database.internal.initContainer.permissions.resources

Os recursos alocados para o contêiner de inicialização das permissões do banco de dados. O padrão é undefined.

database.internal.nodeSelector

Os rótulos de nó para atribuição de pod. O padrão é {}.

database.internal.tolerations

As tolerâncias para atribuição de pod. O padrão é [].

database.internal.affinity

As configurações de afinidade do nó ou pod. O padrão é {}.

database.internal.priorityClassName

A classe de prioridade para executar o pod. O padrão é undefined.

database.internal.livenessProbe.timeoutSeconds

O tempo limite em segundos para a liveness probe (intervalo: 1-5s). O padrão é 1.

database.internal.readinessProbe.timeoutSeconds

O tempo limite em segundos para a verificação de prontidão (intervalo: 1-5s). O padrão é 1.

database.internal.extrInitContainers

Contêineres de inicialização adicionais que são executados antes do contêiner do banco de dados iniciar. O padrão é [].

database.external.host

O nome de host do banco de dados externo. O padrão é 192.168.0.1.

database.external.port

O número da porta do banco de dados externo. O padrão é 5432.

database.external.username

O nome de usuário para o banco de dados externo. O padrão é user.

database.external.password

A senha para o banco de dados externo. O padrão é password.

database.external.coreDatabase

O nome do banco de dados usado pelo serviço kernel. O padrão é registry.

database.external.existingSecret

O segredo existente contendo a senha do banco de dados. A chave deve ser password. O padrão é "".

database.external.sslmode

O método de conexão para o banco de dados externo. Opções: require, verify-full, verify-ca, disable. O padrão é disable.

database.maxIdleConns

O número máximo de conexões ociosas no pool (0 ou menos significa que nenhuma conexão ociosa é mantida). O padrão é 50.

database.maxOpenConns

O número máximo de conexões abertas ao banco de dados (0 ou menos significa ilimitado). O padrão é 100.

database.podAnnotations

As anotações a serem adicionadas ao pod do banco de dados. O padrão é {}.

Valkey / Redis parâmetros
redis.type

O tipo de implantação Redis. Defina como external para Redis externo. O padrão é internal.

redis.internal.image.repository

O repositório da imagem Redis. O padrão é private-registry/harbor-redis.

redis.internal.image.tag

A tag da imagem Redis. O padrão é 7.2.

redis.internal.resources

Os recursos alocados para o contêiner Redis. O padrão é undefined.

redis.internal.automountServiceAccountToken

Controla se o token da conta de serviço é montado. O padrão é false.

redis.internal.nodeSelector

Os rótulos de nó para atribuição de pod. O padrão é {}.

redis.internal.tolerations

As tolerâncias para atribuição de pod. O padrão é [].

redis.internal.affinity

As configurações de afinidade do nó ou pod. O padrão é {}.

redis.internal.priorityClassName

A classe de prioridade para executar o Redis pod. O padrão é undefined.

redis.internal.jobserviceDatabaseIndex

O índice do banco de dados para o jobservice. O padrão é 1.

redis.internal.registryDatabaseIndex

O índice do banco de dados para o registry. O padrão é 2.

redis.internal.trivyAdapterIndex

O índice do banco de dados para o Trivy adaptador. O padrão é 5.

redis.internal.harborDatabaseIndex

O índice do banco de dados para a Harbor lógica de negócios diversa. O padrão é 0.

redis.internal.cacheLayerDatabaseIndex

O índice do banco de dados para a camada de cache de Harbor. O padrão é 0.

redis.internal.initContainers

Os contêineres init que são executados antes do Redis contêiner iniciar. O padrão é [].

redis.external.addr

O endereço da Redis instância externa. O padrão é 192.168.0.2:6379.

redis.external.sentinelMasterSet

O nome do Redis conjunto mestre Sentinel (se aplicável). O padrão é undefined.

redis.external.coreDatabaseIndex

O índice do banco de dados para o kernel. O padrão é 0.

redis.external.jobserviceDatabaseIndex

O índice do banco de dados para o jobservice. O padrão é 1.

redis.external.registryDatabaseIndex

O índice do banco de dados para o registry. O padrão é 2.

redis.external.trivyAdapterIndex

O índice do banco de dados para o Trivy adaptador. O padrão é 5.

redis.external.harborDatabaseIndex

O índice do banco de dados para a Harbor lógica de negócios diversa. O padrão é 0.

redis.external.cacheLayerDatabaseIndex

O índice do banco de dados para a camada de cache de Harbor. O padrão é 0.

redis.external.username

O nome de usuário para Redis autenticação externa. O padrão é undefined.

redis.external.password

A senha para Redis autenticação externa. O padrão é undefined.

redis.external.existingSecret

O segredo existente contendo a Redis senha. A chave deve ser REDIS_PASSWORD. O padrão é "".

redis.podAnnotations

As anotações a serem adicionadas ao Redis pod. O padrão é {}.

Parâmetros do exportador
exporter.replicas

O número de réplicas a serem executadas. O padrão é 1.

exporter.revisionHistoryLimit

O limite do histórico de revisões. O padrão é 10.

exporter.podAnnotations

Anotações a serem adicionadas ao pod do exportador. O padrão é {}.

exporter.image.repository

O repositório para a imagem do exportador. O padrão é private-registry/harbor-exporter.

exporter.image.tag

A tag para a imagem do exportador. O padrão é 2.11.

exporter.nodeSelector

Rótulos de nó para atribuição de pod. O padrão é {}.

exporter.tolerations

Tolerâncias para atribuição de pod. O padrão é [].

exporter.affinity

Afinidades de nó ou pod. O padrão é {}.

exporter.topologySpreadConstraints

Restrições que definem como os Pods se espalham por domínios de falha, como regiões ou zonas de disponibilidade. O padrão é [].

exporter.automountServiceAccountToken

Controla se deve montar o serviceAccountToken. O padrão é false.

exporter.cacheDuration

A duração do cache para informações coletadas pelo exportador. O padrão é 30.

exporter.cacheCleanInterval

O intervalo de limpeza do cache para informações coletadas pelo exportador. O padrão é 14400.

exporter.priorityClassName

A classe de prioridade para executar o pod. O padrão é undefined.

Parâmetros de métricas.
metrics.enabled

Habilita Harbor métricas. O padrão é false.

metrics.core.path

O caminho da URL para métricas do kernel. O padrão é /metrics.

metrics.core.port

A porta para métricas do kernel. O padrão é 8001.

metrics.registry.path

O caminho da URL para métricas do registry. O padrão é /metrics.

metrics.registry.port

A porta para métricas do registry. O padrão é 8001.

metrics.exporter.path

O caminho da URL para métricas do exportador. O padrão é /metrics.

metrics.exporter.port

A porta para métricas do exportador. O padrão é 8001.

metrics.serviceMonitor.enabled

Habilita a criação de um Prometheus ServiceMonitor (requer Prometheus CRDs). O padrão é false.

metrics.serviceMonitor.additionalLabels

Rótulos adicionais a serem aplicados ao manifesto do ServiceMonitor. O padrão é "".

metrics.serviceMonitor.interval

O intervalo de coleta para métricas de Harbor. O padrão é "".

metrics.serviceMonitor.metricRelabelings

As regras de reetiquetagem para métricas antes da ingestão. O padrão é [].

metrics.serviceMonitor.relabelings

As regras de reetiquetagem para métricas antes da coleta. O padrão é [].

Parâmetros de rastreamento
trace.enabled

Habilita a funcionalidade de rastreamento. O padrão é false.

trace.provider

O provedor de rastreamento (jaeger ou otel). A versão do Jaeger deve ser 1.26 ou superior. O padrão é jaeger.

trace.sample_rate

A taxa de amostragem para dados de rastreamento. 1 amostra 100%, 0.5 amostra 50%. O padrão é 1.

trace.namespace

O namespace para diferenciar diferentes serviços de Harbor.

trace.attributes

Um dicionário de chave-valor para atributos definidos pelo usuário na inicialização do provedor de rastreamento.

trace.jaeger.endpoint

O endpoint para rastreamento do Jaeger. O padrão é http://hostname:14268/api/traces.

trace.jaeger.username

O nome de usuário para autenticação do Jaeger.

trace.jaeger.password

A senha para autenticação do Jaeger.

trace.jaeger.agent_host

O host do agente para o Jaeger.

trace.jaeger.agent_port

A porta do agente para o Jaeger. O padrão é 6831.

trace.otel.endpoint

O endpoint para rastreamento de OpenTelemetry. O padrão é hostname:4318.

trace.otel.url_path

O caminho da URL para OpenTelemetry. O padrão é /v1/traces.

trace.otel.compression

Habilita a compressão para OpenTelemetry. O padrão é false.

trace.otel.insecure

Estabelece uma conexão insegura para OpenTelemetry. O padrão é true.

trace.otel.timeout

O tempo limite em segundos para OpenTelemetry. O padrão é 10.

Parâmetros de cache
cache.enabled

Habilita a camada de cache. O padrão é false.

cache.expireHours

O tempo de expiração em horas para a camada de cache. O padrão é 24.

B Exemplo de um Registro Privado gráfico de configuração HA Helm

O arquivo de valores de exemplo a seguir ilustra os parâmetros necessários para a configuração mínima Registro Privado de HA.

expose:
  ingress:
    hosts:
      core: core.harbor.domain 1

externalURL: https://core.harbor.domain 2

portal:
  replicas: 2 3

core:
  replicas: 2 4

jobservice:
  replicas: 2 5

registry:
  replicas: 2 6

database:
  type: external
  external: 7
    host: "192.168.0.1"
    port: "5432"
    username: "user"
    password: "password"
    coreDatabase: "registry"
    existingSecret: "" 8
    sslmode: "disable" 9

redis:
  type: external
  external: 10
    addr: "192.168.0.2:6379" 11
    sentinelMasterSet: "" 12
    coreDatabaseIndex: "0" 13
    jobserviceDatabaseIndex: "1"
    registryDatabaseIndex: "2"
    trivyAdapterIndex: "5"
    harborDatabaseIndex: "6" 14
    cacheLayerDatabaseIndex: "7"15
    username: "" 16
    password: ""
    existingSecret: "" 17

persistence:
  enabled: true 18

1

Nome de host do serviço kernel na regra Ingress.

2

A URL externa para o serviço harbor-core.

3 4 5 6

Número de réplicas a serem criadas. Especifique dois ou mais.

7

Preencha os detalhes da conexão do banco de dados na seção external.

8

Se estiver usando um segredo existente, o valor deve ser password.

9

Aceita um dos seguintes valores:

disable

Não use SSL.

exigir

Sempre use SSL e pule a verificação.

verify-ca

Sempre use SSL. Verifique se o certificado apresentado pelo servidor foi assinado por uma CA confiável.

verify-full

Sempre use SSL. Verifique se o certificado apresentado pelo servidor foi assinado por uma CA confiável e se o nome de host do servidor corresponde ao que está no certificado.

10

Preencha as informações de conexão na seção external.

11

Suporta redis e redis+sentinel.
O endereço para redis é <redis_host>:<redis_port>.
O endereço para redis+sentinel é <sentinel1_host>:<sentinel1_port>,<sentinel2_host>:<sentinel2_port>…​

12

O nome do conjunto de Valkey instâncias a serem monitoradas. Deve ser configurado para suportar redis+sentinel.

13

Deve ser 0 pois a biblioteca que Harbor utiliza não suporta configurações.

14

Opcional. O padrão é 0, mas pode ser configurado para 6.

15

Opcional. O padrão é 0, mas pode ser configurado para 7.

16

Se estiver vazio, será autenticado contra o usuário padrão.

17

Se utilizado, a chave deve ser <REDIS_PASSWORD>.

18

Para armazenar todas as imagens, metadados e digitalizações, certifique-se de que as configurações relacionadas à persistência (Parâmetros de persistência) estejam devidamente configuradas.

C Licença GFDL (GNU Free Documentation License)

Copyright © 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, quinto andar, Boston, MA 02110-1301 EUA. Qualquer pessoa está autorizada a reproduzir e distribuir cópias literais deste documento de licença, mas não é permitido alterá-lo.

C1 0. PREÂMBULO

A finalidade desta Licença é tornar um manual, um livro ou outro documento funcional e útil "livre", no sentido de garantir a todos a liberdade efetiva para copiá-lo e redistribuí-lo, com ou sem modificações, para fins comerciais ou não. Em segundo lugar, esta Licença preserva ao autor e ao editor uma forma de obter crédito pelo seu trabalho, sem ser considerado responsável pelas modificações feitas por outros.

Esta Licença é um tipo de "copyleft", o que significa que trabalhos derivados do documento também devem ser livres no mesmo sentido. Ela complementa a Licença Pública Geral GNU, que é uma licença de copyleft projetada para software livre.

Criamos esta Licença para usá-la em manuais de software livre, pois o software livre precisa de documentação livre: um programa livre deve incluir manuais que ofereçam as mesmas liberdades que o software. Contudo, esta Licença não está limitada a manuais de software; pode ser usada para qualquer trabalho textual, independentemente do assunto ou se é publicado como um livro impresso. Recomendamos esta Licença principalmente para trabalhos cuja finalidade seja instrução ou referência.

C2 1. APLICABILIDADE E DEFINIÇÕES

Esta Licença se aplica a qualquer manual ou outro trabalho, em qualquer meio, que contenha um aviso colocado pelo detentor dos direitos autorais informando que pode ser distribuído sob os termos desta Licença. Esse aviso concede uma licença em nível mundial, isenta do pagamento de royalties e de duração ilimitada, para usar o trabalho sob as condições aqui estabelecidas. O "Documento", abaixo, refere-se a qualquer manual ou trabalho. Qualquer membro do público pode ser um licenciado e é tratado como "você". Você aceita a licença se copiar, modificar ou distribuir o trabalho de uma forma que exija permissão de acordo com a lei de direitos autorais.

Uma "Versão Modificada" do Documento significa qualquer trabalho que contenha o Documento ou parte dele, seja copiado fielmente, ou com modificações e/ou traduzido para outro idioma.

Uma "Seção Secundária" é um apêndice nomeado ou uma seção de introdução do Documento que trata exclusivamente da relação dos editores ou autores do Documento com o assunto geral do Documento (ou com questões relacionadas) e não contém nada que possa estar diretamente ligado a esse assunto geral. (Portanto, se o Documento for parcialmente um livro de matemática, uma Seção Secundária não poderá explicar nada de matemática.) A relação pode ser uma questão de conexão histórica com o assunto ou com temas relacionados, ou de posição legal, comercial, filosófica, ética ou política a respeito deles.

As "Seções Invariáveis" são determinadas Seções Secundárias cujos títulos são designados como sendo referentes a essas Seções Invariáveis, no aviso que indica que o Documento foi lançado sob esta Licença. Se uma seção não se encaixar na definição acima de Seção Secundária, não poderá ser designada como Invariável. O documento pode não conter Seções Invariáveis. Se o Documento não identificar nenhuma Seção Invariável, então não há nenhuma.

Os "Textos de Capa" são certos trechos curtos de texto que estão listados, como Textos de Capa Frontal ou Textos de Capa Traseira, no aviso que diz que o Documento é liberado sob esta Licença. Um Texto de Capa Frontal pode ter no máximo 5 palavras, e um Texto de Contracapa pode ter no máximo 25 palavras.

Uma cópia "Transparente" do Documento significa uma cópia que pode ser lida por máquina, representada em um formato cuja especificação está disponível ao público em geral, que é adequada para revisar o documento de forma direta com editores de texto genéricos ou (para imagens compostas de pixels) programas gráficos genéricos ou (para desenhos) algum editor de desenho amplamente disponível, e que é adequada para entrada em formatadores de texto ou para tradução automática para uma variedade de formatos adequados para entrada em formatadores de texto. Uma cópia feita em um formato de arquivo Transparente cuja marcação, ou ausência de marcação, foi organizada para impedir ou desencorajar modificações subsequentes pelos leitores não é Transparente. Um formato de imagem não é Transparente se usado para qualquer quantidade substancial de texto. Uma cópia que não é "Transparente" é chamada "Opaca".

Exemplos de formatos adequados para cópias Transparentes incluem ASCII simples sem marcação, formato de entrada Texinfo, formato de entrada LaTeX, SGML ou XML usando um DTD publicamente disponível, e HTML simples, PostScript ou PDF que estejam em conformidade com padrões e sejam projetados para modificação humana. Exemplos de formatos de imagem transparentes incluem PNG, XCF e JPG. Formatos Opacos incluem formatos proprietários que podem ser lidos e editados apenas por processadores de texto proprietários, SGML ou XML para os quais o DTD e/ou ferramentas de processamento não estão geralmente disponíveis, e o HTML, PostScript ou PDF gerados por máquina produzidos por alguns processadores de texto apenas para fins de saída.

A "Página de Título" significa, para um livro impresso, a própria página do título, além das páginas subsequentes necessárias para conter, de forma legível, o material que esta Licença requer que apareça na página do título. Para obras em formatos que não têm uma página de título assim, a "Página de Título" significa o texto próximo à ocorrência mais proeminente do título da obra, precedendo o início do corpo do texto.

Uma seção "Intitulada XYZ" significa uma subunidade nomeada do Documento cujo título é precisamente XYZ ou contém XYZ entre parênteses após o texto que traduz XYZ para outro idioma. (Aqui XYZ representa o nome de uma seção específica mencionada abaixo, como "Agradecimentos", "Dedicatória", "Apoio" ou "Histórico".) "Preservar o Título" de tal seção quando você modifica o Documento significa que ela continua sendo uma seção "Intitulada XYZ" de acordo com esta definição.

O Documento pode incluir Isenções de Responsabilidade quanto a Garantia próximas ao aviso que indica que esta Licença se aplica a este Documento. Essas Isenções de Responsabilidade quanto a Garantia são consideradas incluídas por referência nesta Licença, mas apenas no que diz respeito à isenção de garantias: qualquer outra implicação que essas Isenções de Responsabilidade possam ter é nula e não tem efeito sobre o significado desta Licença.

C3 2. CÓPIAS LITERAIS

Você pode copiar e distribuir o Documento em qualquer meio, comercialmente ou não, desde que esta Licença, as informações de copyright e o aviso de licença dizendo que esta Licença se aplica ao Documento sejam reproduzidos em todas as cópias, e que você não adicione outras condições, quaisquer que sejam, às condições desta Licença. Você não pode usar medidas técnicas para obstruir ou controlar a leitura ou a cópia futura das cópias que você fizer ou distribuir. Contudo, você pode aceitar remuneração em troca das cópias. Se você distribuir um número suficientemente grande de cópias, deverá também seguir as condições na seção 3.

Você também pode emprestar cópias, sob as mesmas condições mencionadas acima, e pode exibir cópias publicamente.

C4 3. COPIANDO EM QUANTIDADE

Se você publicar cópias impressas (ou cópias em mídias que normalmente têm capas impressas) do Documento, em número superior a 100, e o aviso de licença do Documento exigir Textos de Capa, deverá encadernar as cópias em capas que contenham, de forma clara e legível, todos esses Textos de Capa: Textos de Capa Frontal na capa frontal e Textos de Contracapa na contracapa. As duas capas também devem identificar, de forma clara e legível, você como o editor dessas cópias. A capa frontal deve apresentar o título completo com todas as palavras do título igualmente proeminentes e visíveis. Você pode adicionar outros materiais nas capas. Cópias com mudanças limitadas às capas, desde que preservem o título do Documento e satisfaçam essas condições, podem ser tratadas como cópias literais em outros aspectos.

Se os textos exigidos para qualquer uma das capas forem muito volumosos para serem incluídos de forma legível, você deve colocar os primeiros listados (quantos couberem razoavelmente) na própria capa e continuar o restante nas páginas adjacentes.

Se você publicar ou distribuir cópias Opacas do Documento em número superior a 100, deverá incluir uma cópia Transparente legível por máquina juntamente com cada cópia Opaca, ou informar em, ou juntamente com, cada cópia Opaca um local na rede de computadores do qual o público geral possa acessar e baixar, usando protocolos de rede públicos padrão, uma cópia Transparente completa do Documento, livre de material adicionado. Se você optar pela segunda opção, deverá tomar medidas razoavelmente prudentes, quando começar a distribuição de cópias Opacas em quantidade, para garantir que essa cópia Transparente permaneça acessível no local indicado até pelo menos um ano após a última vez que você distribuir uma cópia Opaca (diretamente ou através de seus agentes ou distribuidores) dessa edição ao público.

É solicitado, mas não exigido, que você contate os autores do Documento muito antes de redistribuir qualquer número grande de cópias, para dar-lhes a oportunidade de fornecer uma versão atualizada do Documento.

C5 4. MODIFICAÇÕES

Você pode copiar e distribuir uma Versão Modificada do Documento sob as condições das seções 2 e 3 acima, desde que forneça a Versão Modificada estritamente sob esta Licença, com a Versão Modificada no lugar do Documento, permitindo assim a distribuição e modificação da Versão Modificada a quem quer que possua uma cópia desta. Além disso, você deve realizar as seguintes ações na Versão Modificada:

  1. Use na Página de Título (e nas capas, se houver) um título distinto do título do Documento e dos de versões anteriores (os quais devem, se houver, ser listados na seção "Histórico" do Documento). Você pode usar o mesmo título de uma versão anterior se o editor original dessa versão der permissão.

  2. Liste na Página de Título, como autores, uma ou mais pessoas ou entidades responsáveis pela autoria das modificações na Versão Modificada, juntamente com pelo menos cinco dos autores principais do Documento (todos os seus autores principais, se houver menos de cinco), a menos que eles dispensem você dessa exigência.

  3. Mencione na Página de Título o nome do editor da Versão Modificada, como o editor.

  4. Preserve todas as informações de copyright do Documento.

  5. Adicione informações de copyright apropriadas para suas modificações ao lado das outras informações de copyright.

  6. Inclua, imediatamente após as informações de copyright, um aviso de licença concedendo ao público permissão para usar a Versão Modificada sob os termos desta Licença, na forma mostrada no Adendo abaixo.

  7. Preserve, nesse aviso de licença, as listas completas de Seções Invariantes e os Textos de Capa necessários fornecidos no aviso de licença do Documento.

  8. Inclua uma cópia inalterada desta Licença.

  9. Preserve a seção intitulada "Histórico", Preserve seu Título e adicione a ela um item mencionando pelo menos o título, o ano, os novos autores e o editor da Versão Modificada, conforme indicado na Página de Título. Se não houver uma seção intitulada "Histórico" no Documento, crie uma mencionando o título, o ano, os autores e o editor do Documento, conforme indicado na Página de Título; em seguida, adicione um item descrevendo a Versão Modificada, como mencionado na frase anterior.

  10. Preserve a localização de rede, se houver, indicada no Documento para acesso público a uma cópia transparente deste e, da mesma maneira, as localizações de rede indicadas no Documento para versões anteriores nas quais ele se baseia. Essas informações podem ser incluídas na seção “Histórico”. Você pode omitir uma localização de rede para um trabalho que foi publicado pelo menos quatro anos antes do Documento em si, ou se o editor original da versão à qual a localização se refere der permissão.

  11. Para qualquer seção intitulada "Agradecimentos" ou "Dedicatória", Preserve o Título da seção, e preserve dentro da seção toda a essência e o tom de cada um dos agradecimentos e/ou dedicatórias aos colaboradores nela mencionados.

  12. Preserve todas as Seções Invariantes do Documento, inalteradas em seu texto e títulos. Números de seção ou o equivalente não são considerados parte dos títulos das seções.

  13. Apague qualquer seção intitulada “Apoio”. Tal seção não pode ser incluída na Versão Modificada.

  14. Não modifique o título de qualquer seção existente para "Apoio" nem de forma a gerar conflito com o título de qualquer Seção Invariável.

  15. Preserve as Isenções de Responsabilidade quanto a Garantia.

Se a Versão Modificada incluir novas seções iniciais ou apêndices que sejam qualificados como Seções Secundárias e não contiver material copiado do Documento, você poderá, a seu critério, tornar invariantes algumas dessas seções ou todas elas. Para fazer isso, adicione seus títulos à lista de Seções Invariantes no aviso de licença da Versão Modificada. Esses títulos devem ser diferentes de outros títulos de seção.

Você pode adicionar uma seção intitulada "Apoio", desde que ela não contenha nada além do apoio recebido para sua Versão Modificada por várias partes--; por exemplo, declarações de avaliação por pares ou de que o texto foi aprovado por uma organização como a definição oficial de um padrão.

Você pode adicionar uma passagem de até cinco palavras como Texto de Folha de Rosto, e uma passagem de até 25 palavras como Texto de Contracapa, ao fim da lista de Textos de Capa na Versão Modificada. Somente uma passagem de Texto de Folha de Rosto e uma de Texto de Contracapa pode ser adicionada por (ou através de arranjos feitos por) uma entidade qualquer. Se o Documento já incluir um texto de capa para a mesma capa, anteriormente incluído por você ou por arranjo feito pela mesma entidade em cujo nome você está agindo, não será possível adicionar outro; mas você poderá substituir o antigo, com permissão explícita do editor anterior que o incluiu.

O(s) autor(es) e editor(es) do Documento, por esta Licença, não concedem permissão para que seu(s) nome(s) seja(m) usado(s) para publicidade ou para afirmar ou sugerir apoio de qualquer Versão Modificada.

C6 5. COMBINANDO DOCUMENTOS

Você pode combinar o Documento com outros documentos publicados sob esta Licença, sob os termos definidos na seção 4 acima para versões modificadas, desde que você inclua na combinação todas as Seções Invariantes de todos os documentos originais, sem modificações, e as liste como Seções Invariantes de seu trabalho combinado, no aviso de licença, e que você preserve todas as Isenções de Garantia.

O trabalho combinado somente precisa conter uma cópia desta Licença, e várias Seções Invariantes idênticas podem ser substituídas por uma única cópia. Se houver várias Seções Invariantes com o mesmo nome, mas com conteúdos diferentes, torne o título de cada uma dessas seções único, adicionando ao fim dele, entre parênteses, o nome do autor ou editor original da seção, se conhecido, ou então um número exclusivo. Faça o mesmo ajuste nos títulos de seção na lista de Seções Invariantes no aviso de licença do trabalho combinado.

Na combinação, você deve combinar quaisquer seções intituladas "Histórico" nos vários documentos originais, formando uma seção intitulada "Histórico"; do mesmo modo, combine quaisquer seções intituladas "Agradecimentos" e quaisquer seções intituladas "Dedicatória". Você deve eliminar todas as seções intituladas “Apoio”.

C7 6. COLEÇÕES DE DOCUMENTOS

Você pode fazer uma coleção consistindo do Documento e outros documentos publicados sob esta Licença, e substituir as cópias individuais desta Licença nos vários documentos por uma única cópia a ser incluída na coleção, desde que você siga as regras desta Licença para cópias literais de cada um dos documentos em todos os outros aspectos.

Você pode extrair um único documento dessa coleção e distribuí-lo individualmente sob esta Licença, desde que insira uma cópia desta Licença no documento extraído e siga esta Licença em todos os outros aspectos com relação à cópia literal desse documento.

C8 7. AGREGAÇÃO A TRABALHOS INDEPENDENTES

Uma compilação do Documento ou seus derivados com outros documentos ou trabalhos separados e independentes, dentro de ou junto a um volume de uma mídia de armazenamento ou distribuição, é chamada de "agregado" se os direitos autorais resultantes da compilação não forem usados para limitar os direitos legais dos usuários da compilação além do que os trabalhos individuais permitem. Quando o Documento é incluído em um agregado, esta Licença não se aplica a outros trabalhos no agregado que não sejam, por sua vez, derivados do Documento.

Se o requisito do Texto de Capa da seção 3 for aplicável a estas cópias do Documento e, ainda, se o Documento for menor do que a metade do agregado inteiro, os Textos de Capa do Documento poderão ser colocados em capas que encerrem o Documento dentro do agregado, ou no equivalente eletrônico das capas, se o Documento estiver em formato eletrônico. Caso contrário, eles deverão aparecer como capas impressas que envolvam o agregado inteiro.

C9 8. TRADUÇÕES

A tradução é considerada um tipo de modificação, portanto, você pode distribuir traduções do Documento em conformidade com os termos da seção 4. A substituição de Seções Invariantes por traduções requer permissão especial de seus detentores de direitos autorais, mas você pode incluir traduções de algumas ou de todas as Seções Invariantes, além das versões originais dessas Seções Invariantes. Você pode incluir uma tradução desta Licença e todos os avisos de licença no Documento, bem como quaisquer isenções de garantia, desde que também inclua a versão original em inglês desta Licença e as versões originais dos avisos e das isenções de garantia. Em caso de discordância entre a tradução e a versão original desta Licença ou entre um aviso de licença ou uma isenção de garantia, a versão original prevalecerá.

Se uma seção do Documento for intitulada "Agradecimentos", "Dedicatória" ou "Histórico", o requisito (seção 4) para Preservar seu Título (seção 1) normalmente exigirá a mudança do título em si.

C10 9. REVOGAÇÃO

Você não pode copiar, modificar, sublicenciar ou distribuir o Documento, exceto como expressamente previsto por esta Licença. Qualquer outra tentativa de copiar, modificar, sublicenciar ou distribuir o Documento é anulada, e implicará a revogação automática de seus direitos sob esta Licença. Porém, terceiros a quem você forneceu cópias ou direitos sob os termos desta Licença não terão suas licenças revogadas, desde que permaneçam em plena conformidade com ela.

C11 1. REVISÕES FUTURAS DESTA LICENÇA

A Free Software Foundation pode publicar ocasionalmente novas versões revisadas da Licença de Documentação Livre GNU. As novas versões serão semelhantes à versão atual, mas poderão diferir em detalhes para atender a novos problemas ou preocupações. Consulte a https://www.gnu.org/copyleft/.

A cada versão da Licença é atribuído um número de versão exclusivo. Se o Documento especificar que um número de versão específico desta Licença "ou de qualquer versão posterior" se aplica a ele, você terá a opção de seguir os termos e condições da versão especificada ou de qualquer versão posterior que tenha sido publicada (não como rascunho) pela Free Software Foundation. Se o Documento não especificar um número de versão desta Licença, você poderá escolher qualquer versão já publicada (não como rascunho) pela Free Software Foundation.

C12 ADENDO: Como usar esta Licença em seus documentos

  Copyright (c) YEAR YOUR NAME.
  Permission is granted to copy, distribute and/or modify this document
  under the terms of the GNU Free Documentation License, Version 1.2
  or any later version published by the Free Software Foundation;
  with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
  A copy of the license is included in the section entitled "GNU
  Free Documentation License".

Se você tiver Seções Invariantes, Textos de Capa Frontal e Textos de Contracapa, substitua a linha "com…​Textos." por isto:

  with the Invariant Sections being LIST THEIR TITLES, with the
  Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.

Se você tiver Seções Invariantes sem Textos de Capa, ou alguma outra combinação das três, una essas duas alternativas para se adequar à situação.

Se seu documento contiver exemplos não triviais de código de programação, recomendamos publicar esses exemplos paralelamente, sob a licença de software livre de sua escolha, como a Licença Pública Geral GNU, para permitir seu uso em software livre.