SUSE Private Registry

Erste Schritte mit SUSE Private Registry

Revision History: Erste Schritte mit SUSE Private Registry

Publication Date: 2026-05-04

Release notes
Urheberrecht
1 Einführung
2 Anforderungen
- 2.1 Voraussetzungen
- 2.2 Hardware- und Größenempfehlungen
  - 2.2.1 Persistent Storage-Baseline
3 Installation über die Rancher Benutzeroberfläche
- 3.1 Welche Anforderungen muss ich erfüllen?
- 3.2 Was sind die Schritte zur Installation von SUSE Private Registry über die Rancher Benutzeroberfläche?
4 Installation über die Kommandozeile
5 Hochverfügbarkeit setup
6 Konfigurieren Sie Rancher als OIDC-Identitätsanbieter
7 Häufig gestellte Fragen
8 Fehlerbehebung
A Überschreiben des SUSE Private Registry Helm Charts
- A1 Beispiele für SUSE Registry Helm Override-Dateien
- A2 Überschreiben der Helm Chart-Parameter und -Werte
B Beispiel eines Private Registry HA setup Helm Diagramms
C Freie GNU-Dokumentationslizenz (GNU Free Documentation License)

List of Figures

3.1 Hinzufügen eines SUSE Private Registry Repositories
3.2 Hinzufügen von SUSE Private Registry Geheimnissen
3.3 Installieren von SUSE Private Registry

List of Examples

A1 Minimale Bereitstellung mit Ingress
A2 Typische Bereitstellung mit loadBalancer

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:

Updates Harbor 2.14.3 to 2.15.1 (Release Notes v2.15.1).
Updates Trivy version 0.68.2 to 0.70.0 with adapter v0.36.0 general availability (GA) (Release Notes v0.70.0).

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:

Updates Harbor 2.14.2 to 2.14.4 (Release Notes v2.14.4).
Updates Trivy version 0.68.2 to 0.70.0 with adapter v0.36.0 (Release Notes v0.70.0).

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:

Update Harbor 2.14.1 to 2.14.2 (Release Notes v2.14.2)
Trivy version update 0.67.2 to 0.68.2 (Release Notes v0.68.2)

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:

Updated Harbor 2.13.2 to 2.14.1 (Release Notes v2.14.1)

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 Anwendungssammlung
Supports SUSE Sicherheit 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)

Urheberrecht #

Es wird die Genehmigung erteilt, dieses Dokument unter den Bedingungen der GNU Free Documentation License, Version 1.2 oder (optional) Version 1.3 zu vervielfältigen, zu verbreiten und/oder zu verändern; der unveränderbare Abschnitt ist der Copyright-Hinweis und die Lizenzbedingungen. Eine Kopie dieser Lizenz (Version 1.2) finden Sie im Abschnitt mit dem Titel 'GNU Free Documentation License'.

Für SUSE Marken siehe https://www.suse.com/company/legal/. Alle Marken von Drittanbietern sind Eigentum ihrer jeweiligen Inhaber. Markensymbole (®, ™ usw.) kennzeichnen Marken von SUSE und ihren Tochtergesellschaften. Sternchen (*) kennzeichnen Marken von Drittanbietern.

Alle Informationen in diesem Buch wurden mit größter Sorgfalt zusammengestellt. Auch hierdurch kann jedoch keine hundertprozentige Richtigkeit gewährleistet werden. Weder SUSE LLC, noch seine Tochtergesellschaften, noch die Autoren, noch die Übersetzer werden für mögliche Fehler oder deren Folgen haftbar gemacht.

1 Einführung #

1.1 Was ist SUSE Private Registry? #

SUSE Private Registry (Private Registry) ist eine lokale Container-Registry. Private Registry ist für SUSE Kunden konzipiert, die eine Container-Registry benötigen, die gut mit anderen SUSE Diensten und Produkten zusammenarbeitet.

1.2 Was sind die Vorteile von SUSE Private Registry? #

Private Registry basiert auf dem Harbor Projekt und umfasst alle seine Kernfunktionen sowie zusätzliche Vorteile. Beispiel:

Lokale Container-Registry. Private Registry ist eine lokal gehostete Container-Registry mit Zugriff auf Online-SUSE Registry-Dienste.
Sicherheit. Private Registry bietet Sicherheitsüberlegungen für containerisierte Umgebungen. Es umfasst Authentifizierung, Autorisierung und Schwachstellenscanning.
Implementierungsflexibilität. Sie können Private Registry in einer Kubernetes Umgebung wie SUSE Rancher Prime: RKE2 installieren. Sie können Private Registry auch mit einem Setup für hohe Verfügbarkeit bereitstellen.
Benutzermanagement. Private Registry bietet Authentifizierungs- und Autorisierungsmechanismen mit rollenbasierter Zugriffskontrolle (RBAC).
Benutzeroberfläche. Neben einer Befehlszeilenschnittstelle können Sie Private Registry über die Web-Benutzeroberfläche verwalten.

1.3 Wie funktioniert SUSE Private Registry? #

Private Registry wird als Open Container Initiative (OCI) Container bereitgestellt und soll auf einem Kubernetes Cluster bereitgestellt werden. Private Registry besteht aus den folgenden Containern:

harbor-core: die Hauptkomponente der Harbor Registry, verantwortlich für die Verwaltung von Kernfunktionen wie das Verwalten von Projekten, Repositories und Benutzerinteraktionen.
harbor-db: der Datenbankcontainer, der alle Metadaten zu Bildern, Benutzern und Konfigurationen für die Harbor Registry speichert.
harbor-jobservice: ein Dienst, der Hintergrundjobs verwaltet, wie z.B. Bildreplikation und geplante Aufgaben, um eine effiziente Verarbeitung von Operationen innerhalb der Registry sicherzustellen.
harbor-nginx: der Reverse-Proxy und Lastenausgleich, der eingehende Anfragen an die entsprechenden Harbor Dienste weiterleitet und einen einzigen Einstiegspunkt für Benutzer bietet.
harbor-portal: die webbasierte Benutzeroberfläche, die es Benutzern ermöglicht, mit der Harbor Registry zu interagieren, Bilder zu verwalten und Einstellungen über eine grafische Oberfläche zu konfigurieren.
harbor-registry: der Container, der als tatsächliches Backend für die Speicherung von Containerbildern dient und die Speicherung sowie den Abruf verwaltet.
harbor-registryctl: ein Kommandozeilenwerkzeug zur Verwaltung der Harbor Registry, das es Benutzern ermöglicht, administrative Aufgaben und Konfigurationen direkt über das Terminal durchzuführen.
harbor-trivy-adapter: ein Container, der den Trivy Schwachstellenscanner mit Harbor integriert und automatisierte Sicherheitsprüfungen von Containerbildern auf Schwachstellen ermöglicht.
harbor-exporter: der Container, der Harbor Metriken in einem Format exportiert, das von Prometheus für Überwachung und Einblick gesammelt werden kann.
harbor-valkey: ein In-Memory-Schlüssel-Wert-Speicher.

Nach der Implementierung können Sie sich über die Web-Benutzeroberfläche anmelden. Nach erfolgreicher Authentifizierung und Autorisierung können Sie mehrere Aspekte des Produkts konfigurieren, zum Beispiel:

Konfigurieren Sie global settings, wie das Festlegen der Registry auf den Nur-Lesen-Modus oder das Einschränken, wer Projekte erstellen kann.
Wählen Sie eine Authentifizierung Methode aus.
Fügen Sie Benutzer im Datenbank-Authentifizierungsmodus hinzu und weisen Sie anderen Benutzern die Administrator-Rolle zu.
Wenden Sie Ressourcen-Quoten auf Projekte an.
Richten Sie die Replikation von Containerbildern zwischen Private Registry Instanzen ein.

1.4 Weitere Informationen #

Verweisen Sie auf die folgenden Quellen, um weitere Details zu erhalten:

Die Harbor Projekt-Homepage befindet sich unter https://goharbor.io/.
Die Harbor Nutzung ist in https://goharbor.io/docs. detailliert.

2 Anforderungen #

Dieser Abschnitt beschreibt die minimalen Plattformvoraussetzungen und die empfohlenen Produktionsgrößen für SUSE Private Registry.

2.1 Voraussetzungen #

Eine Kubernetes Cluster-Version 1.20 oder höher
Helm Version 3.2.0 oder höher
Unterstützung für Persistent Volume (PV) Bereitsteller in Ihrer Infrastruktur
Ein aktives Abonnement für SUSE Private Registry

2.2 Hardware- und Größenempfehlungen #

Verwenden Sie diese Werte als Ausgangspunkt für die Produktion. Passen Sie basierend auf der Aufbewahrungsrichtlinie, Bildwechsel, Scan-Konkurrenz und Replikationstrafik an. ==== Cluster-Baseline

Bereich	Empfohlener Ausgangspunkt
Arbeits-Knoten	Mindestens 3 Arbeitsknoten
Knotentyp	Mindestens 4 vCPU und 16 GiB RAM pro Knoten
Bevorzugter Knotentyp	8 vCPU und 32 GiB RAM pro Knoten für höhere Scan- und Push-Konkurrenz

Diese Empfehlungen stimmen mit den Richtlinien von Rancher für RKE2 Kubernetes überein. Für Details siehe RKE2 Kubernetes Installationsanforderungen.

2.2.1 Persistent Storage-Baseline #

Komponente	Standard Chart-Größe	Empfohlene Ausgangsgröße
Registrierungsdaten	5 Gi	500 Gi bis 1 Ti
Trivy-Cache und DB	5 Gi	20 Gi bis 50 Gi
Jobservice-Protokolle	1 Gi	10 Gi
Internes PostgreSQL (falls verwendet)	1 Gi	Mindestens 20 Gi
Internes Valkey (falls verwendet)	1 Gi	Mindestens 20 Gi

Die Standardwerte des Charts sind installationsorientiert und sollten nicht als langfristige Produktionskapazität verwendet werden.

3 Installation über die Rancher Benutzeroberfläche #

Um SUSE Private Registry über die Rancher Benutzeroberfläche zu installieren, müssen Sie die folgenden Anforderungen erfüllen und die untenstehenden Schritte befolgen.

3.1 Welche Anforderungen muss ich erfüllen? #

Eine Umgebung, in der ein laufender, unterstützter Kubernetes Cluster vorhanden ist und in der Rancher bereitgestellt wurde. Siehe Rancher Installationsanforderungen für weitere Details.
SUSE Registry Anmeldeinformationen für ein Konto mit einem SUSE Private Registry Abonnement (ein Benutzername und ein Passwort/Token). Siehe Erhalten von Kubernetes Geheimnissen von SCC für weitere Details.

3.2 Was sind die Schritte zur Installation von SUSE Private Registry über die Rancher Benutzeroberfläche? #

SCHRITT 1: Teilen Sie Rancher mit, wo sich das SUSE Private Registry Repository befindet, um nach dem Installationschart zu suchen. #

Melden Sie sich bei Rancher an.
Klicken Sie auf das Hamburger-Menü (☰) in der oberen linken Ecke, wählen Sie Clusterverwaltung und klicken Sie auf den Namen Ihres Clusters, normalerweise local.
Wählen Sie im linken Menü Apps › Repositories.
Klicken Sie auf die Schaltfläche Erstellen oben rechts und füllen Sie das sich öffnende Formular aus:
1. Ziel: Wählen Sie OCI Repository.
2. Name: Geben Sie einen Namen für das Repository ein, z. B. SUSE Private Registry.
3. Beschreibung: Fügen Sie optional eine Beschreibung des Repositories hinzu.
4. OCI Repository Host-URL: Enter `oci://registry.suse.com/private-registry/private-registry-helm`.
5. Authentifizierung: Ändern Sie zu Create an HTTP Basic Auth Secret und geben Sie den Benutzernamen und das Passwort der Registry-Anmeldeinformationen ein.
Bestätigen Sie mit Erstellen.

Figure 3.1: Hinzufügen eines SUSE Private Registry Repositories #

SCHRITT 2: Erstellen Sie ein Geheimnis, um auf die Bilder in der `registry.suse.com` zuzugreifen. #

Klicken Sie auf das Hamburger-Menü (☰) in der oberen linken Ecke und wählen Sie Clusterverwaltung.
Wechseln Sie zu dem Cluster, zu dem Sie das Geheimnis hinzufügen möchten, und klicken Sie auf Erkunden.
Um zur Geheimnisverwaltung zu navigieren, wählen Sie Speicher › Geheimnisse und klicken Sie auf Erstellen in der oberen rechten Ecke.
Wählen Sie das HTTP Basic Auth Geheimnis und dann den private-registry Namespace.
Geben Sie suse-registry als Namen für das Geheimnis ein.
Füllen Sie die Felder username und password mit den SUSE Anmeldeinformationen aus, die in Section 3.1, “Welche Anforderungen muss ich erfüllen?” erhalten wurden.

Figure 3.2: Hinzufügen von SUSE Private Registry Geheimnissen #

SCHRITT 3: Installieren Sie das Helm Chart. #

