Zugriffssteuerung mit IAM

Auf dieser Seite wird die Zugriffssteuerung mit Identity and Access Management (IAM) in Artifact Registry beschrieben.

Standardberechtigungen für Artifact Registry minimieren den Einrichtungsaufwand bei der Implementierung einer CI/CD-Pipeline. Sie können Artifact Registry auch in CI/CD-Tools von Drittanbietern einbinden und die Berechtigungen und die Authentifizierung konfigurieren, die für den Zugriff auf Repositories erforderlich sind.

Wenn Sie die Artefaktanalyse verwenden, um mit Containermetadaten wie z. B. in Images gefundenen Sicherheitslücken zu arbeiten, finden Sie in der Dokumentation zur Artefaktanalyse Informationen dazu, wie Sie Zugriff zum Aufrufen oder Verwalten von Metadaten gewähren.

Hinweise

1. Artifact Registry aktivieren, einschließlich der API und der Google Cloud CLI.
2. Wenn Sie Repository-spezifische Berechtigungen anwenden möchten, erstellen Sie ein Artifact Registry-Repository für Ihre Pakete.

Überblick

IAM-Berechtigungen und Rollen bestimmen, ob Sie Daten in einem Artifact Registry-Repository erstellen, ansehen, bearbeiten oder löschen können.

Eine Rolle ist eine Sammlung von Berechtigungen. Sie können einem Hauptkonto Berechtigungen nicht direkt erteilen. Stattdessen weisen Sie ihm eine Rolle zu. Wenn Sie einem Hauptkonto eine Rolle zuweisen, erhält er alle mit ihr verknüpften Berechtigungen. Einem Hauptkonto können mehrere Rollen zugewiesen werden.

Google Cloud-Standardberechtigungen

Standardmäßig gelten die folgenden Berechtigungen für Google Cloud CI/CD-Dienste im selben Projekt wie Artifact Registry:

• Cloud Build-Berechtigungen umfassen Berechtigungen zum Hochladen und Herunterladen von Artefakten.
• Compute Engine, unterstützte Google Kubernetes Engine-Versionen und Cloud Run verwenden das Standarddienstkonto von Compute Engine mit Lesezugriff.

Wenn sich alle Dienste im selben Google Cloud-Projekt befinden und die Standardberechtigungen Ihren Anforderungen entsprechen, müssen Sie keine Berechtigungen konfigurieren.

Sie müssen Artifact Registry-Berechtigungen für diese Dienste konfigurieren, wenn:

• Sie mit diesen Diensten auf Artifact Registry in einem anderen Projekt zugreifen möchten. Im Projekt mit Artifact Registry weisen Sie dem Workload Identity-Pool oder dem Dienstkonto für jeden Dienst die erforderliche Rolle zu. Wenn Sie eine Verbindung zu Cloud Run herstellen, gewähren Sie dem Cloud Run-Dienst-Agent die erforderliche Rolle.
• Sie eine GKE-Version verwenden, die das Abrufen von Images aus Artifact Registry nicht unterstützt. Konfigurationsanleitungen finden Sie im Abschnitt GKE.
• Sie möchten, dass das Standarddienstkonto Lese- und Schreibzugriff auf Repositories hat. Weitere Informationen finden Sie hier:
  • Compute Engine
  • GKE
• Sie verwenden ein vom Nutzer bereitgestelltes Dienstkonto für Ihre Laufzeitumgebungen anstelle des Standarddienstkontos. Weisen Sie Ihrem Dienstkonto im Projekt mit Artifact Registry die erforderliche Rolle zu.

Drittanbieter einbinden

Für Drittanbieter-Clients müssen Sie sowohl Berechtigungen als auch die Authentifizierung konfigurieren.

Traditionell verwenden Anwendungen, die außerhalb von Google Cloud ausgeführt werden, für den Zugriff auf Google Cloud-Ressourcen Dienstkontoschlüssel. Dienstkontoschlüssel sind jedoch leistungsstarke Anmeldedaten und können ein Sicherheitsrisiko darstellen, wenn sie nicht ordnungsgemäß verwaltet werden.

Mit der Identitätsföderation von Arbeitslasten können Sie externen Identitäten mithilfe der Identity and Access Management IAM-Rollen zuweisen, einschließlich der Möglichkeit, die Identität von Dienstkonten zu übernehmen. Dieser Ansatz eliminiert den mit Dienstkontoschlüsseln verbundenen Wartungs- und Sicherheitsaufwand.

