FortschrittlichDevSecOps Pipeline-Anpassung

Erfahren Sie mehr über die erweiterten Funktionen von DevSecOps adoption, nachdem Sie Ihre erste Anwendung oder Ihren ersten Microservice in Betrieb genommen haben.

Überprüfen Sie unbedingt die Grundlagen vonDevSecOps Pipeline-Anpassung. Dort erfahren Sie mehr über die verschiedenen verfügbaren Vorlagen, Support-Optionen und andere wichtige Informationen für den Einstieg.DevSecOps.

Auswahlmöglichkeiten für das Design

Während Sie weitere Anwendungen und Microservices einbinden, umDevSecOps, Möglicherweise haben Sie folgende Designfragen:

Benötige ich eine Toolchain pro Mikroservice?
Benötige ich eine Pipeline pro Mikroservice?
Muss ich einen gemeinsamenDevSecOps Repository für Inventar und Probleme oder brauche ich separate Repositorys?

Die folgenden Informationen und bewährten Verfahren sollen Ihnen helfen, diese Designentscheidungen zu treffen.

Hinweise zu Toolchains und Pipelines

Die meisten Anwendungen bestehen aus mehreren Mikroservices mit unterschiedlichen Quellenrepositorys. Normalerweise wird eine einzelne Toolchain verwendet, um Mikroservices zu hosten, die logisch gruppiert sind. Verwenden Sie im Allgemeinen eine Toolchain und eine Pipeline oder so wenige Pipelines wie möglich, aber mehrere Auslöser. In jeder Pipeline können Sie so viele Trigger wie Sie benötigen duplizieren und konfigurieren, bis zu 1024 Trigger pro Pipeline. Diese Strategie unterstützt die Durchsetzung allgemeiner Prozesse, Scripts und Konfigurationsdateien. Weitere Informationen finden Sie unter Mehrere Apps in einer CI-Toolchain konfigurieren.

Dieser Ansatz hat die folgenden Vorteile:

Durch die Verwendung weniger Pipelines werden Duplizierungen vermieden und Fehler verringert. Aktualisierungen sind auch einfacher zu verwalten, z. B. wenn eine Umgebungseigenschaft oder ein geheimer Schlüssel hinzugefügt, bearbeitet oder gelöscht wird.
Das Onboarding eines Service ist mit diesem Ansatz schneller. Fügen Sie eine Git-Integration für Ihren Mikroservice hinzu, duplizieren Sie Git und manuelle Auslöser und ändern Sie sie nach Bedarf. Stellen Sie anschließend sicher, dass Ihre .pipeline-config.yaml-Datei und Scripts für Ihren Mikroservice implementiert sind.

Dieser Ansatz hat die folgenden Nachteile:

Eine Bearbeitung kann sich auf jedes Team auswirken, das dieselbe Pipeline verwendet.
Der Benutzerzugriff wird mithilfe von Identity and Access Management(IAM) verwaltet und auf Toolchain-Ebene und nicht auf Pipeline-Ebene festgelegt. Wenn Sie also eine einzelne Toolchain für mehrere Services verwenden, kann jedes Mitglied des Teams die Pipelines anderer Teams anzeigen. Abhängig vom Zugriff des Benutzers in IAM kann er eine Pipeline bearbeiten, löschen oder auslösen.

Aspekte der Abrechnung

Der Dienst Continuous Delivery ermittelt die Abrechnung auf der Grundlage der Anzahl der autorisierten Benutzer pro CD-Instanz und der Anzahl der Ressourcengruppen, die Sie für Ihre Toolchains verwenden. Benutzer, die Zugriff auf Ihre Repositorys haben, werden ebenfalls als berechtigte Benutzer betrachtet. Weitere Informationen finden Sie unter Berechtigte Benutzer. Um die Kosten zu senken, sollten Sie entweder alle Ihre Toolchains in derselben Ressourcengruppe organisieren, oder Sie sollten die Continuous Delivery konsolidierte Fakturierung innerhalb einer Unternehmenskontohierarchie konfigurieren. Weitere Informationen finden Sie unter Konsolidierte Rechnungsstellung.

DevSecOps Überlegungen zu Repositorys