Wählen Sie im Hauptmenü links Apps › Charts.
Geben Sie den Namen des zugewiesenen SUSE Private Registry Repository in das Suchfeld ein. Beispiel: SUSE Private Registry. Wenn es nicht in der Liste erscheint, klicken Sie Alle Repositories aktualisieren.
Klicken Sie auf das Chart und sehen Sie sich die README.md an.
Optional können Sie die Installationswerte anpassen. Entweder klicken Sie durch die Abschnitte auf der linken Seite des Edit Options-Panels, um alle konfigurierbaren Werte anzuzeigen, oder Sie bearbeiten die Werte direkt in der YAML-Datei des Charts.
Klicken Sie oben rechts auf Diese Version installieren.

Figure 3.3: Installieren von SUSE Private Registry #

4 Installation über die Kommandozeile #

Die folgenden Verfahren beschreiben, wie man SUSE Private Registry (Private Registry) auf einem Kubernetes Cluster bereitstellt.

4.1 Erhalten von Kubernetes Geheimnissen aus dem SUSE Kundenzentrum #

Um die Private Registry Images von SUSE Registry herunterzuladen und zu installieren, benötigen Sie ein Kubernetes Geheimnis mit SUSE Kundenzentrum (SCC) Spiegelungsanmeldeinformationen. Um die Anmeldeinformationen von SCC zu erhalten, befolgen Sie diese Schritte:

Besuchen Sie SUSE Kundenzentrum unter https://scc.suse.com und melden Sie sich an.
Wählen Sie die Organisation mit einem aktiven Private Registry Abonnement aus der linken Seitenleiste aus.
Wählen Sie Proxies im oberen Menü aus. Die Anmeldeinformationen werden in der oberen rechten Ecke angezeigt.
Um das Passwort zu sehen, klicken Sie auf das 'Auge'-Symbol.

Erstellen Sie eine password.txt Datei, die das erhaltene Passwort enthält.

>head -1 ./password.txt | helm registry login registry.suse.com \
  --username <PRIVATE_REGISTRY_USERNAME> --password-stdin

Erstellen Sie einen Namespace für SUSE Registry.

>kubectl create namespace <PRIVATE_REGISTRY_NAMESPACE>

Speichern Sie die von SCC abgerufenen Spiegelungsanmeldeinformationen als Kubernetes Geheimnisse, indem Sie den folgenden Befehl ausführen:

>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)

Optional: Um TLS-verschlüsselte Kommunikation zu verwenden, erstellen Sie ein TLS-Geheimnis aus Ihren privaten Schlüssel- und Zertifikatsdateien.
```
>kubectl create secret tls suse-registry-tls \
  --namespace <PRIVATE_REGISTRY_NAMESPACE> \
  --cert=<CERTIFICATE>.pem \
  --key=<PRIVATE_KEY>.pem
```

4.2 Installation und Ausführung von Private Registry mit Helm #

Das folgende Verfahren beschreibt, wie man Private Registry mit Helm installiert. Ersetzen Sie <RELEASE_NAME> durch Ihren benutzerdefinierten Release-Namen für die Implementierung des Helm Charts.

Melden Sie sich bei SUSE Registry mit den erhaltenen SCC Spiegelungsanmeldeinformationen an.

>head -1 ./password.txt | helm registry login registry.suse.com \
  --username <SUSE_REGISTRY_USERNAME> --password-stdin

Installieren Sie die neueste Version des Private Registry Helm Charts.

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

Wenn Sie das Private Registry Helm Chart installieren, wird die folgende Ausgabe angezeigt:

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)

Mit Helm Version 4 können Sie ein Digest verwenden, um das zu installierende Chart anzugeben:

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

Tip

Um das Passwort für den Administratorbenutzer zu erhalten, können Sie auch den folgenden Befehl ausführen:

>kubectl get secret \
  --namespace <PRIVATE_REGISTRY_NAMESPACE> \
  --harbor-core <RELEASE_NAME> \
  -o jsonpath="{.data.HARBOR_ADMIN_PASSWORD}" | base64 -d; echo

Es ist möglich, den kstatus-Watcher mit dem Flag '--wait=watcher' zu verwenden, um sicherzustellen, dass alle Objekte bereit sind, um die Installation abzuschließen. Die Verwendung des Watchers kann dazu führen, dass der Befehl länger dauert.

Um die Standardinstallation mit benutzerdefinierten Werten aus der suse_registry_override.yaml Datei zu überschreiben, verweisen Sie auf Appendix A, Überschreiben des SUSE Private Registry Helm Charts.

Der Befehl beginnt damit, mehrere verwandte Container bereitzustellen, und dies kann mehrere Minuten dauern. Er druckt auch eine Nachricht mit der URL zum Private Registry Webportal und Befehlen, um die Administratoranmeldeinformationen zu erhalten.

4.3 Upgrade von Private Registry #

Um das Release des Helm Charts auf eine bestimmte neuere Version zu upgraden, führen Sie den folgenden Befehl aus:

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

Das Digest ist nur mit Helm 4 möglich.

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

5 Hochverfügbarkeit setup #

Sie können Helm verwenden, um das hochverfügbare (HA) Private Registry auf einem Kubernetes Cluster bereitzustellen. Das HA-Setup stellt sicher, dass Benutzer keine Unterbrechungen des Dienstes erleben, wenn einer der Knoten, auf dem Private Registry läuft, nicht verfügbar wird.

5.1 Architektur des HA-Setup #

Die meisten der Private Registry Komponenten sind jetzt zustandslos. Daher können wir sie skalieren, indem wir die Pod-Replikate erhöhen, um sicherzustellen, dass sie auf mehreren Arbeitsknoten laufen. Kubernetes Dienste gewährleisten die Konnektivität zwischen Pods.

Für den Speicher sollten Benutzer ein HA PostgreSQL und Valkey oder Redis Cluster für die Anwendungsdaten bereitstellen, zusammen mit PVCs oder Objektspeicher zum Speichern von Bildern und Charts.

image::private-registry-ha.png[Private Registry HA-Setup, width=100%]. Private Registry HA-Setup Kubernetes Cluster mit Ingress in HA-Setup unter Verwendung von HA PostgreSQL und HA Valkey.

5.2 Voraussetzungen #

Ein Kubernetes Cluster Version 1.20 oder höher
Helm Version 3.2.0 oder höher
HA Ingress Controller (Private Registry verwaltet nicht den externen Endpunkt)
HA PostgreSQL 9.6+ (Private Registry verwaltet nicht die Implementierung der HA-Datenbank)
HA Valkey oder Redis (Private Registry verwaltet nicht die Implementierung von HA Valkey oder Redis)
Persistent Volume Claim (PVC), der über Knoten oder externen Objektspeicher geteilt werden kann
Ein aktives Abonnement für SUSE Private Registry

5.3 Bereitstellung von Private Registry mit HA #

Laden Sie das Private Registry Helm Chart herunter.

  $ helm pull oci://registry.suse.com/private-registry/private-registry-helm --untar

Update the deployment parameters to match your requirements. Refer to Appendix B, Beispiel eines Private Registry HA setup Helm Diagramms for an example Helm chart for Private Registry HA setup. Refer to Appendix A, Überschreiben des SUSE Private Registry Helm Charts for a complete list of values to specify or override.
Install the Private Registry Helm chart. Replace <RELEASE_NAME> with your custom release name for the Helm chart deployment.
```
  $ helm install <RELEASE_NAME> private-registry-helm/
```

6 Konfigurieren Sie Rancher als OIDC-Identitätsanbieter #

Dieser Leitfaden erklärt, wie Sie Rancher so konfigurieren, dass es als OIDC-Identitätsanbieter fungiert, damit Benutzer sich mit ihren SUSE Private Registry-Anmeldeinformationen in externe Anwendungen wie Rancher authentifizieren können.

6.1 Schritt 1: Aktivieren Sie das Feature-Flag oidc-provider #

Melden Sie sich als Administrator in der Rancher GUI an.
Klicken Sie auf das Hamburger-Menü (☰) oben links und gehen Sie zu Globale Einstellungen › Feature-Flags.
Suchen Sie das oidc-provider-Flag, klicken Sie auf das Weitere Aktionen-Symbol (⋮) und klicken Sie auf Aktivieren.

Konfigurieren Sie Rancher als OIDC-Identitätsanbieter

6.2 2. Schritt: Erstellen Sie eine OIDCClient-Ressource #

Rancher verwendet eine OIDCClient Custom Resource, um Downstream-Anwendungen zu registrieren.

Erstellen Sie eine Datei mit dem Dateinamen rancher-oidc-client.yaml mit folgendem Inhalt:

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"

Wenden Sie die Datei auf den Cluster an, in dem Rancher ausgeführt wird:
```
>kubectl apply -f rancher-oidc-client.yaml
```

6.3 Schritt 3: Rufen Sie die Client-ID und das Client-Geheimnis ab. #

Sobald die Ressource erstellt ist, füllt Rancher automatisch die clientID aus und stellt ein Kubernetes Client-Geheimnis bereit, das die clientSecret enthält.

Holen Sie sich die generierte Client-ID:

>kubectl get oidcclient spr-client -o jsonpath="{.status.clientID}"

Holen Sie sich das Client-Geheimnis. Denken Sie daran, <YOUR_CLIENT_ID> durch die im vorherigen Schritt abgerufene ID zu ersetzen:
```
>kubectl get secret <YOUR_CLIENT_ID>
  -n cattle-oidc-client-secrets
  -o jsonpath="{.data.client-secret-1}" | base64 -d
```

6.4 4. Schritt: Konfigurieren Sie SUSE Private Registry #

Sie können SUSE Private Registry so konfigurieren, dass es Rancher als OIDC-Identitätsanbieter verwendet, indem Sie die Werte über Helm übergeben. Verwenden Sie den core.configureUserSettings-Block in Ihrer values-oidc.yaml-Konfiguration.

Das folgende ist ein Beispielblock, der Ihren Rancher-Endpunkt und die oben abgerufenen Anmeldeinformationen verwendet. Ersetzen Sie die Werte von <YOUR_CLIENT_ID> und <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

Stellen Sie sicher, dass oidc_verify_cert auf false gesetzt ist, wenn Ihre Rancher-Instanz selbstsignierte Zertifikate verwendet. Durch die Angabe von oidc_admin_group erhält jeder Rancher-Benutzer, der zur spr-admins-Gruppe gehört, automatisch Systemadministratorrechte in SUSE Private Registry.

7 Häufig gestellte Fragen #

7.1 Produktübersicht und Differenzierungsmerkmale #

Welche Art von Abonnement benötigen Kunden für SUSE Private Registry?

Es ist in der Rancher Suite enthalten und wird als Add-on für Rancher Prime angeboten.

Die Preise für das Add-on sind die gleichen wie für andere Add-ons.

Was sind die Differenzierungsmerkmale von Harbor (aus der Anwendungssammlung oder von Upstream)?

Verwenden Sie SUSE Private Registry, wenn Sie benötigen:

Level 3 (L3) Support für Produktprobleme.
Einen vorhersehbaren Veröffentlichungszyklus.
Gepatchte Images für bekannte Schwachstellen. Upstream Harbor Images von Docker Hub enthalten oft zahlreiche nicht gepatchte Schwachstellen.
Im Laufe der Zeit wird SUSE auch sofort einsatzbereite Integrationen mit Rancher hinzufügen und die Funktionsanfragen von Kunden priorisieren.

Müssen Kunden die gleiche Anzahl an Add-on SUSE Private Registry Abonnements wie Rancher Prime Abonnements kaufen?

Ja, genau wie bei anderen Add-ons wie SUSE Security. Ein zusätzlicher Vorteil des SUSE Private Registry Abonnementmodells ist, dass es Kunden ermöglicht, so viele Implementierungen durchzuführen, wie sie benötigen.

7.2 Beziehung zu Upstream Harbor #

Wie stimmt der Veröffentlichungszyklus mit Upstream Harbor überein?

Der Veröffentlichungszyklus von SUSE Private Registry ist unabhängig vom Veröffentlichungszyklus von Upstream Harbor.

Bei der Veröffentlichung neuer Versionen von SUSE Private Registry strebt SUSE an, die neueste Version des Upstream Harbor Projekts einzuschließen, die den Qualitäts- und Wartungsanforderungen von SUSE entspricht.

Werden Sie Migrationsüberlegungen für Kunden veröffentlichen, die Harbor aus anderen Quellen betreiben?

Nicht zu diesem Zeitpunkt.

7.3 Implementierung und Installation #

Unterstützen Sie die Installation von SUSE Private Registry über docker-compose?

Nein. Sie müssen SUSE Private Registry mit dem Helm Chart installieren und konfigurieren. Dieses Chart wird auch für das fortlaufende Management (Betrieb ab Tag 2) verwendet und kann in GitOps-Workflows integriert werden.

Empfehlen Sie Bereitstellung im lokalen (Rancher Manager) Cluster?

Nein. SUSE empfiehlt, SUSE Private Registry in einem Downstream-Cluster bereitzustellen. Dies macht das Registry für andere Downstream-Cluster zugänglich, die Images konsumieren müssen.