Workload Identity-Föderation verwenden:

1. Erstellen Sie einen Workload Identity-Föderationspool.
2. Anbieter der Identitätsföderation von Arbeitslasten erstellen
3. Gewähren Sie dem Workload Identity-Pool die entsprechende Artifact Registry-Rolle, um den Zugriff auf das Repository zu ermöglichen.

4. Konfigurieren Sie den Drittanbieterclient für die Authentifizierung bei Artifact Registry.

   • Container-Images: Docker, Helm
   • Sprachpakete: Java, Node.js, Python, Go
   • Betriebssystempakete: Debian, RPM
   • Sonstiges: Kubeflow-Pipeline-Vorlagen

Verwenden Sie ein Dienstkonto:

1. Erstellen Sie ein Dienstkonto, das für Ihre Anwendung agiert, oder wählen Sie ein vorhandenes Dienstkonto für die CI-/CD-Automatisierung aus.
2. Gewähren Sie dem Dienstkonto die entsprechende Artifact Registry-Rolle, um den Zugriff auf das Repository zu ermöglichen.

3. Konfigurieren Sie den Drittanbieterclient für die Authentifizierung bei Artifact Registry.

   • Container-Images: Docker, Helm
   • Sprachpakete: Java, Node.js, Python, Go
   • Betriebssystempakete: Debian, RPM
   • Sonstiges: Kubeflow-Pipeline-Vorlagen

GitLab in Google Cloud

Die Integration von GitLab in Google Cloud verwendet die Identitätsföderation von Arbeitslasten zur Autorisierung und Authentifizierung für GitLab-Arbeitslasten in Google Cloud. Dabei sind keine Dienstkonten oder Dienstkontoschlüssel erforderlich. Weitere Informationen zur Verwendung der Workload Identity-Föderation in dieser Partnerschaft finden Sie unter Authentifizierung.

Informationen zum Einrichten der Identitätsföderation von Arbeitslasten und der erforderlichen IAM-Rollen für GitLab in Google Cloud finden Sie in der GitLab-Anleitung Google Cloud Workload Identity-Föderation und IAM-Richtlinien.

Folgen Sie der GitLab-Anleitung Google Artifact Registry, um eine Verbindung zu Ihrem Artifact Registry-Repository herzustellen.

Rollen und Berechtigungen

Für jede Artifact Registry API-Methode muss das Hauptkonto (Nutzer, Gruppe oder Dienstkonto), das die Anfrage stellt, die erforderlichen Berechtigungen zur Verwendung der Ressource haben. Berechtigungen werden Hauptkonten durch Festlegen von Richtlinien erteilt, die dem Hauptkonto eine vordefinierte Rolle für die Ressource gewähren.

Sie können Rollen für das Google Cloud-Projekt oder das Artifact Registry-Repository zuweisen.

Vordefinierte Artifact Registry-Rollen

IAM bietet vordefinierte Rollen für den Zugriff auf bestimmte Google Cloud-Ressourcen. Mit diesen Rollen wird der unbefugte Zugriff auf andere Ressourcen verhindert.

Verwenden Sie die folgenden vordefinierten Rollen für Standard-, virtuelle und Remote-Repositories in der Domain pkg.dev:

Die folgenden zusätzlichen vordefinierten Rollen enthalten Berechtigungen zum Erstellen von gcr.io-Repositories zum Hosten von Images für die Domain gcr.io. Die Rollen beinhalten keine Berechtigungen zum Erstellen anderer Repository-Formate in Artifact Registry in der Domain pkg.dev. Diese Rollen unterstützen die Abwärtskompatibilität mit Container Registry, da Container Registry die erste Übertragung eines Container-Images verwendet, um jede multiregionale Registry zu erstellen.

Eine vollständige Liste der einzelnen Berechtigungen in jeder Rolle finden Sie unter Artifact Registry-Rollen. Sie können auch den Befehl gcloud iam roles describe verwenden, um eine Liste der Berechtigungen in jeder Rolle aufzurufen.

Einfache IAM-Rollen

Einfache Rollen sind Rollen mit hoher Berechtigung, die es schon vor der Einführung von IAM gab. Mit einfachen Rollen können Sie Hauptkonten umfassenden Zugriff auf Google Cloud-Ressourcen gewähren.

