Verwendung von Integrationen von Geheimnissen in Ihren Toolchains

Die Funktionen zur Verwaltung von Geheimnissen, die in den Benutzeroberflächen für die Einrichtung der Toolchain und der Pipeline zur Verfügung stehen, ermöglichen die Auswahl von in einem Tresor gespeicherten Geheimnissen mit Hilfe der Integration von Geheimnissen für IBM Cloud® Secrets Manager, IBM® Key Protect oder HashiCorp Vault. Mit dem Dialogfeld "Secrets Picker" kann ein Toolchain- oder Pipeline-Editor benannte Secrets aus einer gebundenen Secrets-Integration auswählen, die entweder nach CRN (Cloud Resource Name) oder nach Name konfiguriert ist, die dann zur Laufzeit innerhalb der Toolchain und Pipeline per Referenz aufgelöst wird. Nach der Auswahl eines Geheimnisses wird eine CRN oder ein kanonischer Verweis auf ein Geheimnis in die entsprechende sichere Eigenschaft der Toolchain oder Pipeline eingefügt, wobei das Format entweder crn:v1:...secret:<secret-guid> ist, wenn es sich um eine Secrets Manager-Integration handelt, die nach CRN konfiguriert ist, oder alternativ {vault::integration-name.secret-name}, wenn es sich um eine Tresorintegration handelt, die einen der unterstützten Anbieter verwendet und nach Name konfiguriert ist.

Das kanonische Referenzformat nach Name löst derzeit kein Geheimnis auf, das das Zeichen "Punkt" im Namen des Geheimnisses enthält, da dieses Zeichen verwendet wird, um jeden Abschnitt des kanonischen Pfades abzugrenzen.

Unabhängig davon, welche Art von Geheimreferenz verwendet wird, entweder nach CRN oder nach Name, verwenden die Komponenten der Front-End-Benutzeroberfläche und der Secrets Picker Dialog nur eine Geheimreferenz. Der aufgelöste Wert eines geheimen Verweises nach CRN oder nach Name wird niemals dem Front-End offengelegt und wird immer dynamisch zur Laufzeit innerhalb einer Toolchain und Pipeline aufgelöst, basierend auf einer zulässigen Autorisierung, die verfügbar ist (konfiguriert durch die Verwendung von IAM-Autorisierungen und Zugriffsrichtlinien).

Innerhalb von IBM Cloud® wird der dynamische Prozess der Auflösung von nach CRN und nach Name-Geheimnisreferenzen in Toolchains und Pipelines durchgeführt, indem interne virtuelle private Endpunkte (VPE) zu allen IBM Cloud® Secrets Manager und IBM® Key Protect Provider-Instanzen in allen Regionen. Dadurch wird sichergestellt, dass alle Anfrage- und Antwortdaten zwischen Toolchains, Pipelines und IBM Cloud® Secrets Manager und IBM® Key Protect Anbieterinstanzen innerhalb des begrenzten privaten IBM Cloud Netzwerks bleiben und nicht über öffentliche Netzwerkkanäle übertragen werden.

Neben der manuellen Auswahl der einzelnen Geheimnisse aus den Integrationen gebundener Geheimnisse in einer Toolchain gibt es auch die Möglichkeit, ein Secret Hint zu verwenden. Mit dieser Option kann eine Toolchain-Vorlage mit vorgeschlagenen Geheimnamen (auch bekannt als Hints) vordefiniert werden, die eine Kurzform eines Geheimverweises darstellen. Das Format eines geheimen Hinweises ist {vault::secret-name}, wobei kein geheimer Integrationsname enthalten ist. Dies bietet dem Autor der Toolchain insofern Flexibilität, als dass alle erforderlichen Geheimnamen in ein toolchain.yml vorausgefüllt werden können und diese Namen dann automatisch gegen die für die Toolchain konfigurierten Geheimhaltungsintegrationen aufgelöst werden.

