FAQ für DevSecOps

Hier finden Sie Antworten auf häufig gestellte Fragen zur Nutzung von DevSecOps.

Was ist der Unterschied zwischen CI- und CC-Pipeline?

Sie werden feststellen, dass die CI- und die CC-Pipeline gemeinsame Schritte haben. Die durchgeführten Scans und Kontrollen ähneln sich in Art und Umfang. In der folgenden Tabelle sind die Unterschiede zwischen der CI- und der CC-Pipeline aufgeführt.

Unterschiede in den CI- und CC-Pipelines
CI-Pipeline CC-Pipeline
Es ist Teil der CI-Toolchain. Es ist Teil der CC-Toolchain.
Sie wird ausgelöst, nachdem ein Antrag auf Zusammenführung mit dem master-Zweig zusammengeführt wurde Sie kann manuell oder in vordefinierten Intervallen ausgelöst werden, die unabhängig von einem Verteilungsplan sind.
Im Rahmen des Einrichtungsprozesses werden eine E-Mail-Adresse ( URL ) und Details zum Anwendungscode-Repository eingegeben. Eine Anwendung URL und Anwendungscode-Repo-Details werden nach der Konfiguration der CC-Toolchain und vor dem Start des ersten Pipeline-Laufs bereitgestellt.
Die Vorfallsausgaben, die im Rahmen der verschiedenen Scans und Prüfungen während der Konformitätsprüfungen erstellt werden, haben kein Fälligkeitsdatum. Die Vorfallsausgaben, die im Rahmen der verschiedenen Scans und Prüfungen während der Konformitätsprüfungen erstellt werden, sind mit einem Fälligkeitsdatum versehen.
Die entstehenden Probleme werden während der Erstellung gefunden. Die entstehenden Probleme werden bei regelmäßigen Scans der Staging- oder Produktionsumgebung gefunden.
Die summary.json-Datei wird nicht am Ende eines jeden CI-Pipeline-Laufs erstellt. Die summary.json-Datei wird nicht am Ende eines jeden CI-Pipeline-Laufs erstellt.
Es umfasst Schritte wie die Erstellung von Anwendungsartefakten, das Signieren von Artefakten und die Bereitstellung im Entwicklungscluster. Dies wiederum schafft Inputs für die CD-Pipeline. Es werden nur Scans und Prüfungen durchgeführt, die für die Konformitätsprüfung erforderlich sind.

Wie kann ein Benutzer die Pipeline anpassen?

Eine Pipeline wird mit Hilfe von benutzerdefinierten Skripten angepasst. Benutzerdefinierte Skripte sind Erweiterungspunkte in der Pipeline, an denen Adopter, Teams und Benutzer Skripte zur Ausführung benutzerdefinierter Aufgaben für ihre CI/CD-Strategien bereitstellen können.

Angepasste Scripts steuern die Stages der Pipeline. Sie können eine Konfigurationsdatei verwenden, (pipeline-config.yaml) um das Verhalten der Phasen, den Skriptinhalt und das Basis-Artefakt, das die Skripte ausführt, zu konfigurieren. Die Skripte und die Konfiguration für Pipeline-Stufen werden aus einem Anwendungs-Repository geladen, das .travis.yml oder Jenkinsfile oder einem benutzerdefinierten Repository ähnelt.

Weitere Informationen finden Sie unter Anpassen von Pipelines mithilfe von benutzerdefinierten Skripten.

Multi-Arch-Image für s390x und Power-Plattformen Einschränkungen

One-Pipeline bietet native Unterstützung für s390x und Power-Plattformen unter Verwendung von runtimeClassName (eine Zeichenfolge zur Angabe des Laufzeitprofils) in der One-Pipeline-Konfigurationsdatei. Diese native Unterstützung ist jedoch mit einigen Einschränkungen und Empfehlungen verbunden:

  • Einschränkungen:
    • Diese Funktion ist nur in v11 verfügbar.
    • Die Pod-Startzeit ist höher als bei x86 runtime class.
    • Sie müssen podman mit s390x oder Power-Workloads verwenden. Docker ist nicht verfügbar.
      • Benutzerskripte müssen aktualisiert werden, damit sie mit dem Befehl podman anstelle des Befehls docker funktionieren
      • Auf dem Stage-Image sollte podman installiert sein.
  • Empfehlungen: Verwenden Sie x86 Laufzeitklassen für
    • scannen, da die verschiedenen Scan-Tool-Images möglicherweise keine Multiarch-Unterstützung bieten.
    • bildsignierung, da die Unterstützung mehrerer Architekturen nicht verfügbar ist (in Arbeit).

Wie kann ich ein benutzerdefiniertes Basis-Image für mehrere Architekturen erstellen?

One Pipeline stellt ein offizielles Basis-Image für mehrere Architekturen bereit, das die folgenden Plattformen unterstützt:

  • linux/amd64
  • linux/ppc64le
  • linux/s390x

