geheime Schlüssel in Ihren Toolchains verwalten

Tool-Integrationen in Ihren CI- und CD-Toolchains erfordern Geheimnisse, zum Beispiel Passwörter, API-Schlüssel, Zertifikate oder andere Token. Mit einem IBM Cloud® API-Schlüssel können beispielsweise grundlegende Pipeline-Aufgaben wie die Anmeldung bei IBM Cloud durchgeführt werden. Ebenso schreibt der API-Schlüssel für die Service-ID Angaben in das Bucket in der Cloud Object Store-Instanz.

Aus Sicherheitsgründen dürfen diese geheimen Schlüssel die Identität oder das Konto einer Person nicht offenbaren, da Personen häufig größere Zugriffsberechtigungen als die eigentliche Toolchain-Automatisierungsanforderung haben. Die Zugehörigkeit zur Identität oder zum Konto einer Person würde ebenfalls gegen das Sicherheitsprinzip "geringste Berechtigung"verstoßen. Außerdem wechseln Mitarbeiter häufig die Rolle oder sogar das Unternehmen, und ihre Anmeldedaten müssen entfernt werden, was die Automatisierung der Toolchain unterbrechen könnte. Durch die Verwendung einer Identität, die speziell für Automatisierungszwecke angegliedert ist, wird eine Trennung der Aufgaben zwischen der Automatisierung und den Personen, die die Automatisierung nutzen, erreicht.

Stattdessen müssen die Geheimnisse, die für Ressourcen verwendet werden, die nicht zu IBM Cloud gehören (z. B. GitHub Enterprise ), mit einer funktionalen ID innerhalb Ihres Unternehmens verknüpft werden, auf die nur die Toolchains Zugriff haben, die sie benötigen. Ebenso müssen Geheimnisse für IBM Cloud-Ressourcen mit einem IAM-Service-ID-API-Schlüssel verknüpft sein, der mit einer IAM-Service-ID verknüpft ist. Die Zugriffsberechtigungen für die IAM-Service-ID müssen auf die geringsten von den Toolchains benötigten Privilegien beschränkt werden.

Die Verwaltung solcher Berechtigungsnachweise muss sicher und in Übereinstimmung mit den Best Practices für die Verwaltung geheimer Schlüssel erfolgen. Dies bedeutet insbesondere, dass Sie die erforderlichen Geheimnisse mit Hilfe eines zugelassenen Tresoranbieters innerhalb der Landesgrenzen, wie IBM Cloud® Secrets Manager, IBM® Key Protect oder HashiCorp Vault und dann Ihre Toolchain-Geheimnisse mit diesen Ressourcen zu verknüpfen.

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 verschlüsselten Geheimnissen durch die Verwendung der Integration von Geheimnissen für IBM Cloud® Secrets Manager, IBM® Key Protect oder HashiCorp Vault. Mithilfe des Auswahldialogs für geheime Schlüssel kann ein Toolchain-oder Pipeline-Editor benannte geheime Schlüssel aus einer gebundenen geheimen Schlüssel-Integration auswählen, die entweder durch CRN (Cloudressourcenname) oder durch den Namen konfiguriert ist, die dann durch Referenz zur Laufzeit innerhalb der Toolchain und Pipeline aufgelöst wird. Nachdem ein geheimer Schlüssel ausgewählt wurde, wird eine Referenz auf einen CRN oder einen kanonischen geheimen Schlüssel in die entsprechende sichere Eigenschaft der Toolchain oder Pipeline injiziert, wobei das Format crn:v1:...secret:<secret-guid> lautet, wenn es sich um eine Secrets Manager-Integration handelt, die durch CRN konfiguriert ist, oder alternativ {vault::integration-name.secret-name}, wenn es sich um eine Vaultintegration handelt, die einen der unterstützten Provider verwendet und nach Namen konfiguriert ist.