Wenn Sie eine Anwendung erstellen, die aus mehreren Microservices besteht,DevSecOps Repositories – mit Ausnahme des Beweisrepositorys – können über die Microservices hinweg gemeinsam genutzt werden.

Weitere Informationen finden Sie unter WieDevSecOps Pipelines verwenden Repositorien.

Hinweise zum gemeinsamen Konfigurationsrepository

DerDevSecOps Beispielanwendungen werden mit einem co-lokalisierten geliefert.pipeline-config.yaml Konfigurationsdatei und entsprechende Skripte. Beim Onboarding mehrerer Microservices ist es eine bewährte Methode, Quellcode-Repositorys zu trennen vonDevSecOps Konfigurationsdateien und Skripte. Speichern Sie diese in einem separaten und dedizierten allgemeinen Konfigurationsrepository, das von Ihren CI-, CD-oder CC-Pipelines verwendet werden kann.

Diese besteht aus:

Ein dediziertes Git-Repository zum Hosten einer allgemeinen Scriptbibliothek und einerpipeline-config.yaml-Datei (en).
Eine einzelne Dateipipeline-config.yaml, die allen Services gemeinsam ist. Wenn es zu komplex oder nicht möglich ist, verwenden Sie andere.pipeline-config.yaml-Dateien.
Anpassung auf Ordnerbasis. Implementieren Sie Ihrepipeline-config.yaml-Datei (en), um auf verschiedene Scriptordner in Ihrem Konfigurationsrepository zu verweisen. Organisieren Sie Ihre Scripts in separaten CI-, CD-und CC-Ordnern oder auf der Basis der Servicesprache (Go, Python, NodeJS), des Service, des Anwendungsnamens oder auf der Basis Ihrer Anforderungen.

Ändern Sie Ihre Pipeline(s), um dieses gemeinsam genutzte Konfigurations-Repository zu verwenden, indem Sie den Wert der Pipeline-Eigenschaft pipeline-config-repo (optional pipeline-config-branch ) auf das gemeinsam genutzte Konfigurations-Repository URL setzen.

Hinweise zum Bestandsrepository

Ein einzelnes Bestandsrepository kann von vielen Pipelines und Toolchains gemeinsam genutzt werden. Mehrere CI-Toolchains, -Pipelines und -Auslöser können zu demselben Bestandsrepository beitragen. CI-Pipelines übertragen Aktualisierungen per Push-Operation an das Bestandsrepository, normalerweise während der Releasephase. Das Bestandsrepository wird dann als Quelleneingabe für die CD-Pipeline verwendet. Im Allgemeinen ist es ein bewährtes Verfahren, Bestandsrepositorys in derselben Toolchain zu gruppieren, um die Anzahl der Änderungsanforderungen zu reduzieren, die letztendlich erstellt werden.

Die Verwendung eines Repositorys für gemeinsam genutzten Bestand ist eine Architekturentscheidung, die getroffen werden muss, bevor Sie mit dem Onboarding von Mikroservices beginnen, da sich diese Entscheidung auf die Anzahl der Änderungsanforderungen auswirkt, die bei der Ausführung einer Pipeline erstellt werden. Nehmen wir zum Beispiel an, Sie möchten 10 Microservices integrieren, umDevSecOps. Sie können 10 verschiedene CD-Toolchains mit 10 verschiedenen Bestandsrepositorys haben, was bei jeder Ausführung einer CD-Pipeline zu 10 verschiedenen Änderungsanforderungen führt. Es ist einfacher, diese 10 verschiedenen Mikroservices zu verwalten, wenn sie ein gemeinsames Bestandsrepository und eine gemeinsame CD-Toolchain nutzen. Dies führt nur zu einer einzigen Änderungsanforderung, selbst wenn Sie Aktualisierungen an mehreren Mikroservices vornehmen, da sie alle das Bestandsrepository und die Toolchain gemeinsam nutzen.

Hinweise zum Problemrepository

In Ihrem Problemrepository werden alle Schwachstellenprobleme für Ihre Mikroservices verfolgt. Wenn Sie ein Repository für gemeinsam genutzten Bestand verwenden möchten, können Sie auch ein Repository für gemeinsam genutzte Probleme verwenden.

