Wie DevSecOps Pipelines Repositories verwenden

Zum Erstellen, Testen und Bereitstellen Ihrer Anwendung verwenden DevSecOps Pipelines zwei Repositorys:

• app-repo: Das Anwendungsrepository, das den Quellcode für Ihre Anwendung enthält
• config-repo: Das Konfigurationsrepository, das Ihre YAML-Dateien und Scripts für die Pipelinekonfiguration enthält

In der DevSecOps Beispiel-App sind diese beiden Repositories identisch. Die meisten DevSecOps Anwender beginnen mit diesem Muster. Wenn Sie jedoch weitere Mikroservices integrieren, kann ein dediziertes und separates Pipelinekonfigurationsrepository erforderlich werden. Da das Anwendungsrepository und das Konfigurationsrepository in der Beispiel-App identisch sind, wird das Repository zweimal geklont, wenn die Pipelines ausgeführt werden. Dies kann zu Fehlern führen. Daher empfiehlt es sich, ein separates Konfigurationsrepository zum Hosten von Konfigurationsdateien und Skripten zu haben, die von verschiedenen DevSecOps Toolchains und -Pipelines gemeinsam genutzt und wiederverwendet werden können. Weitere Informationen zum Anpassen des Konfigurationsrepositorys finden Sie unter Erweiterte Anpassungsschritte.

DevSecOps skripte betrachten die app-repo und die config-repo als zwei getrennte Repositories. Die Scripts klonen die Repositorys zweimal während der Startphase der Pipeline. Diese Klone werden als app-repo und one-pipeline-config-repo bezeichnet. Jede Phase wird im Kontext von config repo ausgeführt.

Option 1: Fügen Sie Ihr Anwendungsrepository hinzu und verwenden Sie das Beispielanwendungsrepository als Konfigurationsrepository.

Führen Sie die folgenden Schritte aus, um Ihr Anwendungsrepository zur Toolchain hinzuzufügen und das Beispielanwendungsrepository als Konfigurationsrepository zu verwenden:

1. Klicken Sie in der Cloud- IBM Cloud auf das Menüsymbol > Plattformautomatisierung > Toolchains und wählen Sie die Toolchain aus, die Sie bearbeiten möchten.
2. Klicken Sie auf Hinzufügen.
3. Wählen Sie aus, wo Ihr App-Repository gehostet wird, entweder Gitlab oder GitHub.
4. Verwenden Sie den Standardserver oder fügen Sie einen neuen Server hinzu.
5. Geben Sie die URL des benutzerdefinierten Servers und das persönliche Zugriffstoken ein.
6. Klicken Sie auf Integration erstellen.
7. Geben Sie Ihr Quellcode-Repository für Anwendungen URL ein.
8. Klicken Sie auf Integration erstellen.

Geben Sie als Nächstes das Beispielanwendungsrepository als Konfigurationsrepository an, indem Sie die folgenden Schritte ausführen:

1. Klicken Sie in der Cloud- IBM Cloud auf das Menüsymbol > Plattformautomatisierung > Toolchains und wählen Sie die Toolchain aus, die Sie bearbeiten möchten.
2. Klicken Sie Auf pr-pipeline.
3. Klicken Sie auf Einstellungen und wechseln Sie zur Registerkarte Umgebungseigenschaften.
4. Bearbeiten Sie den Wert der Eigenschaft pipeline-config-repo, um auf das Beispielanwendungs-Repository URL zu verweisen.
5. Kehren Sie zu Ihrer CI-Toolchain zurück.
6. Klicken Sie Auf ci-pipeline.
7. Klicken Sie auf Einstellungen und wechseln Sie zur Registerkarte Umgebungseigenschaften.
8. Bearbeiten Sie den Wert der Eigenschaft pipeline-config-repo, um auf das Beispielanwendungs-Repository URL zu verweisen.

Ihre CI-Pipelines verwenden jetzt das Beispiel-App-Repository pipeline-config als Konfigurationsrepository.

Option 2: Beispielanwendungsrepository durch eigenes Anwendungsrepository ersetzen

Führen Sie die folgenden Schritte aus, um das Beispiel-App-Repository durch Ihr eigenes App-Repository zu ersetzen:

1. Klicken Sie in der IBM Cloud Cloud-Konsole auf das Menüsymbol > Plattformautomatisierung > Toolchains und wählen Sie die CI-Toolchain aus, die Sie bearbeiten möchten.
2. Suchen Sie das Quellcode-Repository der Beispielanwendung und wählen Sie Konfigurieren aus.
3. Ersetzen Sie das Repository URL durch Ihr Quellcode-Repository für Anwendungen URL.
4. Klicken Sie auf Integration speichern.

Stellen Sie nach dem Ersetzen des Beispiel-App-Repositorys sicher, dass das neue App-Repository eine Datei .pipeline-config.yaml und entsprechende Scripts enthält. Kopieren Sie entweder die Datei .pipeline-config.yaml und die Scripts aus dem Repository der Beispielapp in Ihr Anwendungsrepository oder verwenden Sie diese Beispielkonfigurationsdatei.

CI-Pipelines konfigurieren

Nachdem Sie Ihr Anwendungsrepository hinzugefügt haben, müssen Sie die CI-Pipelines für die Arbeit mit dem neuen Repository konfigurieren.

Benutzerdefinierte Skripts mit DevSecOps verwenden

Die Datei pipeline-config.yaml ist die Schlüsselkomponente, die das Verhalten der DevSecOps Pipeline orchestriert und anpasst. Die Datei verwendet Scripts, um Ihre Anwendung zu erstellen, zu testen und zu implementieren. Die Datei definiert, wie die Stages konfiguriert werden und welche Scripts ausgeführt werden. Weitere Informationen finden Sie unter Angepasste Scripts.

Es gibt zwei Hauptkategorien von Skripts, die von DevSecOps Pipelines verwendet werden:

• Anwendungsbezogene Scripts, die zum Erstellen, Testen und Implementieren Ihrer Anwendung verwendet werden. Diese Skripte liegen in Ihrer eigenen Verantwortung und fallen nicht in den Geltungsbereich des DevSecOps Supports. Da diese Scripts keine Standardimplementierung haben, müssen Sie sie Ihrer Anwendung oder Ihrem Konfigurationsrepository hinzufügen. Möglicherweise müssen Sie die Scripts aus Jenkins oder einer anderen Quelle extrahieren.
• Sicherheits-und Compliance-Scripts, die Sicherheits-und Compliance-Scans ausführen. Die meisten werden mit Standardscripts geliefert, die Sie überschreiben können, um Ihre eigene angepasste Implementierung zu verwenden.

Mit Ausnahme der Startphase kann jede Phase einer CI-, CD-oder CC-Pipeline mit eigenen Scripts angepasst werden, um die Standardimplementierung der Stage zu überschreiben. Die Startphase kann nicht mit eigenen Scripts angepasst werden.

Obwohl Bash-Scripts als Beispiele bereitgestellt werden, können Sie Ihre Anwendung mit anderen Sprachen wie Python oder Go erstellen, testen und bereitstellen. Stellen Sie sicher, dass Sie die richtige image für jede Phase verwenden. Siehe die Docker Images im Abschnitt DevSecOps Pipelines.

In der Tabelle Stufen und Aufgaben finden Sie eine Zusammenfassung der verschiedenen Stufen der CI-Pipeline. Die Tabelle enthält außerdem konsolidierte Informationen darüber, ob die Phase über eine Standardreferenzimplementierung verfügt, ob sie angepasst oder übersprungen werden kann oder ob es eine explizite Angabensammlung gibt, die für die Phasenausführung erforderlich ist.

CD-Pipeline konfigurieren

Im DevSecOps Workflow für kontinuierliche Integration und Bereitstellung überträgt die CI-Pipeline während der Phase deploy-release der CI-Pipeline Aktualisierungen an das Inventar-Repository. Weitere Informationen finden Sie unter Beispielscript release.sh.

In diesem Workflow können mehrere CI-Trigger und verschiedene DevSecOps CI-Toolchains zum selben Inventar-Repository beitragen.

Im Gegensatz zur CI-Pipeline muss das von der CD-Pipeline verwendete Bereitstellungsscript aus Ihren aktuellen Scripts in Jenkins, Travis oder einer anderen Plattform angepasst werden, um die Einträge im Bestandsrepository zu verwenden.