Was sind die besten Praktiken für die Bereitstellung in einer Hochverfügbarkeitsumgebung (HA)?

Für HA sollten Sie SUSE Private Registry nicht im Rancher Management-Cluster bereitstellen, um Ressourcenkonflikte zu vermeiden.

Sie können SUSE Private Registry in einem dedizierten Cluster oder in einem oder mehreren Ihrer Anwendungscluster bereitstellen.

Für Anleitungen siehe Chapter 5, Hochverfügbarkeit setup. Bitte beachten Sie, dass Sie Ihre eigenen HA-Komponenten für die Postgres-Datenbank, den Valkey- oder Redis-Server und den Ingress Controller bereitstellen müssen. Diese Komponenten werden nicht durch das SUSE Private Registry Helm Chart bereitgestellt und werden von SUSE nicht unterstützt.

Wird das SUSE Private Registry Helm Chart irgendwann zur Anwendungssammlung hinzugefügt?: Ja, SUSE plant, das Chart in Zukunft dort zu veröffentlichen.
Liefern Sie einen Kubernetes-Operator aus?: SUSE Private Registry wird nicht mit einem dedizierten Operator ausgeliefert. Es wird mit seinem Helm Chart installiert und verwaltet, das in GitOps integriert werden kann. SUSE bewertet weiterhin das Management auf Basis von Operatoren für zukünftige Versionen.

7.4 Sicherheit, Scannen und Signieren #

Integrieren Sie ein Signierungswerkzeug in SUSE Private Registry?

SUSE Private Registry signiert Bilder nicht selbst, kann jedoch Open Container Initiative (OCI)-kompatible Signaturen speichern, verteilen und verifizieren.

Ein weit verbreitetes Tool ist cosign, das Bilder signieren und die Signaturen in SUSE Private Registry speichern kann.

cosign-Signaturen, die an Bilder angehängt sind, sind im SUSE Private Registry-Portal einsehbar und herunterladbar.

Ist es möglich, Bilder mit Notary oder Cosign zur Genehmigung während des Bereitstellungsprozesses zu signieren?

SUSE Private Registry kann cosign-Signaturen speichern, verteilen und verifizieren.

SUSE Private Registry selbst signiert keine Bilder. Sie müssen Bilder während ihres Erstellungsprozesses signieren und dann die Signatur zusammen mit dem Bild im Registry hochladen.

Notary ist nicht in SUSE Private Registry enthalten oder wird nicht unterstützt.

Werden Bilder nur mit Trivy auf Common Vulnerabilities and Exposures (CVEs) gescannt, oder kann auch SUSE Security (NeuVector) verwendet werden?

Bilder werden mit Trivy gescannt, das sofort einsatzbereit ist. SUSE Security kann zusätzlich zu oder als Ersatz für Trivy hinzugefügt werden.

Ist es möglich, ClamAV oder ähnliche Malware-Scans durchzuführen?

Standardmäßig scannt SUSE Private Registry Bilder mit Trivy. Sie können auch SUSE Security (NeuVector) als Scanner konfigurieren.

Wird im Pull-Through-Cache-Szenario das Schwachstellenkriterien durchgesetzt?

Ja, aber mit einer bekannten Einschränkung. Aufgrund von Upstream Harbor Problemen werden Schwachstellenkriterien beim ersten Abruf eines Bildes nicht durchgesetzt, da der Scan noch nicht abgeschlossen ist.

Für eine vollständige Abdeckung kombinieren Sie SUSE Private Registry mit SUSE Security Admission-Kontrollen.

Sind die Containerbilder von SUSE Private Registry gehärtet?

Ja. Die Containerbilder für SUSE Private Registry sind gehärtet. Sie basieren auf SUSE Linux Enterprise Base Container Images (SLE BCI) und werden im gleichen unternehmensgerechten SUSE Build Service erstellt, der auch für SUSE Linux Enterprise verwendet wird. Dies gewährleistet eine sichere Lieferkette. Die Images sind ebenfalls signiert, und SUSE veröffentlicht ihre Supply-chain Levels for Software Artifacts (SLSA) Attestierungen.

Sind die Images von SUSE Private Registry signiert? Wie?

Die Images sind mit cosign signiert. Sie können diese überprüfen, indem Sie den im PEM-Format veröffentlichten Signaturschlüssel unter KB 000021411 speichern.

Führen Sie dann beispielsweise Folgendes aus:

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

7.5 Replikation und Synchronisierung #

Gibt es einen Plan für ein Plugin zur Synchronisierung mit SUSE Registry und SUSE Anwendungssammlung?: Ja, eine solche Funktion ist geplant.

Bietet SUSE Private Registry eine Multi-Site-Replikation an?: Ja. SUSE Private Registry unterstützt die Multi-Site-, richtlinienbasierte Bildreplikation (Pull und Push). Sie können Images über mehrere SUSE Private Registry Implementierungen hinweg synchronisieren, während jede Registry unabhängig bleibt.

7.6 Funktionen und Integration mit Rancher #

Gibt es einen Plan, das Registry innerhalb von Rancher mit einer Erweiterung zu integrieren?: Ja. SUSE plant eine tiefere Integration mit Rancher Prime und anderen Angeboten. Zukünftige Verbesserungen, die in Betracht gezogen werden, umfassen die Integration von Single Sign-On (SSO), vereinfachtes setup für SUSE Sicherheit Scanner und das Spiegeln von Anwendungssammlungen, Überwachung mit SUSE Einblick und eine Rancher UI-Erweiterung.
Wird SUSE das Registry zum Schulungskatalog hinzufügen?: Das ist noch nicht geplant. Wenn Sie an Schulungsmaterial interessiert sind, kontaktieren Sie SUSE, um Möglichkeiten mit dem Schulungsteam zu besprechen.

7.7 Support und Dokumentation #

Gibt es eine Support-Richtlinie für SUSE Private Registry?

Ja. Die Support-Richtlinie von SUSE Private Registry ist die gleiche wie die von jedem anderen Rancher Prime Add-on.

Wenn die SUSE Private Registry Dokumentation Informationen vermissen lässt, kann ich dann auf die offizielle Harbor Dokumentation verweisen?

Ja. Da SUSE Private Registry auf Harbor basiert, ist die offizielle Harbor Dokumentation eine nützliche Ressource. Für Funktionen, die spezifisch für die SUSE-Version sind, verweisen Sie auf die SUSE Private Registry Dokumentation.

Die Release notes geben an, welche Upstream-Harbor-Version Ihrer SUSE Private Registry-Version entspricht.

8 Fehlerbehebung #

Dieser Abschnitt bietet Lösungen für Probleme, die Sie beim Bereitstellen oder Verwenden von SUSE Private Registry haben könnten.

Ich erhalte den 401 unauthorized-Fehler, wenn ich versuche, SUSE Private Registry zu installieren.

Die vollständige Version der Fehlermeldung sieht wie folgt aus:

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]]

Um SUSE Private Registry zu installieren und zu verwenden, benötigen Sie Folgendes:

Ein qualifiziertes Abonnement, das dieses Produkt umfasst, wie ein Rancher Suite Abonnement oder ein SUSE Private Registry Add-on-Abonnement. Wenn Sie kein qualifiziertes Abonnement haben, wenden Sie sich an Ihren SUSE-Vertreter.
Melden Sie sich bei SUSE Registry mit Helm unter Verwendung der SCC-Spiegelungsanmeldeinformationen der SCC-Organisation an, die das Abonnement hält. Weitere Informationen finden Sie in Section 4.1, “Erhalten von Kubernetes Geheimnissen aus dem SUSE Kundenzentrum”.

A Überschreiben des SUSE Private Registry Helm Charts #

Das SUSE Private Registry (Private Registry) Helm Chart wird mit Standardwerten geliefert. Sie können die Installation des Helm Charts auf eine der folgenden Arten anpassen:

Fügen Sie spezifische Parameter zu den --set Flags in der helm install Befehlszeile hinzu, zum Beispiel:

$ 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 Beispiele für SUSE Registry Helm Override-Dateien #

Example A1: Minimale Bereitstellung mit Ingress #

expose:
  type: ingress 1
  ingress:
    hosts:
      core: <PRIVATE_REGISTRY_FQDN> 2

externalURL: https://<PRIVATE_REGISTRY_FQDN> 3

harborAdminPassword: "<MY_PASSWORD>" 4

datenbank:
  intern:
    passwort: "<MY_PASSWORD_POSTGRESQL>"

redis:
  intern:
   passwort: "<MY_PASSWORD_REDIS>"

1	Wie SUSE Registry exponiert wird. Kann `ingress`, `loadBalancer`, `nodePort` oder `clusterIPhis` sein. Der Standardwert ist `ingress`.
2	Hostname für die interne Netzwerkkonfiguration des Kubernetes.
3	URL, unter der die SUSE Registry Anwendung läuft. Es wird verwendet, um Links in der Benutzeroberfläche, Weiterleitungen und auch für API-Antworten zu generieren.
4	Das Administratorkennwort für die Anwendung.

Example A2: Typische Bereitstellung mit 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

datenbank:
  intern:
    passwort: "<MY_PASSWORD_POSTGRESQL>"

redis:
  intern:
   passwort: "<MY_PASSWORD_REDIS>"

1	Wie SUSE Registry exponiert wird. Kann `ingress`, `loadBalancer`, `nodePort` oder `clusterIP` sein. Der Standardwert ist `ingress`.
2	Kann `auto`, `secret` oder `none` sein. Je nach Option müssen möglicherweise zusätzliche Werte angegeben werden.
3	Bei Verwendung der TLS-Verschlüsselung muss dieses Feld mit dem `externalURL` Wert übereinstimmen.
4	URL, unter der die SUSE Registry Anwendung läuft. Es wird verwendet, um Links in der Benutzeroberfläche, Weiterleitungen und auch für API-Antworten zu generieren.
5	Das Administratorkennwort für die Anwendung.

A2 Überschreiben der Helm Chart-Parameter und -Werte #

Die folgenden Tabellen listen alle Parameter mit Beschreibungen auf, die Sie verwenden können, um die Standardinstallationswerte zu überschreiben.

Globale Parameter #

global.imageRegistry: Setzt ein globales Override für die Container-Image-Registry, die für alle Images verwendet wird.
global.imagePullSecrets: Setzt globale Pull-Secrets für den Zugriff auf die Container-Image-Registry.

Allgemeine Parameter #

harborAdminPassword: Setzt das anfängliche Passwort für den Harbor Administrator. Ändern Sie es nach der Bereitstellung im Portal. Der Standardwert ist Harbor12345.
externalURL: Gibt die externe URL für den harbor-core Dienst an. Der Standardwert ist https://core.harbor.domain.
existingSecretAdminPasswordKey: Setzt den Schlüsselnamen im Geheimnis, das das Passwort des Harbor Administrators enthält. Der Standardwert ist HARBOR_ADMIN_PASSWORD.
imagePullSecrets: Setzt die imagePullSecrets Namen für alle Bereitstellungen.
updateStrategy.type: Setzt die Aktualisierungsstrategie für Bereitstellungen mit persistenten Volumes. Akzeptiert RollingUpdate oder Recreate. Verwenden Sie Recreate, wenn RWM für Volumes nicht unterstützt wird. Der Standardwert ist RollingUpdate.
logLevel: Setzt das Protokollniveau für Harbor Dienste. Akzeptiert fatal, error, warn, info, debug oder trace. Der Standardwert ist debug.
enableMigratehelmHook: Führt die Datenbank-Migrationsaufgabe über den Helm Hook aus. Wenn true, trennt die Migrationsaufgabe von harbor-core. Der Standardwert ist false.
caSecretName: Gibt den geheimen Namen an, der den ca.crt-Schlüssel enthält.

Proxy-Parameter #

proxy.httpProxy: Gibt die URL des HTTP-Proxy-Servers an. Der Standardwert ist "".
proxy.httpsProxy: Gibt die URL des HTTPS-Proxy-Servers an. Der Standardwert ist "".
proxy.noProxy: Legt URLs fest, die die Proxy-Konfiguration umgehen. Der Standardwert ist 127.0.0.1,localhost,.local,.internal.
proxy.components: Legt Komponenten fest, die die Proxy-Konfiguration verwenden. Der Standardwert ist ["core","jobservice","trivy"].

Parameter freigeben #

