DevSecOps-Pipelines für Einsteiger anpassen
Machen Sie sich mit den Grundlagen für die Einführung von DevSecOps vertraut und integrieren Sie Ihre erste Anwendung oder Ihren Mikroservice.
Informationen zu DevSecops-Toolchains
Sie haben IBM Cloud DevSecOps Continuous Integration (CI), Continuous Deployment (CD) und Continuous Compliance (CC) Toolchains erkannt und getestet, die DevSecOps Best Practices und Sicherheitstools implementieren.
Jetzt können Sie Ihre eigene Anwendung oder Ihren Mikroservice integrieren und DevSecOps einführen.
Vorbereitende Schritte
Sie benötigen die folgenden Ressourcen für das Onboarding einer Anwendung in einer DevSec-Ops-Toolchain:
- Ein Git-Repository für Anwendungsquellcode, das den Code Ihrer Anwendung enthält und häufig als "App-Repository" bezeichnet wird.
- Eine
.pipeline-config.yaml
-Datei. Diese Datei ist die Kernkonfigurationsdatei, die von CI-, CD-und CC-Pipelines verwendet wird, um alle Stages im Pipelineausführungsprozess anzupassen. Beginnen Sie mit einer Beispieldatei.pipeline-config.yaml
, die Sie herunterladen und an Ihre Anforderungen anpassen können. Alle Phasen mit Ausnahme der Startphase können mithilfe der Datei.pipeline-config.yaml
angepasst werden. Die Datei löst Ihre angepassten Scripts zum Erstellen, Testen und Implementieren Ihrer Anwendung aus und führt sie aus. Sie können den Namen der Datei.pipeline-config.yaml
ändern oder verschiedene Dateien für verschiedene Pipelines oder Auslöser verwenden. Stellen Sie sicher, dass die Parameterwerte in Ihrer Pipeline oder Ihrem Auslöser Ihrer Konfigurationsdatei entsprechen. Weitere Informationen finden Sie unter Pipelineparameter.
IBM Cloud verfügt über die folgenden DevSecOps-Vorlagen für den Einstieg:
- BeispielanwendungNode
- CodeEngine-Konformitätsbeispielanwendung
- Go-Compliance-Beispielanwendung
- Python-Konformitätsbeispielanwendung
- BeispielkonformitätsanwendungNode / Cloudant
Verwendung von Repositorys durch DevSecOps-Pipelines
Zum Erstellen, Testen und Bereitstellen Ihrer Anwendung verwenden DevSecOps-Pipelines zwei Repositorys:
app-repo
: Das Anwendungsrepository, das den Quellcode für Ihre Anwendung enthältconfig-repo
: Das Konfigurationsrepository, das Ihre YAML-Dateien und Scripts für die Pipelinekonfiguration enthält
In der DevSecOps-Beispiel-App sind diese beiden Repositorys 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 ist es ein bewährtes Verfahren, ein separates Konfigurationsrepository zum Hosten von Konfigurationsdateien und Scripts 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-Scripts betrachten app-repo
und config-repo
als zwei separate Repositorys. 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.
Onboarding einer Anwendung
Erstellen und testen Sie zur Vereinfachung eine DevSecOps CI-Toolchain mit der Beispielanwendung Node, bevor Sie fortfahren.
Es gibt drei Hauptmöglichkeiten, Ihre erste Anwendung in eine vorhandene DevSecOps-CI-Toolchain zu integrieren:
- Option 1: Fügen Sie Ihr Anwendungsrepository zur Toolchain hinzu und verwenden Sie das Beispielanwendungsrepository als Konfigurationsrepository.
- Option 2: Ersetzen Sie das Beispielanwendungsrepository durch Ihr Anwendungsrepository.
- Option 3: Fügen Sie Ihr Anwendungsrepository zur Toolchain hinzu und verwenden Sie ein dediziertes Konfigurationsrepository. Weitere Informationen zu dieser Option finden Sie unter Erweiterte Anpassungsschritte.
DevSecOps-Toolchains verwenden GitLab-Repositorys, die von IBMverwaltet werden, auch bekannt als GRIT. Stattdessen können andere Git-Provider verwendet werden. Ihr App-Repository kann beispielsweise auf GitHub oder Gitlab gehostet werden.
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:
- Klicken Sie in der IBM Cloud-Konsole auf das Menüsymbol
> DevOps > Toolchains und wählen Sie die Toolchain aus, die Sie bearbeiten möchten.
- Klicken Sie auf Hinzufügen.
- Wählen Sie aus, wo Ihr App-Repository gehostet wird, entweder
Gitlab
oderGitHub
. - Verwenden Sie den Standardserver oder fügen Sie einen neuen Server hinzu.
- Geben Sie die URL des angepassten Servers und das persönliche Zugriffstoken ein.
- Klicken Sie auf Integration erstellen.
- Geben Sie die URL für das Quellcode-Repository Ihrer Anwendung ein.
- Klicken Sie auf Integration erstellen.
Geben Sie als Nächstes das Beispielanwendungsrepository als Konfigurationsrepository an, indem Sie die folgenden Schritte ausführen:
- Klicken Sie in der IBM Cloud-Konsole auf das Menüsymbol
> DevOps > Toolchains und wählen Sie die Toolchain aus, die Sie bearbeiten möchten.
- Klicken Sie Auf pr-pipeline.
- Klicken Sie auf Einstellungen und wechseln Sie zur Registerkarte Umgebungseigenschaften.
- Bearbeiten Sie den Wert der Eigenschaft
pipeline-config-repo
so, dass er auf die URL des Beispielanwendungsrepositorys verweist. - Kehren Sie zu Ihrer CI-Toolchain zurück.
- Klicken Sie Auf ci-pipeline.
- Klicken Sie auf Einstellungen und wechseln Sie zur Registerkarte Umgebungseigenschaften.
- Bearbeiten Sie den Wert der Eigenschaft
pipeline-config-repo
so, dass er auf die URL des Beispielanwendungsrepositorys verweist.
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:
- Klicken Sie in der IBM Cloud-Konsole auf das Symbol Menü
> DevOps > Toolchains und wählen Sie die CI-Toolchain aus, die Sie bearbeiten wollen.
- Suchen Sie das Quellcode-Repository der Beispielanwendung und wählen Sie Konfigurieren aus.
- Ersetzen Sie die Repository-URL durch die URL Ihres Anwendungsquellcode-Repositorys.
- 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.
Pipelineauslöser konfigurieren
Standardauslöser verwenden das Beispielanwendungsrepository, sodass Sie sie für die Verwendung Ihres App-Repositorys aktualisieren müssen. Überprüfen Sie die Auslösereinstellungen und ändern Sie sie bei Bedarf, um sicherzustellen, dass alle Auslöser auf Ihr App-Repository verweisen. Führen Sie die folgenden Schritte aus:
- Klicken Sie in der IBM Cloud-Konsole auf das Symbol Menü
> DevOps > Toolchains und wählen Sie die CI-Toolchain aus, die Sie bearbeiten wollen.
- Klicken Sie Auf pr-pipeline.
- Bearbeiten Sie Git PR Trigger und geben Sie die URL und den Zweig Ihres Anwendungsrepositorys an.
- Klicken Sie auf Speichern.
- Kehren Sie zu Ihrer CI-Toolchain zurück und klicken Sie auf ci-pipeline.
- Bearbeiten Sie den Git CI-Auslöser und geben Sie die URL und den Zweig Ihres Anwendungsrepositorys an. Stellen Sie sicher, dass der App-Name im Abschnitt Eigenschaften korrekt ist.
- Klicken Sie auf Speichern.
- Bearbeiten Sie den manuellen Auslöser. Stellen Sie im Abschnitt Eigenschaften sicher, dass der App-Name korrekt ist.
- Stellen Sie sicher, dass die Repository-und Verzweigungseigenschaften korrekt sind und auf Ihr App-Repository verweisen.
Datei .pipeline-config.yaml
konfigurieren
Kopieren Sie entweder die Datei .pipeline-config.yaml
aus dem Repository der Beispielapp in Ihr Anwendungsrepository oder verwenden Sie diese Beispielkonfigurationsdatei.
Stellen Sie für pr-pipeline
und ci-pipeline
sicher, dass die Parameter pipeline-config
, pipeline-config-branch
und pipeline-config-repo
ordnungsgemäß festgelegt sind und Ihrer
Konfiguration entsprechen. Wenn diese Parameter nicht ordnungsgemäß festgelegt sind, können Sie Änderungen in der falschen Verzweigung festschreiben, was zu einem Fehler in Ihrer Pipeline führt.
Wenn die Variable pipeline-config-repo
nicht festgelegt ist, gehen DevSecOps-Pipelines davon aus, dass es sich um dasselbe Repository wie das Quellcode-Repository Ihrer Anwendung handelt.
Angepasste Scripts mit DevSecOps verwenden
Die Datei pipeline-config.yaml
ist die Schlüsselkomponente, die das Verhalten der DevSecOps-Pipeline koordiniert 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 Scripts, die von DevSecOps-Pipelines verwendet werden:
- Anwendungsbezogene Scripts, die zum Erstellen, Testen und Implementieren Ihrer Anwendung verwendet werden. Diese Scripts liegen in Ihrer eigenen Verantwortung und liegen außerhalb des Geltungsbereichs für die DevSec-Ops-Unterstützung. 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.
Weitere Informationen finden Sie unter Docker-Images im Abschnitt zu 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.
Migration von Jenkins oder Travis auf DevSecOps
Die meisten DevSecOps-Anwender beginnen nicht mit nichts. Die meisten Anwender verfügen bereits über kontinuierliche Integrations-und Continuous Delivery-Prozesse sowie eine entsprechende Scriptbibliothek. Diese Prozesse werden normalerweise mithilfe von Jenkins, Travis oder einer anderen Plattform implementiert.
Schlüsselpunkte für die Migration auf DevSecOps:
- Die Konfigurationsdatei
pipeline-config.yaml
sollte widerspiegeln, wie die CI-und CD-Pipelines derzeit koordiniert werden. Stages und Schritte sollten DevSecOps-Pipeline-Stages zugeordnet sein. - Sie sollten dieselben Scripts, Basisimages und Variablen verwenden, die bereits vorhanden sind.
- Eigenschaften geheimer Schlüssel müssen in einen Speicher für geheime Schlüssel migriert werden.
- Nicht geheime Eigenschaften müssen als Pipeline-oder Triggereigenschaften hinzugefügt werden.
Im Entwicklungsmodus arbeiten
Sie können den Entwicklungsmodus für CI-und CD-Pipelines verwenden, um die Implementierung Ihrer .pipeline-config.yaml
-Datei und Scripts zu testen. Die Pipeline im Entwicklungsmodus führt keine sicherheits-oder konformitätsbezogenen
Tasks aus, was die Laufzeit für die Pipeline verringert. Weitere Informationen finden Sie unter Pipelines im Entwicklungsmodus ausführen.
Verwenden Sie den Entwicklungsmodus nur für Entwicklungszwecke. Der Entwicklungsmodus ist kein Ersatz für die offiziellen DevSecOps CI-und CD-Pipelines, die die Referenzimplementierungen bleiben.
CD-Pipeline konfigurieren
Im DevSecOps-Workflow für kontinuierliche Integration überträgt die CI-Pipeline während der deploy-release
-Phase der CI-Pipeline Aktualisierungen
an das Bestandsrepository. Weitere Informationen finden Sie unter Beispielscript release.sh.
In diesem Workflow können mehrere CI-Auslöser und unterschiedliche DevSecOps-CI-Toolchains zu demselben Bestandsrepository 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.
Position der DevSecOps-Scripts
DevSecOps-Pipelines werden mit Standardsicherheits-und Scantools und zugehörigen Scripts 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 Umgebungsvariablen namens COMMONS_PATH
bereit, die in allen
Tasks 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 bereitgestellt, aber Sie können beliebig viele angepasste 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.
Docker-Images, die von DevSecOps-Pipelines verwendet werden, sind in der Datei .pipeline-config.yaml
angegeben. Jede Stufe kann ein anderes
Bild verwenden.
Imageversion ändern
Abhängig von Ihren Anforderungen müssen Sie möglicherweise eine andere Version eines Image verwenden. Bearbeiten Sie zum Ändern der Imageversion die Datei .pipeline-config.yaml
. Wenn Sie beispielsweise auf das folgende Bild
in Ihrer YAML-Datei icr.io/continuous-delivery/pipeline/pipeline-base-ubi
:3.24
verwiesen haben, ändern Sie es in icr.io/continuous-delivery/pipeline/pipeline-base-ubi
:3.27
, um die Version
3.27 des Bildes zu verwenden.
Ändern Sie auf dieselbe Weise die dind_image
für die Stage:
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
(...)
Unterstützung anfordern
Wenn Sie Ihre DevSec-Ops-Pipelines anpassen, erhalten Sie Hilfe direkt von den IBM Cloud-Entwicklungsteams, indem Sie bei Slack teilnehmen.