Wenn Sie incident-assigness und incident-labels auf Pipeline-oder Auslöserebene festlegen, können Sie die Ausgabe automatisch dem richtigen Team zuweisen. Weitere Informationen finden Sie unter Continuous Deployment-Parameter.

Hinweise zu IBM Cloud Object Storage

Wenn Sie ein gemeinsames Inventar-Repository verwenden, können Sie auch eine gemeinsame Instanz von IBM Cloud® Object Storage verwenden. Führen Sie die folgenden Schritte aus:

Erstellen Sie eine -Instanz von IBM Cloud Object Storage für die Verwendung in Toolchains und Pipelines.
Richten Sie gegebenenfalls Pipelines und Auslöser für die Verwendung des Buckets IBM Cloud Object Storage ein, indem Sie die Umgebungseigenschaft cos-bucket-name festlegen.

Alle Microservices innerhalb der gleichen CI-, CD- und CC-Pipelines teilen sich einen Object Storage Bucket, unabhängig von der Bereitstellungsumgebung. Der Object Storage Bucket funktioniert ähnlich wie das Evidence Repository, jedoch ohne die Leistungsprobleme, die bei einem umfangreichen Evidence Repository auftreten können. Da bei einem umfangreichen Object Storage Bucket keine Leistungsprobleme auftreten, brauchen Sie keine Beweise aus Object Storage Buckets zu entfernen.

Object Storage eimer-Granularität

DevSecOps pipelines haben keine Meinung über die Granularität von Object Storage Buckets. Technisch gesehen könnten Sie einen einzigen Object Storage Bucket für Ihr gesamtes Unternehmen verwenden. Die Granularität sollte jedoch nicht kleiner als ein Inventar sein, da das Inventar die kleinste logische Gruppierung von Microservices ist, die sich gemeinsam bewegen können.

In der Praxis hängt die Granularität von dem Betriebsmodell ab, das Ihr Compliance-Team für die Verwaltung der Compliance-Daten wünscht:

Wenn das Compliance-Team in der Lage ist, mehrere Object Storage Buckets mit unterteilten Daten zu verwalten, ist dies ein praktikables Modell.
Wenn sie es vorziehen, einen einzigen größeren Object Storage Bucket mit nicht unterteilten Daten zu verwalten, ist auch das möglich.

Ein wichtiger Aspekt: Der Object Storage Bucket (Asservatenkammer) soll systemlesbar und nicht menschenlesbar sein. Es unterstützt keine Ordnerstrukturen, die nach Repository, Microservice, Produkt oder Organisation organisiert sind, und wird dies auch in absehbarer Zukunft nicht tun. Es bleibt eine abgeflachte Struktur von Vermögenswerten und Belegen.

Überlegungen zu Sicherheit und Zugang

Weniger granulare Object Storage Buckets erhöhen den Explosionsradius im Falle eines Sicherheitsverstoßes (z. B. durch die Preisgabe eines Object Storage API-Schlüssels). Es kann auch zu Problemen mit der gegenseitigen Sichtbarkeit führen, wenn ein vertikales Produkt potenziell die Compliance-Daten eines anderen lesen kann, wenn sie denselben Eimer nutzen.

Hinweise zur Migration

Es gibt Möglichkeiten, bei Bedarf über Object Storage Buckets hinweg zu migrieren. Dies beinhaltet in der Regel die Konfiguration bestimmter Umgebungseigenschaften für einen Backup-Bucket Object Storage und den Neuaufbau von CI-Komponenten. Weitere Informationen finden Sie in dieser Dokumentation. Diese Vorgänge sind jedoch als einmalige Migrationsaktivitäten gedacht und nicht als Teil der täglichen Arbeitsabläufe.

Empfohlener Ansatz

Verwenden Sie einen Object Storage Bucket pro logischer Produktgruppierung, deren Compliance-Daten zusammengeführt werden müssen. Zum Beispiel:

Serviceteam A (einschließlich aller darin enthaltenen Trupps) teilt sich Object Storage Eimer A
Serviceteam B (einschließlich aller darin enthaltenen Trupps) teilt sich Object Storage Bucket B