expose.type: Gibt den Typ der Dienstfreigabe an: ingress, clusterIP, nodePort oder loadBalancer. Der Standardwert ist ingress.
expose.tls.enabled: Aktiviert TLS. Der Standardwert ist true.
expose.tls.certSource: Legt die Quelle des TLS-Zertifikats als auto, secret oder none fest. Der Standardwert ist auto.
expose.tls.auto.commonName: Legt den allgemeinen Namen des Zertifikats fest, wenn der Typ nicht ingress ist.
expose.tls.secret.secretName: Gibt den Namen des Geheimnisses an, das tls.crt (Zertifikat) und tls.key (privater Schlüssel) enthält.
expose.ingress.hosts.core: Legt den Harbor-Kernel-Service-Host in der Ingress-Regel fest. Der Standardwert ist core.harbor.domain.
expose.ingress.controller: Legt den Ingress-Controller-Typ fest. Unterstützt default, gce, alb, f5-bigip und ncp. Der Standardwert ist default.
expose.ingress.kubeVersionOverride: Überschreibt die Kubernetes-Version für Ingress-Templating.
expose.ingress.annotations: Legt die Ingress-Annotationen fest.
expose.ingress.labels: Legt die Ingress-spezifischen Labels fest. Der Standardwert ist {}.
expose.clusterIP.name: Legt den Namen des ClusterIP-Dienstes fest. Der Standardwert ist harbor.
expose.clusterIP.annotations: Legt die Annotationen des ClusterIP-Dienstes fest. Der Standardwert ist {}.
expose.clusterIP.ports.httpPort: Legt den HTTP-Dienstport fest. Der Standardwert ist 80.
expose.clusterIP.ports.httpsPort: Legt den HTTPS-Dienstport fest. Der Standardwert ist 443.
expose.clusterIP.labels: Legt ClusterIP-spezifische Labels fest. Der Standardwert ist {}.
expose.nodePort.name: Legt den NodePort-Dienstnamen fest. Der Standardwert ist harbor.
expose.nodePort.ports.http.port: Legt den HTTP-Dienstport fest. Der Standardwert ist 80.
expose.nodePort.ports.http.nodePort: Legt den HTTP-Nodeport fest. Der Standardwert ist 30002.
expose.nodePort.ports.https.port: Legt den HTTPS-Dienstport fest. Der Standardwert ist 443.
expose.nodePort.ports.https.nodePort: Legt den HTTPS-Nodeport fest. Der Standardwert ist 30003.
expose.nodePort.annotations: Legt die Annotationen von NodePort fest.
expose.nodePort.labels: Legt NodePort-spezifische Labels fest. Der Standardwert ist {}.
expose.loadBalancer.name: Legt den Dienstnamen fest. Der Standardwert ist harbor.
expose.loadBalancer.IP: Legt die IP des LoadBalancers fest, wenn die IP-Zuweisung unterstützt wird. Der Standardwert ist "".
expose.loadBalancer.ports.httpPort: Legt den HTTP-Dienstport fest. Der Standardwert ist 80.
expose.loadBalancer.ports.httpsPort: Legt den HTTPS-Dienstport fest. Der Standardwert ist 30002.
expose.loadBalancer.annotations: Legt die Anmerkungen des LoadBalancers fest. Der Standardwert ist {}.
expose.loadBalancer.labels: Legt LoadBalancer-spezifische Labels fest. Der Standardwert ist {}.
expose.loadBalancer.sourceRanges: Spezifiziert IP-Adressbereiche für loadBalancerSourceRanges. Der Standardwert ist [].

Persistenzparameter #

persistence.enabled: Aktiviert oder deaktiviert die Datenpersistenz. Der Standardwert ist true.
persistence.resourcePolicy: keep verhindert die Entfernung von PVCs während einer Helm Löschoperation. Ein leerer Wert löscht PVCs nach der Chart-Löschung. Der Standardwert ist keep.
persistence.persistentVolumeClaim.registry.existingClaim: Der vorhandene PVC, der manuell erstellt werden muss, bevor die Bindung erfolgt. Erfordert eine subPath-Spezifikation, wenn der PVC mit anderen Komponenten geteilt wird.
persistence.persistentVolumeClaim.registry.storageClass: Der storageClass, der das Volume bereitstellt.
persistence.persistentVolumeClaim.registry.subPath: Der Unterpfad im Volume.
persistence.persistentVolumeClaim.registry.accessMode: Der Zugriffsmodus des Volumes. Der Standardwert ist ReadWriteOnce.
persistence.persistentVolumeClaim.registry.size: Die Größe des Volumes. Der Standardwert ist 5Gi.
persistence.persistentVolumeClaim.registry.annotations: Die Annotationen des Volumes.
persistence.persistentVolumeClaim.jobservice.jobLog.existingClaim: Der vorhandene PVC, der manuell erstellt werden muss, bevor die Bindung erfolgt. Erfordert eine subPath-Spezifikation, wenn der PVC mit anderen Komponenten geteilt wird.
persistence.persistentVolumeClaim.jobservice.jobLog.storageClass: Der storageClass, der das Volume bereitstellt.
persistence.persistentVolumeClaim.jobservice.jobLog.subPath: Der Unterpfad im Volume.
persistence.persistentVolumeClaim.jobservice.jobLog.accessMode: Der Zugriffsmodus des Volumes. Der Standardwert ist ReadWriteOnce.
persistence.persistentVolumeClaim.jobservice.jobLog.size: Die Größe des Volumes. Der Standardwert ist 1Gi.
persistence.persistentVolumeClaim.jobservice.jobLog.annotations: Die Annotationen des Volumes.
persistence.persistentVolumeClaim.database.existingClaim: Der vorhandene PVC, der manuell erstellt werden muss, bevor die Bindung erfolgt. Erfordert eine subPath-Spezifikation, wenn der PVC mit anderen Komponenten geteilt wird.
persistence.persistentVolumeClaim.database.storageClass: Der storageClass, der das Volume bereitstellt.
persistence.persistentVolumeClaim.database.subPath: Der Unterpfad im Volume. Wird ignoriert, wenn eine externe Datenbank verwendet wird.
persistence.persistentVolumeClaim.database.accessMode: Der Zugriffsmodus des Volumes. Wird ignoriert, wenn eine externe Datenbank verwendet wird. Der Standardwert ist ReadWriteOnce.
persistence.persistentVolumeClaim.database.size: Die Größe des Volumes. Wird ignoriert, wenn eine externe Datenbank verwendet wird. Der Standardwert ist 1Gi.
persistence.persistentVolumeClaim.database.annotations: Die Annotationen des Volumes.
persistence.persistentVolumeClaim.redis.existingClaim: Der vorhandene PVC, der manuell erstellt werden muss, bevor die Bindung erfolgt. Erfordert eine subPath-Spezifikation, wenn der PVC mit anderen Komponenten geteilt wird.
persistence.persistentVolumeClaim.redis.storageClass: Der storageClass, der das Volume bereitstellt. Verwendet die Standard-StorageClass, wenn nicht angegeben.
persistence.persistentVolumeClaim.redis.subPath: Der Unterpfad im Volume. Wird ignoriert, wenn ein externes Valkey verwendet wird.
persistence.persistentVolumeClaim.redis.accessMode: Der Zugriffsmodus des Volumes. Wird ignoriert, wenn ein externes Valkey verwendet wird. Der Standardwert ist ReadWriteOnce.
persistence.persistentVolumeClaim.redis.size: Die Größe des Volumes. Wird ignoriert, wenn ein externes Valkey verwendet wird. Der Standardwert ist 1Gi.
persistence.persistentVolumeClaim.redis.annotations: Die Annotationen des Volumes.
persistence.persistentVolumeClaim.trivy.existingClaim: Der vorhandene PVC, der manuell erstellt werden muss, bevor die Bindung erfolgt. Erfordert eine subPath-Spezifikation, wenn der PVC mit anderen Komponenten geteilt wird.
persistence.persistentVolumeClaim.trivy.storageClass: Der storageClass, der das Volume bereitstellt. Verwendet die Standard-StorageClass, wenn nicht angegeben.
persistence.persistentVolumeClaim.trivy.subPath: Der Unterpfad im Volume.
persistence.persistentVolumeClaim.trivy.accessMode: Der Zugriffsmodus des Volumes. Der Standardwert ist ReadWriteOnce.
persistence.persistentVolumeClaim.trivy.size: Die Größe des Volumes. Der Standardwert ist 1Gi.
persistence.persistentVolumeClaim.trivy.annotations: Die Annotationen des Volumes.
persistence.imageChartStorage.disableredirect: Steuert das Redirect-Management von Content-Backends. Auf true setzen, um Redirects für nicht unterstützte Backends zu deaktivieren. Der Standardwert ist false.
persistence.imageChartStorage.caBundleSecretName: Der Name des Secrets, das das CA-Bundle für selbstsignierte Speicherzertifikate enthält.
persistence.imageChartStorage.type: Der Speichertyp für Bilder und Diagramme: filesystem, azure, gcs, s3, swift oder oss. Der Standardwert ist filesystem.
persistence.imageChartStorage.gcs.existingSecret: Der Name des vorhandenen Secrets, das den JSON-Schlüssel des GCS-Dienstkontos enthält. Der Schlüssel muss gcs-key.json sein. Der Standardwert ist "".
persistence.imageChartStorage.gcs.useWorkloadIdentity: Aktiviert die Nutzung der Workload-Identität in einem GKE-Cluster. Der Standardwert ist false.

Die standardmäßige nginx- Parameter #

nginx.image.repository: Das Image-Repository für Die standardmäßige nginx-. Der Standardwert ist private-registry/harbor-nginx.
nginx.image.tag: Der Image-Tag für Die standardmäßige nginx-.
nginx.replicas: Die Anzahl der auszuführenden Replikate. Der Standardwert ist 1.
nginx.revisionHistoryLimit: Die maximale Anzahl alter ReplicaSet Revisionen, die beibehalten werden sollen. Der Standardwert ist 10.
nginx.resources: Die Rechenressourcen, die für den Container zugewiesen sind. Der Standardwert ist undefined.
nginx.automountServiceAccountToken: Steuert die automatische Montage des Tokens des Dienstkontos. Der Standardwert ist false.
nginx.nodeSelector: Die Knoten-Labels, die für die Pod-Zuweisung verwendet werden. Der Standardwert ist {}.
nginx.tolerations: Die Toleranzen für die Pod-Zuweisung. Der Standardwert ist [].
nginx.affinity: Die Regeln für die Affinität von Knoten oder Pods. Der Standardwert ist {}.
nginx.topologySpreadConstraints: Die Regeln für die Verteilung von Pods über Ausfallbereiche wie Regionen oder Verfügbarkeitszonen. Der Standardwert ist [].
nginx.podAnnotations: Die Annotationen, die dem Die standardmäßige nginx- Pod hinzugefügt wurden. Der Standardwert ist {}.

Portalparameter #

portal.image.repository: Repository-Standort für das Portalbild. Der Standardwert ist private-registry/harbor-portal.
portal.image.tag: Tag für das Portalbild. Der Standardwert ist 3.11.
portal.replicas: Anzahl der zu erstellenden Replikate. Der Standardwert ist 1.
portal.revisionHistoryLimit: Maximale Anzahl alter ReplicaSet Revisionen, die beibehalten werden sollen. Der Standardwert ist 10.
portal.resources: Ressourcen, die dem Container zugewiesen sind. Der Standardwert ist undefined.
portal.automountServiceAccountToken: Steuert die automatische Montage des Tokens des Dienstkontos. Der Standardwert ist false.
portal.nodeSelector: Knoten-Labels, die für die Pod-Zuweisung verwendet werden. Der Standardwert ist {}.
portal.tolerations: Toleranzen, die für die Pod-Zuweisung verwendet werden. Der Standardwert ist [].
portal.affinity: Einstellungen zur Affinität von Knoten und Pods. Der Standardwert ist {}.
portal.topologySpreadConstraints: Definiert die Verteilung von Pods über Ausfallbereiche wie Regionen oder Verfügbarkeitszonen. Der Standardwert ist [].
portal.podAnnotations: Annotationen, die dem Portal-Pod hinzugefügt wurden. Der Standardwert ist {}.
portal.serviceAnnotations: Annotationen, die dem Portal-Dienst hinzugefügt wurden. Der Standardwert ist {}.
portal.priorityClassName: Prioritätsklassenname für die Pod-Ausführung.
portal.initContainers: Init-Container, die vor dem Start des Controller-Containers ausgeführt werden sollen. Der Standardwert ist [].

Kernelparameter #