Das kanonische Referenzformat nach Name löst momentan keinen geheimen Schlüssel auf, der den Punkt im Namen des geheimen Schlüssels enthält, da dieses Zeichen verwendet wird, um die einzelnen Abschnitte des kanonischen Pfads zu begrenzen.

Unabhängig davon, welcher Typ von Referenz auf geheime Schlüssel verwendet wird ( nach CRN oder nach Name), verwenden die Front-End-Benutzerschnittstellenkomponenten und der Auswahldialog für geheime Schlüssel nur eine Referenz auf geheime Schlüssel. Der aufgelöste Wert einer Referenz auf einen geheimen Schlüssel nach CRN oder nach Name wird nie dem Front-End zugänglich gemacht und immer dynamisch zur Laufzeit in einer Toolchain und Pipeline aufgelöst, basierend auf einer zulässigen Autorisierung, die verfügbar ist (konfiguriert mithilfe von IAM-Autorisierungs-und Zugriffsrichtlinien).

Innerhalb von IBM Cloud® wird der dynamische Prozess der Auflösung von CRN- und Namensgeheimnisreferenzen in Toolchains und Pipelines unter Verwendung interner virtueller privater Endpunkte (VPE) zu allen IBM Cloud® Secrets Manager und IBM® Key Protect Anbieterinstanzen in allen Regionen durchgeführt. 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 Einzelauswahl ausgewählter geheimer Schlüssel aus allen gebundenen Integrationen geheimer Schlüssel in einer Toolchain ist auch die Option zur Verwendung von Secret Hint verfügbar. Mit dieser Option kann eine Toolchain-Vorlage mit vorgeschlagenen Namen für geheime Schlüssel (auch bekannt als Hints) vordefiniert werden, die eine Referenz für geheime Schlüssel in Kurzform sind. Das Format eines geheimen Hinweises ist {vault::secret-name}, wobei kein Name für die Integration geheimer Schlüssel enthalten ist. Dies bietet dem Toolchain-Autor Flexibilität, da alle erforderlichen Namen geheimer Schlüssel vorab in eine toolchain.yml eingetragen werden können und diese Namen dann automatisch anhand der für die Toolchain konfigurierten Integrationen geheimer Schlüssel aufgelöst werden.

Wie zuvor beschrieben, können Sie Secrets Manager konfigurieren, um über CRN auf geheime Schlüssel zu verweisen. Weitere Informationen finden Sie unter Cloud Resource Names(CRN). Dieses Format ermöglicht eine größere Flexibilität, da Sie auf geheime Schlüssel aus einer Secrets Manager-Instanz in einem anderen Konto verweisen können, wenn die richtige Berechtigung vorhanden ist. Weitere Informationen finden Sie unter Secrets Manager.

Die Geheimnisse, die sowohl bei CI als auch bei CD zum Einsatz kommen, werden im Folgenden beschrieben:

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

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 Für den Zugriff auf Images, die von Pipelinetasks 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 Änderungsmanagementoperationen verwendet
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 Für die Authentifizierung beim Object Storage-Service verwendet-Dieser Schlüssel muss über die Berechtigung `writer` verfügen.
IBM Cloud Object Storage Reader-API-Schlüssel	`backup-cos-api-key`	Erforderlich: CI & CD Für die Authentifizierung beim Object Storage-Service verwendet-Dieser Schlüssel muss über die Berechtigung `Reader` verfügen.
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 Server HashiCorp Vault 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 abhängig von Ihren Anforderungen zwischen den Vaultintegrationen wählen, wie in Geheime Schlüssel für IBM Cloud verwalten beschrieben. 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 zum sicheren Speichern und Anwenden von Geheimnissen wie API-Schlüsseln, Bildsignaturen oder HashiCorp Vault-Berechtigungsnachweisen, die Teil Ihrer Toolchain sind.

Secrets Manager-Toolintegrationsformular — IBM Secrets Manager Toolintegration

Die Vorlagen werden auch mit einer HashiCorp Vault Tool-Integration wie dem folgenden Beispiel geliefert:

HashiCorp Vault Formular zur Toolintegration mit Pflichtfeldern und Beispielwerten Formular zur Toolintegration mit Pflichtfeldern und Beispielwerten Toolintegration — HashiCorp Vault

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

Name: Ein Name für diese Toolintegration. Dieser Name wird in der Toolchain angezeigt.
Server-URL: Die Server-URL für Ihre HashiCorp Vault-Instanz. Beispiel: https://<vault-service>.<org>.com:8200.
Integrations-URL: Die URL, zu der Sie navigieren möchten, wenn Sie auf die Kachel der HashiCorp Vault-Integration klicken.
Pfad für geheime Schlüssel: Der Mountpfad, in dem Ihre geheimen Schlüssel in Ihrer HashiCorp Vault-Instanz gespeichert werden.
Authentifizierungsmethode: Die Authentifizierungsmethode für Ihre HashiCorp Vault-Instanz. Verwenden Sie AppRole.
Rollen-ID: Die ID zum Auswählen der 'AppRole', die zum Auswerten der anderen Berechtigungsnachweise verwendet wird.
Geheime ID: 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®-Toolintegration:

Key Protect Tool-Integrationsformular mit erforderlichen Feldern und Beispielwerten — IBM Key Protect Tool-Integration

Wenn Sie role id und secret id im Voraus in Key Protect gespeichert haben, können Sie die Instanz Key Protect auswählen, die diese geheimen Schlüssel in der Toolkarte enthält (siehe Abbildung 2). Danach können Sie auf die Schlüsselsymbole in den Feldern "role id" und "secret id" auf der Werkzeugkarte HashiCorp Vault 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 dieselbe Auswahlsteuerung verwenden, um die HashiCorp Vault Geheimnisse auf alle übrigen Instanzen anzuwenden.

Abrufen von Geheimnissen aus IBM Cloud Secrets Manager

Verwenden Sie den Befehl get_env, um sicher auf das Geheimnis zuzugreifen. Mit dieser Methode lässt sich das Geheimnis herausfinden, ohne dass es in den Protokollen auftaucht.

Unterstützte Typen geheimer Schlüssel

Derzeit unterstützen wir das Abrufen der folgenden Arten von Geheimnissen aus den Umgebungseigenschaften in Secrets Manager:

Beliebig
IAM-Berechtigungsnachweise
Schlüsselwert

Verwendung:

  export SECRET_VALUE=$(get_env "secret_key" "")

Beispiel:

secret_key ist der Name, unter dem das Geheimnis gespeichert wird.
SECRET_VALUE enthält den abgerufenen geheimen Wert zur späteren Verwendung.

Je nach Art des Geheimnisses ruft get_env bestimmte Werte ab:

Abrufen beliebiger Geheimnisse

  {
    "name": "my-secret",
    "secret_type": "arbitrary",
    ...
    "payload": "The quick brown fox jumped over the lazy dog."
  }

Wenn get_env mit my-secret verwendet wird, wird der Wert payload abgerufen.

Abrufen von iam_credentials Secret

  {
    "name": "my-iam-credentials",
    "secret_type": "iam_credentials",
    ...
    "api_key": "RmnPBn6n1dzoo0v3kyznKEpg0WzdTpW9lW7FtKa017_u",
    "api_key_id": "ApiKey-dcd0b857-b590-4507-8c64-ae89a23e8d76",
    "service_id": "ServiceId-bb4ccc31-bd31-493a-bb58-52ec399800be"
  }

Wenn get_env mit my-iam-credentials verwendet wird, wird api_key abgerufen.

Abrufen von Schlüsselwerten Geheimnis

  {
    "name": "my-kv-secret",
    "secret_type": "key-value",
    ...
    "data": "{\"key\":\"value\"}"
  }

Wenn get_env mit my-kv-secret verwendet wird, wird value innerhalb des Schlüssel-Wert-Paares abgerufen