Verwenden Sie nach Möglichkeit vordefinierte Rollen für den Zugriff auf Repositories, damit Nutzer und Dienstkonten nur die erforderlichen Berechtigungen haben.

Weitere Informationen zu einfachen Rollen finden Sie in der Referenz zu einfachen und vordefinierten IAM-Rollen.

Berechtigungen gewähren

Berechtigungen auf Projektebene gewähren, wenn für alle Repositories im Projekt dieselben Berechtigungen gelten. Wenn für einige Konten unterschiedliche Zugriffsebenen erforderlich sind, erteilen Sie Rollen auf Repository-Ebene.

Wenn Sie Berechtigungen für ein virtuelles Repository gewähren, gelten diese Berechtigungen unabhängig von den einzelnen Repository-Berechtigungen für alle vorgelagerten Repositories, die über das virtuelle Repository verfügbar sind.

Wenn Sie Rollen mit dem Befehl gcloud zuweisen, können Sie eine einzelne Rollenbindung für ein Hauptkonto angeben oder eine Richtliniendatei verwenden, um mehrere Bindungen zu definieren.

Projektweite Berechtigungen gewähren

Sie weisen eine Rolle auf Projektebene zu, wenn für alle Repositories im Projekt dieselben Berechtigungen gelten.

So fügen Sie einem Projekt einen Nutzer oder ein Dienstkonto hinzu und gewähren ihm eine Artifact Registry-Rolle:

Repository-spezifische Berechtigungen erteilen

Berechtigungen auf Repository-Ebene gewähren Sie, wenn Sie Nutzern oder Dienstkonten für jedes Repository in Ihrem Projekt unterschiedliche Zugriffsrechte gewähren möchten.

provider "google" {
    project = "PROJECT-ID"
}

resource "google_artifact_registry_repository" "my-repo"     {
  provider = google-beta

  location = "LOCATION"
  repository_id = "REPOSITORY"
  description = "DESCRIPTION"
  format = "FORMAT"
}

resource "google_service_account" "repo-account" {
  provider = google-beta

  account_id   = "ACCOUNT-ID"
  display_name = "Repository Service Account"
}

resource "google_artifact_registry_repository_iam_member" "repo-iam" {
  provider = google-beta

  location = google_artifact_registry_repository.my-repo.location
  repository = google_artifact_registry_repository.my-repo.name
  role   = "roles/artifactregistry.reader"
  member = "serviceAccount:${google_service_account.repo-account.email}"
}

Öffentlichen Zugriff auf ein Repository konfigurieren

Wenn Sie Artefakte haben, die allen Nutzern im Internet ohne Authentifizierung zugänglich gemacht werden sollen, speichern Sie diese in einem von Ihnen veröffentlichten Repository.

Gewähren Sie dem Hauptkonto allUsers die Rolle „Artifact Registry-Leser“, um ein Repository für den öffentlichen Lesezugriff zu konfigurieren. Außerdem empfehlen wir, Kontingente für Nutzeranfragen zu begrenzen, damit ein einzelner Nutzer das Gesamtkontingent des Projekts nicht aufbrauchen kann.

Berechtigungen aufheben

Wenn Sie den Zugriff auf ein Repository widerrufen möchten, entfernen Sie das Hauptkonto aus der Liste der autorisierten Hauptkonten.

Entfernen Sie das allUsers-Hauptkonto, um den öffentlichen Zugriff auf ein Repository zu entfernen.

Bedingten Zugriff mit Tags gewähren

Projektadministratoren können Tags für Ressourcen in Google Cloud erstellen und diese in Resource Manager verwalten. Wenn Sie ein Tag an ein Artifact Registry-Repository anhängen, können Administratoren das Tag mit IAM-Bedingungen verwenden, um bedingten Zugriff auf das Repository zu gewähren.

Sie können keine Tags an einzelne Artefakte anhängen.

Weitere Informationen finden Sie in der folgenden Dokumentation:

• Administratoren, die Tags und die Zugriffssteuerung einrichten
  • Tags erstellen und verwalten
  • Tags und Zugriffssteuerung:
• Entwickler, die Tags an Repositories anhängen
  • Tagging-Repositories

In Google Cloud-Dienste einbinden