core.image.repository: Das Repository für das Harbor Kernel-Image. Der Standardwert ist private-registry/harbor-core.
core.image.tag: Das Tag für das Harbor Kernel-Image. Der Standardwert ist 2.11.
core.replicas: Die Anzahl der Replikate. Der Standardwert ist 1.
core.revisionHistoryLimit: Das Limit der Revisionshistorie. Der Standardwert ist 10.
core.startupProbe.initialDelaySeconds: Die anfängliche Verzögerung in Sekunden für die Startprobe. Der Standardwert ist 10.
core.resources: Die Ressourcen, die für den Container zugewiesen werden sollen. Der Standardwert ist undefined.
core.automountServiceAccountToken: Montiert das Token des Dienstkontos. Der Standardwert ist false.
core.nodeSelector: Die Knotenlabels für die Pod-Zuweisung. Der Standardwert ist {}.
core.tolerations: Die Toleranzen für die Pod-Zuweisung. Der Standardwert ist [].
core.affinity: Die Knoten- oder Pod-Affinitäten. Der Standardwert ist {}.
core.topologySpreadConstraints: Die Einschränkungen, die definieren, wie Pods über Fehlerdomänen wie Regionen oder Verfügbarkeitszonen verteilt werden. Der Standardwert ist [].
core.podAnnotations: Die Annotationen, die zum Kernel-Pod hinzugefügt werden sollen. Der Standardwert ist {}.
core.serviceAnnotations: Die Annotationen, die zum Kernel-Dienst hinzugefügt werden sollen. Der Standardwert ist {}.
core.configureUserSettings: Ein JSON-String in der Umgebungsvariable CONFIG_OVERWRITE_JSON zur Konfiguration der Benutzereinstellungen.
core.quotaUpdateProvider: Der Anbieter zur Aktualisierung der Projektquoten-Nutzung, Optionen sind redis oder db. Der Standardwert ist db.
core.secret: Wird verwendet, wenn der Kernelserver mit anderen Komponenten kommuniziert.
core.secretName: Der Name eines Kubernetes Geheimnisses, um Ihr eigenes TLS-Zertifikat und den privaten Schlüssel für die Token-Verschlüsselung oder -Entschlüsselung zu verwenden.
core.tokenKey: Der im PEM-Format vorliegende RSA-Private-Key, der zur Signierung von Dienst-Token verwendet wird.
core.tokenCert: Das im PEM-Format vorliegende Zertifikat, das von core.tokenKey signiert wurde und zur Validierung von Dienst-Token verwendet wird.
core.xsrfKey: Der XSRF-Schlüssel, der automatisch generiert wird, wenn er nicht angegeben ist.
core.priorityClassName: Die Prioritätsklasse, unter der der Pod ausgeführt werden soll.
core.artifactPullAsyncFlushDuration: Die Zeitdauer für die asynchrone Aktualisierung der Artefakt-Pull-Zeit und der Repository-Pull-Anzahl.
core.gdpr.deleteUser: Aktiviert die DSGVO-konforme Benutzerlöschung. Der Standardwert ist false.
core.gdpr.auditLogsCompliant: Aktiviert die DSGVO-Konformität für Audit-Protokolle, indem der Benutzername in seinen CRC32-Wert geändert wird, wenn dieser Benutzer aus dem System gelöscht wurde. Der Standardwert ist false.
core.initContainers: Die Init-Container, die vor dem Start des Containers des Controllers ausgeführt werden sollen. Der Standardwert ist [].

Jobservice-Parameter #

jobservice.image.repository: Das Repository für das Jobservice-Image. Der Standardwert ist private-registry/harbor-jobservice.
jobservice.image.tag: Das Tag für das Jobservice-Image. Der Standardwert ist 2.11.
jobservice.replicas: Die Anzahl der Replikate. Der Standardwert ist 1.
jobservice.revisionHistoryLimit: Das Limit der Revisionshistorie. Der Standardwert ist 10.
jobservice.maxJobWorkers: Die maximale Anzahl an Jobarbeitern. Der Standardwert ist 10.
jobservice.jobLoggers: Die Logger für Jobs: file, database oder stdout. Der Standardwert ist [file].
jobservice.loggerSweeperDuration: Die Dauer in Tagen, um Jobprotokolle aufzubewahren (wird ignoriert, wenn jobLoggers auf stdout gesetzt ist). Der Standardwert ist 14.
jobservice.notification.webhook_job_max_retry: Die maximale Anzahl an Wiederholungen für das Senden von Webhook-Benachrichtigungen. Der Standardwert ist 3.
jobservice.notification.webhook_job_http_client_timeout: Der HTTP-Client-Timeout in Sekunden für das Senden von Webhook-Benachrichtigungen. Der Standardwert ist 3.
jobservice.reaper.max_update_hours: Die maximale Zeit in Stunden, um auf den Abschluss einer Aufgabe zu warten. Wenn die Aufgabe nach den angegebenen Stunden nicht abgeschlossen ist, wird sie als Fehler markiert, läuft jedoch weiter. Der Standardwert ist 24.
jobservice.reaper.max_dangling_hours: Die maximale Zeit in Stunden für die Ausführung im laufenden Zustand, ohne dass eine neue Aufgabe erstellt wird. Der Standardwert ist 168.
jobservice.resources: Die [Ressourcen], die für den Container zugewiesen werden sollen. Der Standardwert ist undefined.
jobservice.automountServiceAccountToken: Montiert das Token des Dienstkontos. Der Standardwert ist false.
jobservice.nodeSelector: Die Knotenlabels für die Pod-Zuweisung. Der Standardwert ist {}.
jobservice.tolerations: Die Toleranzen für die Pod-Zuweisung. Der Standardwert ist [].
jobservice.affinity: Die Knoten- oder Pod-Affinitäten. Der Standardwert ist {}.
jobservice.topologySpreadConstraints: Die Einschränkungen, die definieren, wie Pods über Fehlerdomänen wie Regionen oder Verfügbarkeitszonen verteilt werden. Der Standardwert ist [].
jobservice.podAnnotations: Die Annotationen, die dem Jobservice-Pod hinzugefügt werden sollen. Der Standardwert ist {}.
jobservice.priorityClassName: Die Prioritätsklasse, unter der der Pod ausgeführt werden soll.
jobservice.secret: Das Geheimnis, das verwendet wird, wenn der Jobdienst mit anderen Komponenten kommuniziert. Wenn kein geheimer Schlüssel angegeben ist, wird Helm generiert. Muss eine Zeichenkette von 16 Zeichen sein.
jobservice.initContainers: Die Init-Container, die vor dem Start des Containers des Controllers ausgeführt werden sollen. Der Standardwert ist [].

Registrierungsparameter #

registry.registry.image.repository: Der Speicherort des Registrierungsimages. Der Standardwert ist private-registry/harbor-registry.
registry.registry.image.tag: Das Tag für das Registrierungsimage. Der Standardwert ist 2.11.
registry.registry.resources: Die [Ressourcen], die für den Container zugewiesen werden sollen. Der Standardwert ist undefined.
registry.controller.image.repository: Der Speicherort des Registrierungscontroller-Images. Der Standardwert ist private-registry/harbor-registryctl.
registry.controller.image.tag: Das Tag für das Registrierungscontroller-Image. Der Standardwert ist 2.11.
registry.controller.resources: Die [Ressourcen], die für den Container zugewiesen werden sollen. Der Standardwert ist undefined.
registry.replicas: Die Anzahl der Replikatinstanzen. Der Standardwert ist 1.
registry.revisionHistoryLimit: Die maximale Anzahl von Revisionen, die in der Historie beibehalten werden sollen. Der Standardwert ist 10.
registry.nodeSelector: Die Knotenlabels für die Pod-Zuweisung. Der Standardwert ist {}.
registry.automountServiceAccountToken: Steuert, ob das Token des Dienstkontos gemountet werden soll. Der Standardwert ist false.
registry.tolerations: Die Toleranzen für die Pod-Zuweisung. Der Standardwert ist [].
registry.affinity: Die Knoten- oder Pod-Affinitäten. Der Standardwert ist {}.
registry.topologySpreadConstraints: Die Einschränkungen, die die Verteilung von Pods über Fehlerdomänen wie Regionen oder Verfügbarkeitszonen definieren. Der Standardwert ist [].
registry.middleware: Middleware-Unterstützung für ein CDN zwischen dem Backend-Speicher und dem Docker Pull-Empfänger.
registry.podAnnotations: Die Annotationen, die dem Registrierungs-Pod hinzugefügt werden sollen. Der Standardwert ist {}.
registry.priorityClassName: Die Prioritätsklasse für die Pod-Ausführung.
registry.secret: Das Geheimnis, das den Upload-Zustand zwischen dem Client und dem Registrierungs-Speicher-Backend sichert.
registry.credentials.username: Der Benutzername für den internen Zugriff auf das Registrierungs-Backend von Harbor Kernel. Der Standardwert ist harbor_registry_user.
registry.credentials.password: Das Passwort für den internen Zugriff auf das Registrierungs-Backend von Harbor Kernel. Der Standardwert ist harbor_registry_password.
registry.credentials.existingSecret: Ein vorhandenes Geheimnis, das das Passwort für den Zugriff auf die Registrierungsinstanz im htpasswd-Authentifizierungsmodus enthält. Der Standardwert ist "".
registry.credentials.htpasswdString: Der Login und das Passwort im htpasswd-Zeichenfolgenformat. Schließt registry.credentials.username und registry.credentials.password aus. Der Standardwert ist undefined.
registry.relativeurls: Gibt relative URLs in den Location-Headern zurück, wenn dies wahr ist. Erforderlich, wenn Harbor hinter einem Reverse-Proxy steht. Der Standardwert ist false.
registry.upload_purging.enabled: Ermöglicht das Löschen von Upload-Verzeichnissen. Der Standardwert ist true.
registry.upload_purging.age: Der Zeitraum, nach dem Dateien in Upload-Verzeichnissen entfernt werden, standardmäßig eine Woche. Der Standardwert ist 168h.
registry.upload_purging.interval: Das Zeitintervall zwischen Löschvorgängen. Der Standardwert ist 24h.
registry.upload_purging.dryrun: Aktiviert den Trockenlaufmodus für das Löschen von Uploads. Der Standardwert ist false.
registry.initContainers: Die Init-Container, die vor dem Start des Containers des Controllers ausgeführt werden. Der Standardwert ist [].

Trivy Parameter #

trivy.enabled: Aktiviert oder deaktiviert den Trivy Scanner. Der Standardwert ist true.
trivy.image.repository: Das Repository für das Trivy Adapter-Image. Der Standardwert ist private-registry/harbor-trivy-adapter.
trivy.image.tag: Das Tag für das Trivy Adapter-Image. Der Standardwert ist 2.11.
trivy.resources: Die Ressourcen, die für den Trivy Adapter-Container zugewiesen werden sollen. Der Standardwert ist undefined.
trivy.automountServiceAccountToken: Ob das Token des Dienstkontos gemountet werden soll. Der Standardwert ist false.
trivy.replicas: Die Anzahl der Pod-Replikate. Der Standardwert ist 1.
trivy.debugMode: Aktiviert den Trivy Debug-Modus zur Fehlersuche. Der Standardwert ist false.
trivy.vulnType: Durch Kommas getrennte Liste von Schwachstellentypen (os und library). Der Standardwert ist os,library.
trivy.severity: Durch Kommas getrennte Liste von Schweregraden von Schwachstellen, die überprüft werden sollen. Der Standardwert ist UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL.
trivy.ignoreUnfixed: Zeigt nur behobene Schwachstellen an. Der Standardwert ist false.
trivy.insecure: Überspringt die Überprüfung des Registrierungszertifikats. Der Standardwert ist false.
trivy.skipUpdate: Deaktiviert die Trivy Datenbankdownloads von GitHub. Der Standardwert ist false.
trivy.skipJavaDBUpdate: Erfordert den manuellen Download der trivy-java.db Datei, wenn aktiviert. Der Standardwert ist false.
trivy.offlineScan: Verhindert, dass Trivy API-Anfragen sendet, um Abhängigkeiten zu identifizieren. Der Standardwert ist false.
trivy.securityCheck: Durch Kommas getrennte Liste von Sicherheitsproblemen, die erkannt werden sollen. Der Standardwert ist vuln.
trivy.timeout: Die Dauer, die auf den Abschluss des Scans gewartet werden soll. Der Standardwert ist 5m0s.
trivy.gitHubToken: Das für den Datenbankdownload erforderliche GitHub-Zugriffstoken. Der Standardwert ist undefined.
trivy.priorityClassName: Die Prioritätsklasse für die Ausführung des Pods. Der Standardwert ist undefined.
trivy.topologySpreadConstraints: Definiert die Verteilungseinschränkungen für Pods über Fehlerdomänen. Der Standardwert ist undefined.
trivy.initContainers: Liste der Init-Container, die vor dem Start des Hauptcontainers ausgeführt werden sollen. Der Standardwert ist [].

Datenbankparameter #