Dieser Beispielcode zeigt, wie Informationen aus dem Bestand abgerufen und verwendet werden, um eine Kubernetes-Implementierung auszuführen.

Speicherort DevSecOps Skripte

DevSecOps Pipelines werden mit standardmäßigen Sicherheits- und Scan-Tools und zugehörigen Skripts geliefert.

Der Anfang eines Stageprotokolls verweist beispielsweise auf das Standardscript:

scan-artifact:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.24
  dind: true
  dind_image: icr.io/continuous-delivery/toolchains/devsecops/docker:20.10.21-dind
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script: |
    #!/bin/sh

    "/opt/commons/scan-artifact/scan.sh"

/opt/commons/scan-artifact/scan.sh ist das Standardscript.

Die DevSecOps Pipeline stellt den Pfad zum Stammordner der Commons-Bibliothek in einer Umgebungsvariable namens COMMONS_PATH bereit, die in allen Aufgaben und Schritten verfügbar ist. Für den Zugriff auf ein Script, das in das Konformitätsbasisimage integriert ist, verwenden Sie die Variable COMMONS_PATH mit dem benötigten Scriptordner:

source "${COMMONS_PATH}/<script folder in commons>/<script file name>

In der Tabelle Stufen und Tasks finden Sie eine Zusammenfassung der verschiedenen Stufen der CD-Pipeline. Die Tabelle enthält außerdem konsolidierte Informationen darüber, ob die Phase über eine Standardreferenzimplementierung verfügt, ob sie angepasst oder übersprungen werden kann oder ob eine explizite Angabensammlung für die Phasenausführung erforderlich ist.

Umgebungseigenschaften

DevSecOps Pipelines werden mit vordefinierten Umgebungseigenschaften geliefert, Sie können jedoch beliebig viele benutzerdefinierte Eigenschaften hinzufügen. Sie können auf diese Eigenschaftswerte in Ihren Scripts mit dem get_env-Befehl zugreifen.

Nachdem Sie Ihre Eigenschaft und den zugehörigen optionalen Standardwert zur Pipeline oder zum Auslöser hinzufügen, verwenden Sie den Befehl get_env in Ihrem Script, um den Wert der Eigenschaft abzurufen. Im folgenden Beispiel wird der Wert der Eigenschaft my-variable abgerufen:

MY_VARIABLE=$(get_env my-variable "")

Sie können den Wert einer Eigenschaft in einem Script auch dynamisch mit dem set_env-Befehl überschreiben. Im folgenden Beispiel wird der Wert in der Eigenschaft my-variable überschrieben:

set_env my-variable new-value

Stages werden übersprungen

Einige Phasen können irrelevant sein. Möglicherweise erstellen Sie keine Docker-Images oder Sie haben noch keine Abnahmetests implementiert. Wenn Sie eine Stage überspringen wollen, können Sie die Datei .pipeline-config.yaml bearbeiten, um exit 0 einzuschließen, oder die Variable skip auf true setzen.

Im folgenden Beispiel wird exit 0 hinzugefügt, um eine Phase zu überspringen:

scan-artifact:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.24
  dind: true
  dind_image: icr.io/continuous-delivery/toolchains/devsecops/docker:20.10.21-dind
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  skip: false
  runAfter: null
  script: |
    #!/bin/sh

    exit 0
    "/opt/commons/scan-artifact/scan.sh"

Docker-Images in DevSecOps Pipelines

Standardmäßig verwenden DevSecOps Pipelines IBM Continuous Delivery Images. Diese Images enthalten einige der gängigsten Tools wie Node und Java für die Ausführung Ihrer Scripts. Sie können auch Images anderer Anbieter oder eigene angepasste Images verwenden, die Ihre bevorzugten Tools enthalten.

Von DevSecOps Pipelines verwendete Docker Images sind in der Datei .pipeline-config.yaml angegeben. Jede Stufe kann ein anderes Bild verwenden.

scan-artifact:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.24
  dind: true
  dind_image: icr.io/continuous-delivery/toolchains/devsecops/docker:20.10.21-dind
(...)