Für die meisten Google Cloud-Dienstkonten müssen für die Konfiguration des Zugriffs auf eine Registry nur die entsprechenden IAM-Berechtigungen erteilt werden.

Standardberechtigungen für Google Cloud-Dienste

Google Cloud-Dienste wie Cloud Build oder Google Kubernetes Engine verwenden ein Standarddienstkonto oder einen Dienst-Agent, um mit Ressourcen innerhalb desselben Projekts zu interagieren.

In folgenden Fällen müssen Sie Berechtigungen selbst konfigurieren oder ändern:

• Der Google Cloud-Dienst befindet sich in einem anderen Projekt als Artifact Registry.
• Die Standardberechtigungen erfüllen Ihre Anforderungen nicht. Beispielsweise hat das Compute Engine-Standarddienstkonto schreibgeschützten Zugriff auf den Speicher im selben Projekt. Wenn Sie ein Image von einer VM in Artifact Registry hochladen möchten, können Sie die Berechtigungen für das VM-Dienstkonto ändern oder ein anderes Konto mit den erforderlichen Berechtigungen verwenden.
• Sie verwenden ein vom Nutzer bereitgestelltes Dienstkonto anstelle des Standarddienstkontos, um mit Artifact Registry zu interagieren.

Die folgenden Dienstkonten greifen normalerweise auf Artifact Registry zu. Die E-Mail-Adresse für das Dienstkonto enthält die Google Cloud-Projekt-ID oder Projektnummer des Projekts, in dem der Dienst ausgeführt wird.

Zugriff auf Compute Engine-Instanzen gewähren

Für VM-Instanzen, die auf Repositories zugreifen, müssen sowohl die Artifact Registry-Berechtigungen als auch der Zugriffsbereich konfiguriert sein.

Während die Zugriffsebene eines Dienstkontos durch die IAM-Rollen bestimmt wird, die dem Dienstkonto zugewiesen sind, bestimmen die Zugriffsbereiche auf einer VM-Instanz die standardmäßigen OAuth-Bereiche für Anfragen, die über die gcloud CLI und Clientbibliotheken auf der Instanz erfolgen. Dies hat zur Folge, dass Zugriffsbereiche bei der Authentifizierung mit Standardanmeldedaten für Anwendungen möglicherweise den Zugriff auf API-Methoden weiter einschränken.

Compute Engine verwendet die folgenden Standardeinstellungen:

• Das Compute Engine-Standarddienstkonto ist die Identität für VM-Instanzen. Die E-Mail-Adresse des Dienstkontos hat das Suffix @developer.gserviceaccount.com.
• Das Standarddienstkonto hat die einfache IAM-Rolle „Bearbeiter“, wenn Sie dieses Verhalten nicht deaktiviert haben.
• Instanzen, die Sie mit dem Standarddienstkonto erstellen, haben die Compute Engine-Standardzugriffsbereiche, einschließlich Lesezugriff auf den Speicher. Während die Rolle „Bearbeiter“ im Allgemeinen Schreibzugriff gewährt, beschränkt der Speicherzugriffsbereich read-only das Dienstkonto der Instanz so, dass nur Artefakte aus einem beliebigen Repository im selben Projekt heruntergeladen werden.

Sie müssen den Zugriffsbereich des Dienstkontos in folgenden Fällen konfigurieren:

• Das VM-Dienstkonto muss auf ein Repository in einem anderen Projekt zugreifen.
• Das VM-Dienstkonto muss neben dem Lesen von Artefakten aus Repositories weitere Aktionen ausführen. Dies wendet in der Regel Drittanbietertools auf einer VM an, die Images übertragen oder die Artifact Registry-Befehle gcloud ausführen muss.

So konfigurieren Sie Berechtigungen und legen den Zugriffsbereich fest:

1. Rufen Sie im Projekt mit Ihrer VM-Instanz den Namen des Compute Engine-Standarddienstkontos ab. Die E-Mail-Adresse des Dienstkontos hat das Suffix @developer.gserviceaccount.com.

2. Weisen Sie dem Projekt mit dem Repository die Berechtigungen zu, damit das Dienstkonto auf das Repository zugreifen kann.