Für die meisten Anwendungsfälle empfehlen wir, das offizielle Basis-Image direkt zu verwenden:

icr.io/continuous-delivery/toolchains/devsecops/baseimage:<version>

Falls Ihre Anwendung zusätzliche Betriebssystempakete, Sprach-Laufzeitumgebungen oder andere benutzerdefinierte Abhängigkeiten benötigt, können Sie im Rahmen Ihrer CI-Pipeline ein eigenes, benutzerdefiniertes Basis-Image für mehrere Architekturen erstellen.

Verwenden Sie „ Docker “ Buildx mit der Option „ --platform “ in Ihrem Schritt „ build-artifact “:

docker buildx build \
  --platform linux/amd64,linux/ppc64le,linux/s390x \
  -t <registry>/<namespace>/<image>:<tag> \
  --push .

Dadurch werden architektur-spezifische Images erstellt und als ein einziges Manifest für Multi-Architektur-Images veröffentlicht. Container-Laufzeitumgebungen laden automatisch das für die Zielplattform geeignete Image herunter.

Empfohlene Vorgehensweise

  1. Verwenden Sie das Basis-Image „One Pipeline“ als „ FROM “-Image in Ihrer Dockerfile-Datei.
  2. Fügen Sie nur die zusätzlichen Pakete oder Abhängigkeiten hinzu, die Ihre Anwendung benötigt.
  3. Erstellen und veröffentlichen Sie das Image mithilfe von „ Docker Buildx“ in Ihrer CI-Pipeline.
  4. Überprüfen Sie das veröffentlichte Bild unter docker buildx imagetools inspect oder skopeo inspect.

Weitere Informationen zur Multi-Arch-Unterstützung und zu den Einschränkungen finden Sie unter „ Einschränkungen bei Multi-Arch-Images für die Plattformen „ s390x “ und „Power“ “.

Auslösen der Pipeline mit CLI

Eine Pipeline kann mit Hilfe der IBM Cloud CLI oder einer API ausgelöst werden. Mit der CLI können Sie eine Pipeline starten, indem Sie die Toolchain- und Pipeline-IDs angeben. Über die API können Sie eine POST-Anforderung mit der richtigen Authentifizierung und den richtigen Kopfzeilen senden, um die Pipeline auszulösen.

Weitere Informationen finden Sie unter Auslöser verwenden

Welche Umgebungsvariable wird beim Klonen von Repositorys unter Git verwendet?

Die Pipelines von „ DevSecOps “ verwenden ein hierarchisches Token-System zur Authentifizierung von Vorgängen im „ Git “-Repository, einschließlich des Klonens. Die Umgebungsvariable „ git-token “ dient als Standard-Token, Sie können sie jedoch durch spezifischere Token überschreiben, um die Sicherheit und Zugriffskontrolle zu verbessern.

Reihenfolge der Token-Prioritäten

Die Pipeline wertet Authentifizierungstoken von „ Git “ in der folgenden Prioritätsreihenfolge aus (von der höchsten zur niedrigsten):

  1. Persönliches Zugriffstoken (PAT), das in der Toolchain-Integration für ein bestimmtes Repository angegeben ist
  2. Repository-spezifisches Token: git-token-[repo_name]-[repo_org]
  3. Organisationsspezifisches Token: git-token-[repo_org]
  4. Standard-Token: git-token
  5. OAuth Token aus der Toolchain-Integration (falls „ OAuth “ anstelle von „PAT“ verwendet wird)

Beispiele für die Benennung von Token

Für ein Repository unter https://github.com/my-org/my-app:

  • Repository-spezifisch: git-token-my-app-my-org
  • Organisationsspezifisch: git-token-my-org

Wichtige Überlegungen

  • Wenn dieselbe „ git-token “ sowohl für Lesevorgänge (Repositorys klonen) als auch für Schreibvorgänge (PR-/CI-Status festlegen, Inventar aktualisieren) verwendet wird, reicht ein Lesezugriff nicht aus. Das Token muss über Schreibrechte verfügen.
  • Durch die Verwendung von Repository- oder organisationsspezifischen Tokens können Sie das Prinzip der geringsten Berechtigungen anwenden, indem Sie für jedes Repository nur die erforderlichen Berechtigungen erteilen.

Weitere Informationen zu den Funktionen von Repository-Tokens finden Sie unter „ Repository-Informationen und Tokens abrufen “.

Wie testet man Änderungen an der Konfiguration von „ OnePipeline “?

Das Testen von Änderungen an Ihrer „ OnePipeline “-Konfiguration erfordert einen systematischen Ansatz, um Störungen der Produktionspipelines zu vermeiden und gleichzeitig die Anpassungen zu validieren.

Die Komponenten von „ OnePipeline “ verstehen