Wie bereits beschrieben, können Sie Secrets Manager konfigurieren, um Geheimnisse nach CRN zu referenzieren. Weitere Informationen finden Sie unter Cloud Resource Names(CRN). Dieses Format bietet mehr Flexibilität, da Sie auf Geheimnisse aus einer Secrets Manager-Instanz in einem anderen Konto verweisen können, wenn die richtige Autorisierung vorhanden ist. Weitere Informationen finden Sie unter Konfiguration von Secrets Manager.

Hint ist ein vorgeschlagener Standardname, der automatisch mit dem ersten übereinstimmenden Geheimnis mit demselben Namen in allen verfügbaren, an die Toolchain gebundenen Integrationen von Namensgeheimnissen abgeglichen wird.

Geheime Schlüssel für DevSecOps-Pipeline

Die Geheimnisse, die sowohl bei CI als auch bei CD verwendet werden, werden im Folgenden beschrieben:

DevSecOps Geheimnisse

Secret	Tipp	Informationen
IBM Cloud-API-Schlüssel	ibmcloud-api-key	Erforderlich: CI & CD Dient zur Authentifizierung bei IBM public cloud und zur Durchführung einer Vielzahl von Vorgängen
Privater GPG-Schlüssel	signing_key	Erforderlich: Nur CI Dies ist das Zertifikat, das zum Signieren von Bildern verwendet wird, die von der CI-Pipeline erstellt wurden
API-Schlüssel für IBM Private Worker Service	private-worker-service-api-key	Erforderlich: Nur CI Ein Service-ID-API-Schlüssel, der zur Ausführung von Delivery-Pipeline-Workloads auf einem privaten Worker-Service von Tekton verwendet wird
GitHub-Zugriffstoken	git-token	Optional: CI & CD Dient zur Authentifizierung bei GitHub und ermöglicht den Zugriff auf die Repositories
Artifactory API-Token	artifactory-token	Erforderlich: CI & CD Verwendet für den Zugriff auf Bilder, die von Pipeline-Aufgaben verwendet werden
Slack-Webhook	slack-webhook	Optional: CI & CD Dieser Webhook ist erforderlich, wenn Sie die Slack-Tool-Integration verwenden möchten, um Toolchain-Statusbenachrichtigungen zu posten
ServiceNow API-Token	servicenow-api-token	Erforderlich: Nur CD Wird für den Zugriff auf Service Now für Änderungsmanagementvorgänge benötigt
HashiCorp Vault-Rollen-ID	role-id	Erforderlich: CI & CD Wird zur Authentifizierung beim HashiCorp Vault-Server verwendet
ID des geheimen HashiCorp Vault-Schlüssels	secret-id	Erforderlich: CI & CD Wird zur Authentifizierung beim HashiCorp Vault-Server verwendet
IBM Cloud Object Storage-Writer-API-Schlüssel	cos-api-key	Erforderlich: CI & CD Wird verwendet, um sich beim Object Storage-Dienst zu authentifizieren - Dieser Schlüssel muss die writer Erlaubnis haben
SonarQube-Kennwort oder -Authentifizierungstoken	sonarqube-password	Optional: CI Wird zur Authentifizierung beim SonarQube source code analyzer verwendet

Wenn Sie einen HashiCorp Vault-Server verwenden, stellen Sie sicher, dass die HashiCorp Vault-Tool-Integration die Methode AppRole Auth Method verwendet. Wenn Sie die Authentifizierungsmethode AppRole verwenden, benötigen Sie role-id und secret-id, um den Vault-Server HashiCorp erfolgreich in die Toolchain zu integrieren. Da es sich bei role-id und secret-id um Geheimnisse handelt, wird empfohlen, sie mit Hilfe einer IBM Key Protect Tool-Integration zu speichern, damit sie sicher abgerufen und im Workflow der Toolchain angewendet werden können. Alle anderen Toolchain-Geheimnisse sollten mit Hilfe der HashiCorp Vault Toolintegration gespeichert und abgerufen werden.