database.type: Der Datenbanktyp. Auf external setzen, wenn eine externe Datenbank verwendet wird. Der Standardwert ist internal.
database.internal.image.repository: Das Repository für das Datenbank-Image. Der Standardwert ist private-registry/harbor-db.
database.internal.image.tag: Das Tag für das Datenbank-Image. Der Standardwert ist 2.11.
database.internal.password: Das Passwort für die interne Datenbank. Der Standardwert ist changeit.
database.internal.shmSizeLimit: Das Limit für die Größe des gemeinsamen Speichers für PostgreSQL (typischerweise 50 % des Container-Speicherlimits). Der Standardwert ist 512Mi.
database.internal.resources: Die für den Datenbankcontainer zugewiesenen Ressourcen. Der Standardwert ist undefined.
database.internal.automountServiceAccountToken: Steuert, ob das Token des Dienstkontos montiert wird. Der Standardwert ist false.
database.internal.initContainer.migrator.resources: Die für den Init-Container des Datenbankmigrators zugewiesenen Ressourcen. Der Standardwert ist undefined.
database.internal.initContainer.permissions.resources: Die für den Init-Container der Datenbankberechtigungen zugewiesenen Ressourcen. Der Standardwert ist undefined.
database.internal.nodeSelector: Die Knotenlabels für die Pod-Zuweisung. Der Standardwert ist {}.
database.internal.tolerations: Die Toleranzen für die Pod-Zuweisung. Der Standardwert ist [].
database.internal.affinity: Die Einstellungen für die Knoten- oder Pod-Affinität. Der Standardwert ist {}.
database.internal.priorityClassName: Die Prioritätsklasse für die Ausführung des Pods. Der Standardwert ist undefined.
database.internal.livenessProbe.timeoutSeconds: Das Timeout in Sekunden für die Liveness-Prüfung (Bereich: 1-5s). Der Standardwert ist 1.
database.internal.readinessProbe.timeoutSeconds: Der Timeout in Sekunden für die Readiness-Prüfung (Bereich: 1-5s). Der Standardwert ist 1.
database.internal.extrInitContainers: Zusätzliche Init-Container, die vor dem Start des Datenbankcontainers ausgeführt werden. Der Standardwert ist [].
database.external.host: Der Hostname der externen Datenbank. Der Standardwert ist 192.168.0.1.
database.external.port: Die Portnummer der externen Datenbank. Der Standardwert ist 5432.
database.external.username: Der Benutzername für die externe Datenbank. Der Standardwert ist user.
database.external.password: Das Passwort für die externe Datenbank. Der Standardwert ist password.
database.external.coreDatabase: Der Datenbankname, der vom Kernelservice verwendet wird. Der Standardwert ist registry.
database.external.existingSecret: Das vorhandene Secret, das das Datenbankpasswort enthält. Der Schlüssel muss password sein. Der Standardwert ist "".
database.external.sslmode: Die Verbindungsart für die externe Datenbank. Optionen: require, verify-full, verify-ca, disable. Der Standardwert ist disable.
database.maxIdleConns: Die maximale Anzahl an inaktiven Verbindungen im Pool (0 oder weniger bedeutet, dass keine inaktiven Verbindungen behalten werden). Der Standardwert ist 50.
database.maxOpenConns: Die maximale Anzahl an offenen Verbindungen zur Datenbank (0 oder weniger bedeutet unbegrenzt). Der Standardwert ist 100.
database.podAnnotations: Die Annotationen, die zum Datenbank-Pod hinzugefügt werden sollen. Der Standardwert ist {}.

Valkey / Redis Parameter #

redis.type: Der Redis Implementierungstyp. Auf external setzen für externe Redis. Der Standardwert ist internal.
redis.internal.image.repository: Das Repository für das Redis Image. Der Standardwert ist private-registry/harbor-redis.
redis.internal.image.tag: Das Tag für das Redis Image. Der Standardwert ist 7.2.
redis.internal.resources: Die Ressourcen, die für den Redis Container zugewiesen sind. Der Standardwert ist undefined.
redis.internal.automountServiceAccountToken: Steuert, ob das Token des Dienstkontos montiert wird. Der Standardwert ist false.
redis.internal.nodeSelector: Die Knotenlabels für die Pod-Zuweisung. Der Standardwert ist {}.
redis.internal.tolerations: Die Toleranzen für die Pod-Zuweisung. Der Standardwert ist [].
redis.internal.affinity: Die Einstellungen für die Knoten- oder Pod-Affinität. Der Standardwert ist {}.
redis.internal.priorityClassName: Die Prioritätsklasse für das Ausführen des Redis Pods. Der Standardwert ist undefined.
redis.internal.jobserviceDatabaseIndex: Der Datenbankindex für den Jobservice. Der Standardwert ist 1.
redis.internal.registryDatabaseIndex: Der Datenbankindex für die Registry. Der Standardwert ist 2.
redis.internal.trivyAdapterIndex: Der Datenbankindex für den Trivy Adapter. Der Standardwert ist 5.
redis.internal.harborDatabaseIndex: Der Datenbankindex für die verschiedenen Harbor Geschäftslogik. Der Standardwert ist 0.
redis.internal.cacheLayerDatabaseIndex: Der Datenbankindex für die Cache-Schicht von Harbor. Der Standardwert ist 0.
redis.internal.initContainers: Die Init-Container, die vor dem Start des Redis Containers ausgeführt werden. Der Standardwert ist [].
redis.external.addr: Die Adresse der externen Redis Instanz. Der Standardwert ist 192.168.0.2:6379.
redis.external.sentinelMasterSet: Der Name des Redis Sentinel Master Sets (sofern zutreffend). Der Standardwert ist undefined.
redis.external.coreDatabaseIndex: Der Datenbankindex für den Kernel. Der Standardwert ist 0.
redis.external.jobserviceDatabaseIndex: Der Datenbankindex für den Jobservice. Der Standardwert ist 1.
redis.external.registryDatabaseIndex: Der Datenbankindex für die Registry. Der Standardwert ist 2.
redis.external.trivyAdapterIndex: Der Datenbankindex für den Trivy Adapter. Der Standardwert ist 5.
redis.external.harborDatabaseIndex: Der Datenbankindex für die verschiedenen Harbor Geschäftslogik. Der Standardwert ist 0.
redis.external.cacheLayerDatabaseIndex: Der Datenbankindex für die Cache-Schicht von Harbor. Der Standardwert ist 0.
redis.external.username: Der Benutzername für die externe Redis Authentifizierung. Der Standardwert ist undefined.
redis.external.password: Das Passwort für die externe Redis Authentifizierung. Der Standardwert ist undefined.
redis.external.existingSecret: Das vorhandene Geheimnis, das das Redis Passwort enthält. Der Schlüssel muss REDIS_PASSWORD sein. Der Standardwert ist "".
redis.podAnnotations: Die Annotationen, die zum Redis Pod hinzugefügt werden sollen. Der Standardwert ist {}.

Exporter-Parameter #

exporter.replicas: Die Anzahl der zu betreibenden Replikate. Der Standardwert ist 1.
exporter.revisionHistoryLimit: Das Limit der Versionshistorie. Der Standardwert ist 10.
exporter.podAnnotations: Annotationen, die zum Exporter-Pod hinzugefügt werden sollen. Der Standardwert ist {}.
exporter.image.repository: Das Repository für das Exporter-Image. Der Standardwert ist private-registry/harbor-exporter.
exporter.image.tag: Das Tag für das Exporter-Image. Der Standardwert ist 2.11.
exporter.nodeSelector: Knotenbeschriftungen für die Pod-Zuweisung. Der Standardwert ist {}.
exporter.tolerations: Tolerations für die Pod-Zuweisung. Der Standardwert ist [].
exporter.affinity: Knoten- oder Pod-Affinitäten. Der Standardwert ist {}.
exporter.topologySpreadConstraints: Einschränkungen, die festlegen, wie Pods über Ausfalldomänen wie Regionen oder Verfügbarkeitszonen verteilt werden. Der Standardwert ist [].
exporter.automountServiceAccountToken: Steuert, ob das serviceAccountToken gemountet werden soll. Der Standardwert ist false.
exporter.cacheDuration: Die Cache-Dauer für Informationen, die vom Exporter gesammelt werden. Der Standardwert ist 30.
exporter.cacheCleanInterval: Das Intervall zur Cache-Reinigung für Informationen, die vom Exporter gesammelt werden. Der Standardwert ist 14400.
exporter.priorityClassName: Die Prioritätsklasse, unter der der Pod ausgeführt werden soll. Der Standardwert ist undefined.

Metrikparameter #

metrics.enabled: Aktiviert Harbor Metriken. Der Standardwert ist false.
metrics.core.path: Der URL-Pfad für Kernelmetriken. Der Standardwert ist /metrics.
metrics.core.port: Der Port für Kernelmetriken. Der Standardwert ist 8001.
metrics.registry.path: Der URL-Pfad für Registrierungsmetriken. Der Standardwert ist /metrics.
metrics.registry.port: Der Port für Registrierungsmetriken. Der Standardwert ist 8001.
metrics.exporter.path: Der URL-Pfad für Exporter-Metriken. Der Standardwert ist /metrics.
metrics.exporter.port: Der Port für Exporter-Metriken. Der Standardwert ist 8001.
metrics.serviceMonitor.enabled: Aktiviert die Erstellung eines Prometheus ServiceMonitors (benötigt Prometheus CRDs). Der Standardwert ist false.
metrics.serviceMonitor.additionalLabels: Zusätzliche Labels, die auf das ServiceMonitor-Manifest angewendet werden sollen. Der Standardwert ist "".
metrics.serviceMonitor.interval: Das Abfrageintervall für Harbor Metriken. Der Standardwert ist "".
metrics.serviceMonitor.metricRelabelings: Die Relabeling-Regeln für Metriken vor der Eingabe. Der Standardwert ist [].
metrics.serviceMonitor.relabelings: Die Relabeling-Regeln für Metriken vor dem Scraping. Der Standardwert ist [].

Trace-Parameter #

trace.enabled: Aktiviert die Trace-Funktionalität. Der Standardwert ist false.
trace.provider: Der Trace-Anbieter (jaeger oder otel). Die Jaeger-Version sollte 1.26+ sein. Der Standardwert ist jaeger.
trace.sample_rate: Die Abtastrate für Trace-Daten. 1 samplet 100 %, 0.5 samplet 50 %. Der Standardwert ist 1.
trace.namespace: Der Namespace zur Unterscheidung verschiedener Harbor-Dienste.
trace.attributes: Ein Schlüssel-Wert-Wörterbuch für benutzerdefinierte Attribute bei der Initialisierung des Trace-Anbieters.
trace.jaeger.endpoint: Der Endpunkt für Jaeger-Tracing. Der Standardwert ist http://hostname:14268/api/traces.
trace.jaeger.username: Der Benutzername für die Jaeger-Authentifizierung.
trace.jaeger.password: Das Passwort für die Jaeger-Authentifizierung.
trace.jaeger.agent_host: Der Agenten-Host für Jaeger.
trace.jaeger.agent_port: Der Agenten-Port für Jaeger. Der Standardwert ist 6831.
trace.otel.endpoint: Der Endpunkt für OpenTelemetry-Tracing. Der Standardwert ist hostname:4318.
trace.otel.url_path: Der Pfad für OpenTelemetry. Der Standardwert ist /v1/traces.
trace.otel.compression: Aktiviert die Kompression für OpenTelemetry. Der Standardwert ist false.
trace.otel.insecure: Stellt eine unsichere Verbindung für OpenTelemetry her. Der Standardwert ist true.
trace.otel.timeout: Die Zeitüberschreitung in Sekunden für OpenTelemetry. Der Standardwert ist 10.

Cache-Parameter #

cache.enabled: Aktiviert die Cache-Schicht. Der Standardwert ist false.
cache.expireHours: Die Ablaufzeit in Stunden für die Cache-Schicht. Der Standardwert ist 24.

B Beispiel eines Private Registry HA setup Helm Diagramms #

Die folgende Beispielwerte-Datei veranschaulicht die Parameter, die für das minimale Private Registry HA setup erforderlich sind.

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	Hostname des Kernelservice in der Ingress Regel.
2	Die externe URL für den harbor-core Dienst.
3 4 5 6	Anzahl der zu erstellenden Replikate. Geben Sie zwei oder mehr an.
7	Füllen Sie die Datenbankverbindungsdetails im `external` Abschnitt aus.
8	Wenn ein vorhandenes Geheimnis verwendet wird, muss der Wert `password` sein.
9	Akzeptiert einen der folgenden Werte: Deaktivieren Verwenden Sie kein SSL. require Verwenden Sie immer SSL und überspringen Sie die Überprüfung. verify-ca Verwenden Sie immer SSL. Überprüfen Sie, ob das vom Server präsentierte Zertifikat von einer vertrauenswürdigen CA signiert wurde. verify-full Verwenden Sie immer SSL. Überprüfen Sie, ob das vom Server präsentierte Zertifikat von einer vertrauenswürdigen CA signiert wurde und der Hostname des Servers mit dem im Zertifikat übereinstimmt.
10	Füllen Sie die Verbindungsinformationen im `external` Abschnitt aus.
11	Unterstützt redis und redis+sentinel. Die Adresse für redis ist `<redis_host>:<redis_port>`. Die Adresse für redis+sentinel ist `<sentinel1_host>:<sentinel1_port>`,`<sentinel2_host>:<sentinel2_port>`…
12	Der Name der Menge von Valkey Instanzen, die überwacht werden sollen. Es muss so eingestellt werden, dass redis+sentinel unterstützt wird.
13	Muss `0` sein, da die von Harbor verwendete Bibliothek keine Konfigurationen unterstützt.
14	Optional. Standardmäßig auf `0` eingestellt, kann jedoch auf `6` konfiguriert werden.
15	Optional. Standardmäßig auf `0` eingestellt, kann jedoch auf `7` konfiguriert werden.
16	Wenn es leer ist, wird es gegen den Standardbenutzer authentifiziert.
17	Wenn verwendet, muss der Schlüssel <REDIS_PASSWORD> sein.
18	Um alle Bilder, Metadaten und Scans zu speichern, stellen Sie sicher, dass die persistenzbezogenen Einstellungen (Persistenzparameter) ordnungsgemäß konfiguriert sind.

C Freie GNU-Dokumentationslizenz (GNU Free Documentation License) #

Copyright © 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. Es ist jedermann gestattet, diese Lizenzurkunde zu vervielfältigen und unveränderte Kopien zu verbreiten; Änderungen sind jedoch nicht erlaubt.