OnePipeline besteht aus zwei anpassbaren Hauptkomponenten:

  • Tekton-Pipeline-Definitionen: Zentral verwaltete Pipeline-Definitionen für PR-, CI-, CD- und CC-Workflows, verfügbar im Repository „compliance-pipelines “. Neue Versionen werden alle zwei Wochen im Rahmen eines Sprints veröffentlicht.

    • v10: Stabile Version mit begrenzter Parallelität
    • v11: Die Version der nächsten Generation mit maximaler Anpassbarkeit und Parallelität

  • Pipeline-Konfiguration (.pipeline-config.yaml): Benutzerdefinierte Konfigurationsdatei, die das Standardverhalten der Pipeline überschreibt, einschließlich Pipeline-Images, Skripten, Architekturen und Eigenschaften. Diese Datei kann in Ihrem Anwendungs-Repository oder in einem zentralen Konfigurations-Repository gespeichert werden.

Testansatz 1: Verwendung einer Testkonfigurationsdatei

Dies ist die empfohlene Vorgehensweise, um Konfigurationsänderungen zu testen, ohne die Produktionspipelines zu beeinträchtigen.

  1. Testzweig erstellen

    • Erstellen Sie im Repository einen Zweig, der Ihre Datei „ .pipeline-config.yaml “ enthält
    • Nimm deine Konfigurationsänderungen in diesem Zweig vor

  2. Testauslöser einrichten

    • Dupliziere den vorhandenen Pipeline-Trigger in deiner Toolchain
    • Gib ihm einen eindeutigen Namen (zum Beispiel „ Manual-Test-Config “)
    • Passen Sie die Trigger-Eigenschaften so an, dass sie auf Ihre Testkonfiguration verweisen:
      • pipeline-config: Dateiname Ihrer Konfigurationsdatei
      • pipeline-config-branch: Der Name Ihres Test-Branches
      • pipeline-config-repo: Repository URL mit der Konfiguration

  3. Im Entwicklungsmodus testen

    • Entwicklungsmodus in den Triggereigenschaften aktivieren
    • Führen Sie die Pipeline aus, um Ihre benutzerdefinierten Skripte zu überprüfen
    • Im Entwicklungsmodus werden die Erfassung von Nachweisen, die Erstellung von Compliance-Vorgängen und Bestandsaktualisierungen übersprungen, was ihn ideal für schnelle Iterationen macht
    • Wichtig: Der Entwicklungsmodus ist für Produktionsanwendungen nicht geeignet

  4. Test mit Konformitätsprüfungen

    • Nachdem Sie die Skripte im Entwicklungsmodus überprüft haben, deaktivieren Sie dev-mode
    • Deaktivieren Sie die Bestandsaktualisierung während des Tests
    • Führen Sie einen vollständigen Prozess mit Beweissicherung und Problemmanagement durch
    • Stellen Sie sicher, dass alle Konformitätsprüfungen wie erwartet erfolgreich verlaufen

  5. Zu Produktion hochstufen

    • Wenn die Tests zufriedenstellend verlaufen sind, erstelle einen Pull-Request, um deine Änderungen in den Hauptzweig zu integrieren
    • Die Änderungen werden automatisch auf die Trigger in der Produktionsumgebung angewendet
    • Sollten Probleme auftreten, können Sie die Änderungen schnell rückgängig machen

Testansatz 2: Anpassung des Pipeline-Aufbaus

Verzweigte Pipeline-Definitionen (Fortgeschrittene)

  • (Das Repository „compliance-pipelines“ forken)
  • Änderungen in deiner Fork entwickeln und testen
  • Füge das geforkte Repository als „ Git “-Integration in deine Toolchain ein
  • Aktualisiere die Pipeline-Definition vorübergehend, damit sie auf deinen Fork verweist
  • Konfigurieren Sie einen Trigger im Entwicklungsmodus, um die neue Pipeline-Definition zu testen
  • Befolgen Sie die Testschritte aus Ansatz 1

Bewährte Verfahren

  • Testen Sie immer zuerst im Entwicklungsmodus, um Skriptfehler schnell zu erkennen
  • Verwenden Sie aussagekräftige Namen für Testauslöser, um Verwechslungen zu vermeiden
  • Dokumentiere deine Konfigurationsänderungen in Commit-Meldungen
  • Lassen Sie Testauslöser deaktiviert oder löschen Sie sie nach dem Testen, um versehentliche Ausführungen zu verhindern
  • Erwägen Sie die Einrichtung einer speziellen Test-Toolchain für größere Änderungen an der Pipeline
  • Überprüfen Sie die Pipeline-Protokolle sorgfältig, um sicherzustellen, dass alle Phasen wie erwartet ausgeführt werden

Weitere Informationen zum Anpassen von Pipelines finden Sie unter Benutzerdefinierte Skripte und