Wenn die Pipeline-Umgebungseigenschaft git-token nicht festgelegt ist, wird standardmäßig ibmcloud-api-key verwendet, um das Git Repos and Issue Tracking Access Token abzurufen. Falls ibmcloud-api-key jedoch keinen Zugriff auf git hat, muss git-token angegeben werden.

Speicher für geheime Schlüssel konfigurieren

Mit IBM Cloud können Sie aus verschiedenen Angeboten zur Verwaltung von Geheimnissen und zum Datenschutz wählen, die Ihnen helfen, Ihre sensiblen Daten zu schützen und Ihre Geheimnisse zu zentralisieren. Sie können je nach Ihren Anforderungen zwischen den Tresorintegrationen wählen, wie in Verwaltung von IBM Cloud Geheimnissen erläutert. Diese Dokumentation enthält Informationen über die Voraussetzungen und die Verwendung einer Liste vorgeschriebener Geheimnamen, die auch als Hinweise bezeichnet werden. Durch die Verwendung von Hinweisen in einer Vorlage kann eine Toolchain automatisch mit vorkonfigurierten geheimen Schlüsseln gefüllt werden, d. h. die geheimen Schlüssel müssen nicht manuell aus den Vault-Integrationen ausgewählt werden, die an die Toolchain angehängt sind.

Verwenden Sie IBM Cloud® Secrets Manager um Geheimnisse wie API-Schlüssel, Bildsignatur oder HashiCorp Vault-Anmeldeinformationen, die Teil Ihrer Toolchain sind, sicher zu speichern und anzuwenden.

Die Vorlagen enthalten auch eine HashiCorp Vault-Tool-Integration wie das folgende Beispiel:

Um HashiCorp Vault zu nutzen, müssen Sie die folgenden Informationen angeben:

Name

Ein Name für diese Werkzeugintegration. Dieser Name wird in der Toolchain angezeigt.

Server-URL

Der Server URL für Ihre HashiCorp Vault-Instanz. Beispiel: https://<vault-service>.<org>.com:8200.

Integration URL

Die URL, zu der Sie navigieren möchten, wenn Sie auf die Kachel HashiCorp Vault Integration klicken.

Pfad der Geheimnisse

Der Mount-Pfad, in dem Ihre Geheimnisse in Ihrer HashiCorp Vault-Instanz gespeichert sind.

Authentifizierungsmethode

Die Authentifizierungsmethode für Ihre HashiCorp Vault-Instanz. Verwenden Sie AppRole.

Rollen-ID

Kennung, die die AppRole auswählt, gegen die die anderen Berechtigungsnachweise ausgewertet werden.

ID des geheimen Schlüssels

Berechtigungsnachweis, der standardmäßig für jede Anmeldung erforderlich ist (mit secret_id) und immer geheim sein soll.

Die Vorlagen enthalten auch eine IBM® Key Protect for IBM Cloud® Tool-Integration:

Wenn Sie die role id und secret id im Voraus in Key Protect gespeichert haben, können Sie die Key Protect-Instanz, die diese Geheimnisse enthält, in der Werkzeugkarte auswählen, wie in Abbildung 2 dargestellt. Danach können Sie auf die Schlüsselsymbole in den Feldern Rollenkennzeichen und Geheimniskennzeichen in der Werkzeugkarte HashiCorp Tresor klicken und die Geheimnisse mit Hilfe der Auswahlfunktion auf diese Felder anwenden.

Auch alle anderen Geheimnisse, die in der Toolchain verwendet werden, haben ein Schlüsselsymbol, das mit dem Textfeld verbunden ist. Sie können die gleiche Auswahlsteuerung verwenden, um die HashiCorp Vault-Geheimnisse auf alle übrigen Instanzen anzuwenden.