3. Legen Sie den Zugriffsbereich mit der Option --scopes fest.

   1. Stoppen Sie die VM-Instanz. Siehe Instanz beenden.

   2. Ändern Sie den Zugriffsbereich mit dem folgenden Befehl.

      gcloud compute instances set-service-account INSTANCE --scopes=SCOPE
      

      Ersetzen Sie SCOPE durch den entsprechenden Wert.

      • Für Docker werden die folgenden Optionen unterstützt:

        • storage-ro – Gewährt Lesezugriff für das Abrufen von Images.
        • storage-rw – Gewährt Lese- und Schreibberechtigung für das Hoch- und Herunterladen von Images.
        • cloud-platform – Anzeige und Verwaltung von Daten einschließlich Metadaten in allen Google Cloud-Diensten

      • Verwenden Sie für andere Formate den Bereich cloud-platform.

   3. Starten Sie die VM-Instanz neu. Siehe Beendete Instanz starten.

Zugriff auf Google Kubernetes Engine-Cluster gewähren

GKE-Cluster und Knotenpools können Container ohne zusätzliche Konfiguration abrufen, wenn die folgenden Anforderungen erfüllt sind:

• GKE befindet sich im selben Projekt wie Artifact Registry
• Knoten verwenden das Standarddienstkonto, also das Compute Engine-Standarddienstkonto.
• So wurden Knoten mit Lesezugriff auf den Speicher erstellt:
  • Über die Standardzugriffsbereiche von Compute Engine.
  • Gewähren des Zugriffsbereichs cloud-platform oder eines anderen Bereichs, der Lesezugriff auf den Speicher umfasst.
• Sie verwenden eine unterstützte Version von GKE.

Wenn Ihre GKE-Umgebung diese Anforderungen nicht erfüllt, hängt die Anleitung zum Gewähren des Zugriffs davon ab, ob Sie das Compute Engine-Standarddienstkonto oder ein vom Nutzer bereitgestelltes Dienstkonto als Identität für Ihre Knoten verwenden.

Standarddienstkonto

Die folgenden Konfigurationsanforderungen gelten für das Compute Engine-Standarddienstkonto:

1. Wenn sich GKE in einem anderen Projekt als Artifact Registry befindet, erteilen Sie dem Dienstkonto die erforderlichen Berechtigungen.

2. Wenn Sie Images übertragen, mit Repositories für andere Formate als Container interagieren oder gcloud-Befehle über Ihren Cluster ausführen möchten, müssen Sie beim Erstellen des Clusters oder Knotenpools Zugriffsbereiche für das Dienstkonto festlegen.

3. Wenn Sie keine unterstützte Version von GKE verwenden, konfigurieren Sie imagePullSecrets.

Vom Nutzer bereitgestelltes Dienstkonto

Wenn Sie ein vom Nutzer bereitgestelltes Dienstkonto als Identität für einen Cluster verwenden möchten, müssen Sie Folgendes tun:

1. Gewähren Sie dem Dienstkonto die erforderlichen Berechtigungen aus dem Google Cloud-Projekt, in dem Artifact Registry ausgeführt wird.

2. Wenn Sie einen Cluster oder Knotenpool mit einem vom Nutzer bereitgestellten Dienstkonto erstellen, wird standardmäßig der Zugriffsbereich cloud-platform gewährt.

   Wenn Sie das Flag --scopes mit dem Befehl gcloud container clusters create oder gcloud container node-pools create verwenden, müssen Sie die entsprechenden Zugriffsbereiche für die Verwendung mit Artifact Registry einschließen.

Zugriffsbereiche festlegen

Zugriffsbereiche sind die Legacy-Methode zum Festlegen der Autorisierung für Compute Engine-VMs. Damit Images aus Artifact Registry-Repositories abgerufen werden können, müssen GKE-Knoten den schreibgeschützten Speicherzugriffsbereich oder einen anderen Speicherzugriffsbereich haben, der den Speicher-Lesezugriff umfasst.

Sie können Zugriffsbereiche nur beim Erstellen eines Clusters oder Knotenpools festlegen. Zugriffsbereiche auf vorhandenen Knoten können nicht geändert werden.

• Wenn Sie das Compute Engine-Standarddienstkonto verwenden, erstellt GKE Knoten mit den Standardzugriffsbereichen von Compute Engine, die Lesezugriff auf den Speicher gewähren.
• Wenn Sie ein vom Nutzer bereitgestelltes Dienstkonto verwenden, erstellt GKE Knoten mit dem Bereich cloud-platform. Dies ist der Bereich, der für die meisten Google Cloud-Dienste erforderlich ist.