C1 0. VORWORT #

Der Zweck dieser Lizenz ist es, eine Dokumentation (Handbuch etc.) zu ermöglichen, die funktional, hilfreich und frei ist: damit jede Person sie sowohl kommerziell als auch nicht-kommerziell kopieren, weiterverteilen und ändern darf. Weiterhin sichert diese Lizenz einem Autor oder Verleger die Möglichkeit, Anerkennung für seine Arbeit zu erhalten, ohne für Änderungen durch andere verantwortlich gemacht zu werden.

Diese Lizenz ist eine Art von "Copyleft", was bedeutet, dass von diesem Dokument abgeleitete Werke ihrerseits in derselben Weise frei sein müssen. Dies vervollständigt die GNU General Public License, eine „Copyleft“-Lizenz, die für freie Software entworfen wurde.

Wir haben diese Lizenz entwickelt, um sie für Handbücher für freie Software zu verwenden, da freie Software auch eine freie Dokumentation benötigt: Zu einem freien Programm gehören auch freie Handbücher, die dieselben Freiheiten wie die Software bieten. Diese Lizenz ist aber nicht auf Softwarehandbücher beschränkt; vielmehr kann sie für jede Art von Textwerk verwendet werden, unabhängig davon, was das Thema ist oder ob es als gedrucktes Buch veröffentlicht wurde. Wir empfehlen diese Lizenz prinzipiell für Werke, die als Anleitung oder Referenz dienen sollen.

C2 1. ANWENDBARKEIT UND DEFINITIONEN #

Diese Lizenz findet Anwendung auf jedes Handbuch oder andere Werk, unabhängig von dem Medium, auf dem es erscheint, das einen vom Rechteinhaber eingefügten Hinweis enthält, der besagt, dass das Werk unter den Bedingungen dieser Lizenz verbreitet werden darf. Ein solcher Hinweis gewährt eine weltweit gültige, tantiemenfreie und zeitlich unbefristete Lizenz, die es gestattet, das Werk unter den hier festgelegten Bedingungen zu nutzen. Der Begriff „Dokument“ wird im Folgenden für alle solche Handbücher und Werke verwendet. Jede Person kann Lizenznehmer sein und wird im Folgenden mit Sie angesprochen. Sie akzeptieren diese Lizenz, wenn Sie ein Dokument derart kopieren, verändern oder verteilen, dass Sie gemäß den Gesetzen zum Copyright die Erlaubnis benötigen.

Eine „modifizierte Version“ des Dokuments steht für jedes Werk, welches das Dokument als Ganzes oder in Teilen enthält, sowohl unverändert als auch mit Änderungen kopiert und/oder in andere Sprachen übersetzt.

Ein „zweitrangiger Abschnitt“ ist ein benannter Anhang oder ein Vorspannteil des Dokuments, der sich ausschließlich mit dem Verhältnis der Autoren bzw. Verleger des Dokuments zu dessen eigentlichem Thema (oder zu verwandten Angelegenheiten) befasst und nichts enthält, was unmittelbar zu diesem Thema gehört. (Wenn das Dokument beispielsweise ein Buch über Mathematik ist, dann darf ein zweitrangiger Abschnitt nichts über Mathematik enthalten). Bei diesem Verhältnis kann es sich um eine historische Beziehung zu dem Thema oder damit in Verbindung stehenden Inhalten oder um diesbezügliche gesetzliche, gesellschaftliche, philosophische, ethische oder politische Positionen handeln.

Die „unveränderlichen Abschnitte“ sind benannte zweitrangige Abschnitte, deren Titel als unveränderlicher Abschnitt in dem Lizenzhinweis, der das Dokument unter diese Lizenz stellt, aufgeführt sind. Wenn ein Abschnitt nicht in die oben stehende Definition eines zweitrangigen Abschnitts passt, darf er nicht als unveränderlich ausgewiesen werden. Das Dokument kann auch keine unveränderlichen Bereiche enthalten. Wenn das Dokument keine unveränderlichen Bereiche angibt, sind keine solchen darin enthalten.

„Umschlagtexte“ sind bestimmte kurze Textpassagen, die als vorderer Umschlagtext oder hinterer Umschlagtext in dem Hinweis aufgeführt sind, der besagt, dass das Dokument unter dieser Lizenz veröffentlicht wird. Ein vorderer Umschlagtext darf höchstens 5 Wörter enthalten, ein hinterer Umschlagtext höchstens 25 Wörter.

Eine „transparente“ Kopie des Dokuments ist eine maschinenlesbare Kopie in einem Format, dessen Spezifikation der Allgemeinheit zugänglich ist, das sich eignet, das Dokument unkompliziert mit allgemeinen Texteditoren oder (bei pixelbasierten Bildern) mit allgemeinen Bildbearbeitungsprogrammen oder (bei Zeichnungen) mit einem weit verbreiteten Zeichenprogramm zu bearbeiten und das sich als Eingabe für Textformatierer oder zur automatischen Umwandlung in verschiedene für Textformatierer geeignete Formate eignet. Eine Kopie in einem ansonsten transparenten Dateiformat, deren Auszeichnung oder das Fehlen derselben so gestaltet ist, dass nachfolgende Änderungen durch Leser verhindert oder erschwert werden, ist nicht transparent. Ein Bildformat ist nicht transparent, wenn es für eine wesentliche Menge von Text verwendet wird. Eine Kopie, die nicht „transparent“ ist, wird als „opak“ bezeichnet.

Beispiele verwendbarer Formate für transparente Kopien schließen einfachen ASCII-Text ohne Markup, das Texinfo-Eingabeformat, das LaTeX-Eingabeformat, SGML oder XML unter Nutzung einer öffentlich verfügbaren DTD sowie standardkonformes, einfaches HTML, PostScript oder PDF ein, die sich zur direkten Bearbeitung mit gängigen Texteditoren (bzw. bei pixelbasierten Bildern mit üblichen Bildbearbeitungsprogrammen oder bei Zeichnungen mit einem weit verbreiteten Zeichenprogramm) eignen. Beispiele für transparente Bildformate sind unter anderem PNG, XCF und JPG. Opake Formate sind unter anderem solche proprietären Formate, die nur von proprietären Textverarbeitungsprogrammen gelesen und bearbeitet werden können, SGML oder XML, deren DTD und/oder Verarbeitungswerkzeuge nicht allgemein verfügbar sind, und maschinengeneriertes HTML, PostScript oder PDF, das von manchen Textverarbeitungsprogrammen nur zu Ausgabezwecken erzeugt wird.

Mit „Titelseite“ werden bei einem gedruckten Buch die eigentliche Titelseite sowie die direkt darauf folgenden Seiten bezeichnet, die all das in lesbarer Form enthalten, was gemäß dieser Lizenz auf der Titelseite erscheinen muss. Für Werke, die in Formaten vorliegen, die keine Titelseiten haben, gilt als „Titelseite“ der Text, der direkt nach der auffälligsten Darstellung des Titels des Werks folgt, aber noch vor dem Inhalt des Werks steht.

Ein Abschnitt „Entitled XYZ“ bezeichnet einen benannten Unterabschnitt des Dokuments, dessen Titel entweder exakt XYZ lautet oder in Klammern den Zusatz XYZ enthält, nachdem ein erläuternder Text zu XYZ in einer anderen Sprache folgt. (Hier steht XYZ für einen bestimmten Abschnittsnamen, der unten erwähnt wird, wie „Danksagungen“, „Widmungen“, „Empfehlungen“ oder „Historie“.) Das Beibehalten des Titels eines solchen Abschnitts beim Ändern des Dokuments bedeutet, dass dieser weiterhin als Abschnitt „Entitled XYZ“ geführt wird, wie in dieser Definition festgelegt.

Das Dokument kann direkt hinter dem Hinweis, der besagt, dass das Dokument unter dieser Lizenz freigegeben ist, Haftungsausschlüsse enthalten. Diese Haftungsausschlüsse gelten als durch Verweisung in diese Lizenz eingeschlossen, jedoch ausschließlich im Hinblick auf den Ausschluss von Garantien – jede weitere Auslegung oder Implikation dieser Haftungsausschlüsse ist unwirksam und berührt die Bedeutung dieser Lizenz nicht.

C3 2. UNVERÄNDERTE KOPIEN #

Sie dürfen das Dokument auf jedem Medium sowohl kommerziell als auch nicht kommerziell kopieren und verbreiten, vorausgesetzt, dass diese Lizenz, die Copyright-Hinweise sowie der Hinweis auf die Lizenz, der besagt, dass diese Lizenz auf das Dokument anzuwenden ist, in allen Kopien reproduziert wird und dass keine weiteren Bedingungen jeglicher Art zu denen dieser Lizenz hinzugefügt werden. Sie dürfen in den Kopien, die Sie erstellen oder verbreiten, keinerlei technische Maßnahmen treffen, um das Lesen oder das weitere Kopieren zu erschweren oder zu kontrollieren. Dennoch dürfen Sie Gegenleistungen für Kopien akzeptieren. Wenn Sie eine ausreichend große Menge von Kopien verteilen, müssen Sie zusätzlich die Bestimmungen von Ziffer 3 beachten.

Sie können außerdem unter denselben Bedingungen, die oben angeführt sind, Kopien verleihen und Sie können Kopien auch öffentlich ausstellen.

C4 3. KOPIEN IN MENGEN #

Wenn Sie gedruckte Kopien des Dokuments (oder Kopien auf Medien, die üblicherweise gedruckte Umschläge haben), in einer Stückzahl von mehr als 100 veröffentlichen und der Lizenzhinweis des Dokuments Umschlagtexte verlangt, müssen die Kopien in Hüllen verpackt sein, die alle diese Umschlagtexte klar und lesbar enthalten: Die vorderen Umschlagtexte auf dem vorderen Umschlag und die hinteren Umschlagtexte auf dem hinteren Umschlag. Beide Umschläge müssen Sie außerdem klar und lesbar als den Herausgeber dieser Kopien benennen. Der vordere Umschlag muss den gesamten Titel darstellen, mit allen Worten gleich auffällig und sichtbar. Sie können weiteres Material den Umschlägen hinzufügen. Das Kopieren mit Änderungen, die auf Umschläge begrenzt sind, kann, solange der Titel des Dokuments erhalten bleibt und diese Bedingungen erfüllt sind, in anderen Aspekten als unverändertes Kopieren behandelt werden.

Wenn der vorgeschriebene Text für einen der Umschläge zu umfangreich ist, um lesbar zu bleiben, sollten Sie den ersten der aufgelisteten Texte auf den aktuellen Umschlag nehmen (so viel wie vernünftigerweise möglich ist) und den Rest auf direkt angrenzende Seiten fortsetzen.

Wenn Sie mehr als 100 opake Kopien des Dokuments veröffentlichen oder verbreiten, müssen Sie entweder eine maschinenlesbare, transparente Kopie jeder opaken Kopie beilegen oder mit bzw. in jeder opaken Kopie eine Computer-Netzwerk-Adresse angeben, von wo die allgemeine, netzwerkbenutzende Öffentlichkeit Zugriff zum Download einer kompletten transparenten Kopie über öffentliche Standardnetzwerkprotokolle hat, die frei von zusätzlichen Materialien ist. Wenn Sie sich für die letztere Möglichkeit entscheiden, müssen Sie mit Beginn der Verbreitung der opaken Kopien in Stückzahlen zumutbare und vernünftige Schritte unternehmen, um sicherzustellen, dass die transparente Kopie mindestens ein Jahr nach der letzten Verbreitung einer opaken Kopie (direkt oder über Ihre Agenten oder Händler) dieser Ausgabe an die Öffentlichkeit an der genannten Adresse verfügbar bleibt.

Es wird gebeten, aber nicht verlangt, dass Sie die Autoren des Dokuments rechtzeitig kontaktieren, bevor Sie eine größere Anzahl von Kopien verbreiten, um ihnen die Gelegenheit zu geben, Ihnen eine aktualisierte Version des Dokuments zur Verfügung zu stellen.

C5 4. MODIFIKATIONEN #

Unter den obigen Bedingungen unter Ziffer 2 und 3 können Sie modifizierte Versionen kopieren und verbreiten, vorausgesetzt, dass Sie die modifizierte Version unter exakt dieser Lizenz herausgeben, wobei die modifizierte Version die Rolle des Dokuments einnimmt, und dadurch die weitere Modifikation und Verbreitung an jeden lizenzieren, der eine Kopie davon besitzt. Zusätzlich müssen Sie die folgenden Dinge in der modifizierten Version beachten:

Benutzen Sie auf der Titelseite (und auf Umschlägen, sofern vorhanden) einen Titel, der sich von dem Titel des Dokuments und von früheren Versionen unterscheidet (die früheren Versionen sollten, wenn es welche gibt, im Abschnitt Historie aufgelistet werden). Sie können denselben Titel wie den einer Vorgängerversion verwenden, wenn der ursprüngliche Herausgeber damit einverstanden ist.
Geben Sie auf der Titelseite als Autoren eine oder mehrere Personen oder Einheiten an, die für die Urheberschaft der Änderungen in der modifizierten Version verantwortlich sind, zusammen mit mindestens fünf der hauptverantwortlichen Autoren des Dokuments (bzw. allen, falls es weniger als fünf gibt), sofern diese Sie nicht von dieser Vorgabe entbinden.
Geben Sie auf der Titelseite den Namen des Herausgebers der modifizierten Version als Herausgeber an.
Erhalten Sie alle Copyright-Vermerke des Dokuments.
Setzen Sie einen passenden Copyright-Hinweis für Ihre Modifikationen direkt hinter die anderen Copyright-Hinweise.
Schließen Sie direkt hinter den Copyright-Vermerken einen Lizenzhinweis ein, der die öffentliche Erlaubnis erteilt, die modifizierte Version unter den Bedingungen dieser Lizenz zu benutzen, wie es im Anhang weiter unten beschrieben ist.
Erhalten Sie im Lizenzvermerk die vollständigen Listen der unveränderlichen Abschnitte und der erforderlichen Umschlagtexte, die im Lizenzvermerk des Dokuments angegeben sind.
Schließen Sie eine unveränderte Kopie dieser Lizenz mit ein.
Behalten Sie den Abschnitt mit dem Titel "Historie" bei, bewahren Sie seinen Titel und fügen Sie einen Punkt hinzu, der mindestens den Titel, das Jahr, die neuen Autoren und den Herausgeber der modifizierten Version, wie auf der Titelseite angegeben, enthält. Wenn es im Dokument keinen Abschnitt mit dem Titel "Historie" gibt, erstellen Sie einen der den Titel, das Jahr, die Autoren und den Herausgeber des Dokuments, wie auf der Titelseite angegeben, enthält, und fügen Sie einen Eintrag hinzu, der die modifizierte Version, wie im vorherigen Satz angegeben, beschreibt.
Erhalten Sie die Netzwerkadresse, die im Dokument angegeben ist, um öffentlichen Zugang zu einer transparenten Kopie des Dokuments zu gewähren, sowie die Netzwerkadressen, die im Dokument für frühere Versionen angegeben sind, auf denen es basiert. Diese Angaben können in den Abschnitt „Historie“ verschoben werden. Sie können eine Netzwerkadresse für ein Werk weglassen, das mindestens vier Jahre vor dem Dokument selbst veröffentlicht wurde, oder wenn der ursprüngliche Herausgeber der Version, auf die verwiesen wird, seine Erlaubnis erteilt.
Für jeden Abschnitt mit dem Titel "Danksagungen" oder "Widmungen" bewahren Sie den Titel des Abschnitts und die Substanz sowie den Ton aller Danksagungen und/oder Widmungen der Beitragenden, die darin gegeben sind.
Erhalten Sie alle unveränderlichen Abschnitte des Dokuments unverändert in ihrem Text und ihren Titeln. Abschnittsnummern oder deren Äquivalente gelten nicht als Teil der Abschnittstitel.
Löschen Sie alle Abschnitte, die mit „Anmerkungen“ überschrieben sind. Ein solcher Abschnitt darf nicht in der modifizierten Version enthalten sein.
Benennen Sie keinen bestehenden Abschnitt in "Empfehlungen" um oder in einen Titel, der mit einem unveränderlichen Abschnitt in Konflikt steht.
Erhalten Sie alle Garantieausschlüsse.

Wenn die modifizierte Version neue Vorspannabschnitte oder Anhänge enthält, die als sekundäre Abschnitte qualifiziert sind und kein Material aus dem Dokument beinhalten, können Sie nach eigenem Ermessen einige oder alle dieser Abschnitte als unveränderlich festlegen. Fügen Sie dazu ihre Titel zur Liste der unveränderlichen Abschnitte im Lizenzvermerk der modifizierten Version hinzu. Diese Titel müssen sich von allen anderen Abschnittstiteln unterscheiden.

Sie können einen Abschnitt mit dem Titel "Empfehlungen" hinzufügen, vorausgesetzt, er enthält nichts außer Empfehlungen Ihrer modifizierten Version von verschiedenen Parteien-- – zum Beispiel Erklärungen zum Peer-Review oder dass der Text von einer Organisation als maßgebliche Definition eines Standards genehmigt wurde.

Sie können einen Text von bis zu fünf Wörtern als vorderen Umschlagtext und einen Text von bis zu 25 Wörtern als hinteren Umschlagtext an das Ende der Liste der Umschlagtexte in der modifizierten Version hinzufügen. Nur ein Text für den vorderen Umschlag und einer für den hinteren Umschlag dürfen von (oder durch Vereinbarungen getroffen von) einer einzigen Einheit hinzugefügt werden. Wenn das Dokument bereits einen Umschlagtext für denselben Umschlag enthält, der von Ihnen oder durch eine Vereinbarung, die von der gleichen Einheit getroffen wurde, in deren Namen Sie handeln, hinzugefügt wurde, dürfen Sie keinen weiteren hinzufügen; Sie können jedoch den alten ersetzen, wenn Sie die ausdrückliche Genehmigung des vorherigen Herausgebers haben, der den alten hinzugefügt hat.

Die Autor(en) und Herausgeber des Dokuments geben durch diese Lizenz keine Erlaubnis, ihre Namen für Werbung oder zur Behauptung oder Andeutung der Unterstützung einer modifizierten Version zu verwenden.

C6 5. KOMBINIEREN VON DOKUMENTEN #

Sie können das Dokument mit anderen Dokumenten kombinieren, die unter dieser Lizenz veröffentlicht wurden, gemäß den in Abschnitt 4 oben für modifizierte Versionen definierten Bedingungen, vorausgesetzt, dass Sie in der Kombination alle unveränderlichen Abschnitte aller Originaldokumente unverändert einbeziehen und sie alle als unveränderliche Abschnitte Ihres kombinierten Werks in dessen Lizenzvermerk auflisten und dass Sie alle ihre Haftungsausschlüsse bewahren.

Das kombinierte Werk muss nur eine Kopie dieser Lizenz enthalten, und mehrere identische unveränderliche Abschnitte können durch eine einzelne Kopie ersetzt werden. Wenn es mehrere unveränderliche Abschnitte mit dem gleichen Namen, aber unterschiedlichen Inhalten gibt, machen Sie den Titel jedes solchen Abschnitts eindeutig, indem Sie am Ende in Klammern den Namen des ursprünglichen Autors oder Herausgebers dieses Abschnitts, falls bekannt, oder andernfalls eine eindeutige Nummer hinzufügen. Machen Sie dieselbe Anpassung an den Abschnittstiteln in der Liste der unveränderlichen Abschnitte im Lizenzhinweis des kombinierten Werks.

In der Kombination müssen Sie alle Abschnitte mit dem Titel "Historie" in den verschiedenen Originaldokumenten zu einem Abschnitt mit dem Titel "Historie" zusammenfassen; ebenso müssen Sie alle Abschnitte mit dem Titel "Danksagungen" und alle Abschnitte mit dem Titel "Widmungen" zusammenfassen. Sie müssen alle Abschnitte mit dem Titel „Anmerkungen“ löschen.

C7 6. SAMMLUNGEN VON DOKUMENTEN #

Sie können eine Sammlung erstellen, die aus dem Dokument und anderen unter dieser Lizenz veröffentlichten Dokumenten besteht, und die einzelnen Kopien dieser Lizenz in den verschiedenen Dokumenten durch eine einzige Kopie ersetzen, die in der Sammlung enthalten ist, vorausgesetzt, Sie befolgen die Regeln dieser Lizenz für die wörtliche Kopie jedes der Dokumente in allen anderen Aspekten.

Sie können ein einzelnes Dokument aus einer solchen Sammlung entnehmen und es einzeln unter dieser Lizenz verbreiten, vorausgesetzt, Sie fügen eine Kopie dieser Lizenz in das extrahierte Dokument ein und befolgen diese Lizenz in allen anderen Aspekten bezüglich der wörtlichen Kopie dieses Dokuments.

C8 7. AGGREGATION MIT UNABHÄNGIGEN WERKEN #

Eine Zusammenstellung des Dokuments oder seiner Ableitungen mit anderen separaten und unabhängigen Dokumenten oder Werken auf einem Datenträger oder Verbreitungsmedium wird als "Sammlung" bezeichnet, wenn das aus der Zusammenstellung resultierende Urheberrecht nicht verwendet wird, um die gesetzlichen Rechte der Benutzer der Zusammenstellung über das hinaus einzuschränken, was die einzelnen Werke erlauben. Wenn das Dokument in einer Sammlung enthalten ist, gilt diese Lizenz nicht für die anderen Werke in der Sammlung, die selbst keine Ableitungen des Dokuments sind.

Wenn die Anforderungen an die Umschlagtexte aus Abschnitt 3 auf diese Kopien des Dokuments anwendbar sind, und wenn das Dokument weniger als die Hälfte der gesamten Aggregation ausmacht, können die Umschlagtexte des Dokuments auf Umschlägen platziert werden, die das Dokument innerhalb der Aggregation umschließen, oder auf das elektronische Äquivalent von Umschlägen, wenn das Dokument in elektronischer Form vorliegt. Andernfalls müssen sie auf gedruckten Umschlägen erscheinen, die die gesamte Sammlung umschließen.

C9 8. ÜBERSETZUNG #

Übersetzung wird als eine Art Modifikation betrachtet, sodass Sie Übersetzungen des Dokuments unter den Bedingungen von Abschnitt 4 verbreiten dürfen. Das Ersetzen unveränderlicher Abschnitte durch Übersetzungen erfordert eine besondere Genehmigung der Urheberrechtsinhaber, aber Sie können Übersetzungen einiger oder aller unveränderlichen Abschnitte zusätzlich zu den Originalversionen dieser unveränderlichen Abschnitte einfügen. Sie können eine Übersetzung dieser Lizenz und aller Lizenzhinweise im Dokument sowie aller Garantieausschlüsse hinzufügen, vorausgesetzt, dass Sie auch die originale englische Version dieser Lizenz und die originalen Versionen dieser Hinweise und Ausschlüsse beifügen. Im Falle eines Konflikts zwischen der Übersetzung und der Originalversion dieser Lizenz oder eines Hinweises oder Ausschlusses hat die Originalversion Vorrang.

Wenn ein Abschnitt im Dokument mit "Danksagungen", "Widmungen" oder "Historie" überschrieben ist, erfordert die Anforderung (Abschnitt 4), den Titel zu bewahren (Abschnitt 1), typischerweise eine Änderung des tatsächlichen Titels.

C10 9. ABSCHLUSSBESTIMMUNGEN #

Sie dürfen das Dokument nicht kopieren, ändern, unterlizenzieren oder verteilen, es sei denn, dies ist ausdrücklich unter dieser Lizenz vorgesehen. Jeder andere Versuch, das Dokument zu kopieren, zu ändern, weiterzulizenzieren oder zu verbreiten, ist ungültig und führt automatisch zum Verlust Ihrer Rechte unter dieser Lizenz. Personen, die von Ihnen gemäß dieser Lizenz Kopien oder Rechte erhalten haben, verlieren ihre Lizenz jedoch nicht, solange sie die Bestimmungen vollständig einhalten.

C11 1. SPÄTERE ÜBERARBEITUNGEN DIESER LIZENZ #

Die Free Software Foundation kann von Zeit zu Zeit neue, überarbeitete Versionen der GNU Freien Dokumentationslizenz veröffentlichen. Solche neuen Versionen werden im Geist der vorliegenden Version ähnlich sein, können sich jedoch in Details unterscheiden, um neuen Problemen oder Bedenken gerecht zu werden. Siehe https://www.gnu.org/copyleft/.

Jede Version dieser Lizenz erhält eine eigene Versionsnummer. Wenn das Dokument angibt, dass eine bestimmte nummerierte Version dieser Lizenz "oder eine spätere Version" darauf anwendbar ist, haben Sie die Wahl, entweder den Bedingungen dieser angegebenen Version oder den Bedingungen jeder späteren Version zu folgen, die von der Free Software Foundation veröffentlicht wurde (nicht als Entwurf). Wenn das Dokument keine Versionsnummer angibt, können Sie jede Version auswählen, die jemals (nicht als Entwurf) von der Free Software Foundation veröffentlicht wurde.

C12 ANHANG: Wie Sie diese Lizenz für Ihre Dokumente verwenden können #

  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".

Wenn Sie unveränderliche Abschnitte, Front-Cover-Texte und Back-Cover-Texte haben, ersetzen Sie die Zeile „with…Texts.“ durch die folgende:

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

Wenn Sie unveränderliche Abschnitte ohne Umschlagtexte oder eine andere Kombination der drei haben, kombinieren Sie diese beiden Alternativen, um der Situation gerecht zu werden.

Wenn Ihr Dokument nicht-triviale Beispiele von Programmcode enthält, empfehlen wir, diese Beispiele parallel unter einer freien Softwarelizenz Ihrer Wahl – zum Beispiel der GNU General Public License – zu veröffentlichen, um deren Nutzung in freier Software zu ermöglichen.