Dieser Ansatz schafft ein Gleichgewicht zwischen der Einfachheit des Betriebs und den Anforderungen an Sicherheit und Zugangskontrolle.

In mehreren Umgebungen implementieren

Die Bereitstellung in mehreren Zielumgebungen mit der CD-Pipeline kann auf verschiedene Arten erreicht werden.

Jede targeted environment sollte über eine entsprechende Verzweigung im Bestandsrepository verfügen, in der Änderungen von einer source in eine target-Verzweigung hochgestuft werden.

Die folgenden optionalen Designs passen möglicherweise zu Ihrer Architektur:

Verwenden Sie einen manuellen Auslöser pro Zielumgebung. Duplizieren Sie einen Auslöser und bearbeiten Sie anschließend die Umgebungseigenschaften so, dass sie der neuen Umgebung entsprechen.
Verwenden Sie ein Git-Konfigurationsrepository mit einem Ordner pro Zielumgebung, in dem bestimmte Konfigurationseinstellungen in Dateien gespeichert werden.

Mit Standardscripts und angepassten Scripts arbeiten

Die meisten Sicherheits-und Konformitätsscripts enthalten Standardscripts, die ausgeführt werden, wenn für eine Phase keine angepassten Scripts bereitgestellt werden. Es kann manchmal schwierig sein, zu bestimmen, welches Script ausgeführt wird, wo sich das entsprechende Quellenscript befindet und wie die Standardscripts überschrieben werden.

Auszuführendes Script ermitteln

Um festzustellen, welches Script für eine Phase ausgeführt wird, öffnen Sie die Pipelineausführung (vorzugsweise eine CI-Pipeline). Erweitern Sie eine Task und klicken Sie anschließend auf run-stage, um die Protokolle zu öffnen. Der Anfang der run-stage-Protokolle enthält Informationen zu den Scripts, die in der Stage verwendet wurden, einschließlich des Repositorys, in dem sich das Script befindet. In den Protokollen können Sie blättern, um weitere Details zu den ausgeführten Scripts anzuzeigen. Die Task code-compliance-checks kann beispielsweise die folgenden Informationen im Protokoll run-stage enthalten, die Umgebungseigenschaften für die Phase enthalten:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script:
    #!/bin/sh

    "/opt/commons/compliance-checks/run.sh"

In diesem Beispiel wird das Script /opt/commons/compliance-checks/run.sh ausgeführt, das sich in der commons-Bibliothek befindet. Verwenden Sie diese Commons-Bibliothek als Quelle zum Kopieren von Code, der für bestimmte Edge-Fälle angepasst werden kann. Im Beispiel befindet sich compliance-checks/run.sh in der Bibliothek compliance-commons.

Standardscripts überschreiben

Führen Sie die folgenden Schritte aus, um Standardscripts zu überschreiben:

Kopieren Sie im Stageprotokoll das Snippet, das ein Standardscript angibt:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script:
    #!/bin/sh

    "/opt/commons/compliance-checks/run.sh"

Fügen Sie das Snippet in Ihre Datei .pipeline-config.yaml ein.
Fügen Sie Ihren angepassten Code vor oder nach dem Aufrufen des Scripts hinzu. Dieser Ausschnitt ruft das Standard-Skript für die Konformitätsprüfung auf
Bearbeiten, löschen oder fügen Sie bei Bedarf Eigenschaften hinzu.

Das folgende Beispiel zeigt das aktualisierte Script in Ihrer Datei .pipeline-config.yaml:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script: |
    #!/bin/sh
    # run some custom script here
    ./scripts/my-custom-script1.sh

    "/opt/commons/compliance-checks/run.sh"

    # then some additional work
    ./scripts/my-custom-script2.sh

Weitere Informationen finden Sie unter Angepasste Scripts.

Zu verwendende Terraform-VorlagenDevSecOps Toolchains als Code

Die folgenden Toolchains bieten Code zum ErstellenDevSecOps CI-, CD- und CC-Toolchains mit Terraform:

Der frühe Zugriff auf diese Terraform-Toolchains wird unverändert bereitgestellt. Diese Toolchains befinden sich in der aktiven Entwicklung, sodass sich Variablen und Variablennamen ändern können.