Führen Sie den folgenden Befehl aus, um beim Erstellen eines Clusters Zugriffsbereiche anzugeben:

gcloud container clusters create NAME --scopes=SCOPES

Führen Sie den folgenden Befehl aus, um beim Erstellen eines Knotenpools Zugriffsbereiche anzugeben:

gcloud container node-pools create NAME --scopes=SCOPES

Ersetzen Sie die folgenden Werte:

• NAME ist der Name des Clusters oder Knotenpools.

• SCOPES ist eine durch Kommas getrennte Liste der Zugriffsbereiche, die zugewiesen werden sollen.

  • Verwenden Sie einen der folgenden Bereiche, um auf Docker-Repositories zuzugreifen:

  • storage-ro: Gewährt Lesezugriff auf Images.

  • storage-rw – Gewährt Lese- und Schreibberechtigung für das Hoch- und Herunterladen von Images.

  • cloud-platform – Anzeige und Verwaltung von Daten einschließlich Metadaten in allen Google Cloud-Diensten

  • Für den Zugriff auf andere Repositories müssen Sie den Bereich cloud-platform verwenden.

  Eine vollständige Liste der Bereiche finden Sie in der Dokumentation zu gcloud container clusters create oder gcloud container node-pools create.

Weitere Informationen zu Bereichen, die Sie beim Erstellen eines neuen Clusters festlegen können, finden Sie in der Dokumentation zum Befehl gcloud container clusters create.

imagePullSecret konfigurieren

So konfigurieren Sie ein imagePullSecret:

1. Suchen Sie im Projekt mit GKE das Compute Engine-Standarddienstkonto. Die E-Mail-Adresse des Kontos hat das Suffix @developer.gserviceaccount.com.

2. Laden Sie den Dienstkontoschlüssel für das Dienstkonto herunter.

3. Bestätigen Sie im Projekt mit dem Repository, dass Sie dem Repository Berechtigungen erteilt haben.

4. Erstellen Sie im Projekt mit Ihrem Cluster ein imagePullSecret-Secret namens artifact-registry mit dem Dienstkontoschlüssel.

   kubectl create secret docker-registry artifact-registry \
   --docker-server=https://LOCATION-docker.pkg.dev \
   --docker-email=SERVICE-ACCOUNT-EMAIL \
   --docker-username=_json_key \
   --docker-password="$(cat KEY-FILE)"
   

   Wo

   • LOCATION ist der regionale oder multiregionale Speicherort für das Repository.
   • SERVICE-ACCOUNT-EMAIL ist die E-Mail-Adresse des Compute Engine-Dienstkontos.
   • KEY-FILE ist der Name der Dienstkonto-Schlüsseldatei. Beispiel: key.json.

5. Öffnen Sie Ihr Standarddienstkonto:

   kubectl edit serviceaccount default --namespace default

   Jeder Namespace in Ihrem Kubernetes-Cluster hat ein Standarddienstkonto namens default. Dieses Standarddienstkonto wird verwendet, um Ihr Container-Image abzurufen.

6. Fügen Sie das neu erstellte imagePullSecret-Secret Ihrem Standarddienstkonto hinzu:

   imagePullSecrets:
   - name: artifact-registry
   

   Ihr Dienstkonto sollte nun so aussehen:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: default
     namespace: default
     ...
   secrets:
   - name: default-token-zd84v
   # The secret you created:
   imagePullSecrets:
   - name: artifact-registry
   

Jetzt ist für alle neuen Pods, die im aktuellen default-Namespace erstellt werden, das imagePullSecret-Secret definiert.

Artifact Registry-Dienstkonto

Der Artifact Registry-Dienst-Agent ist ein von Google verwaltetes Dienstkonto, das bei der Interaktion mit Google Cloud-Diensten im Namen von Artifact Registry agiert. Weitere Informationen zum Konto und zu seinen Berechtigungen finden Sie unter Artifact Registry-Dienstkonto.

Nächste Schritte

Nachdem Sie Berechtigungen eingerichtet haben, sollten Sie sich näher über die Arbeit mit Ihren Artefakten informieren.

• Container-Images: Docker, Helm
• Sprachpakete: Java, Node.js, Python, Go
• Betriebssystempakete: Debian, RPM