IBM Cloud Docs
Daten in Continuous Delivery schützen

Daten in Continuous Delivery schützen

IBM Cloud® Continuous Delivery hostet Ihre Datenbanken in einer hoch verfügbaren und sicheren Umgebung:

  • Daten werden als ruhende Daten (GPFS, LUKS und integrierte Platte) sowie bei der Übertragung (HTTPS und SSH) mithilfe von Verschlüsselungsschlüsseln verschlüsselt. Hierbei handelt es sich um interne Schlüssel des Continuous Delivery-Service oder der Services bzw. der Infrastruktur, von denen er abhängig ist.
  • Personenbezogene Daten können nur im Professional-Tarif verschlüsselt werden, indem ein Stammschlüssel innerhalb einer Instanz des IBM® Key Protect for IBM Cloud®-Dienstes oder des IBM Cloud® Hyper Protect Crypto Services-Dienstes verwendet wird.
  • Client- und Systemberechtigungsnachweise werden auf verschlüsselten Platten gespeichert.
  • Konfigurationsdaten für Toolintegrationen und Delivery Pipeline-Eigenschaftswerte können sensible Informationen enthalten. Diese Daten werden mithilfe von Verschlüsselungsschlüsseln verschlüsselt, bei denen es sich um interne Schlüssel des Continuous Delivery-Service handelt, da diese Daten in internen Datenbanken dieses Service gespeichert werden.
  • Die Anwendung und die Daten sind für hohe Verfügbarkeit konfiguriert.
  • Der Zugriff auf Daten ist ausschließlich auf die Benutzer begrenzt, die die Daten zur Unterstützung und Wartung des Service benötigen.

Sensible Daten in Continuous Delivery schützen

Der Continuous Delivery-Service verschlüsselt kundeneigene sensible Daten, bevor sie in Datenbanken gespeichert werden, die der Service intern verwendet. Zu den sensiblen Daten gehören Konfigurationsdaten für die Integration von Tools anderer Anbieter und Delivery Pipeline-Eigenschaftswerte. Die Daten werden mit internen Verschlüsselungsschlüsseln des Dienstes Continuous Delivery oder mit Verschlüsselungsschlüsseln des Stammschlüssels verschlüsselt, der in einer Instanz des Dienstes IBM® Key Protect for IBM Cloud® oder des Dienstes IBM Cloud® Hyper Protect Crypto Services angegeben ist.

DevOps-Prozesse erfordern oft verschiedene Typen von Berechtigungsnachweisen (z. B. Benutzernamen und Kennwörter, API-Schlüssel, Serviceschlüssel und SSH-Schlüssel), um mit anderen Systemen zu interagieren, um Anwendungen zu erstellen, zu testen und bereitzustellen. Sie sind dafür verantwortlich, sicherzustellen, dass diese Berechtigungsnachweise nicht versehentlich außerhalb der gewünschten Zielgruppe geteilt werden. Der Zugriff auf diese Berechtigungsnachweise durch böswillige Akteure kann Ihren IT-Betrieb unterbrechen, unerwartete Kosten verursachen und dazu führen, dass Ihre Ressourcen verwendet werden, um Angriffe zu starten. IBM ist nicht verantwortlich für den Schutz und die Verwaltung der Sicherheit Ihrer Berechtigungsnachweise.

Um Ihre Berechtigungsnachweise langfristig zu sichern, müssen Sie diese Anweisungen befolgen:

  • Speichern Sie keine Berechtigungsnachweise in Git-Repositorys. Abhängig von den Repository-Einstellungen sind Dateien in einem Repository möglicherweise für andere Mitglieder Ihrer Organisation, andere IBM Cloud-Benutzer oder öffentlich im Internet sichtbar.
  • Schließen Sie keine Benutzerberechtigungen in Delivery Pipeline-Definitionen ein, weil sie möglicherweise für andere Benutzer sichtbar sind. Schließen Sie insbesondere keine Benutzerberechtigungen in Delivery Pipeline Classic-Jobdefinitionsscripts, in Delivery Pipeline Tekton-YAML-Dateien oder in Scripts ein, die von Delivery Pipelines gestartet werden.
  • Veröffentlichen Sie keine Benutzerberechtigungen in Protokolldateien, die erstellt werden, wenn eine Pipeline ausgeführt wird, da diese Dateien möglicherweise geteilt werden.
  • Geben Sie keine Berechtigungsnachweise in Klartext in Aufrufen an Continuous Delivery-APIs an, z. B. wenn Sie Toolintegrationen, Tekton-Pipeline-Umgebungseigenschaftenoder Tekton-Pipeline-Auslösereigenschaftenkonfigurieren.
  • Schließen Sie keine Berechtigungsnachweise, persönlichen Identifikationsinformationen oder andere sensible Informationen in Aufrufe der API POST /toolchains/{toolchain_id}/events ein. Die API sendet Ereignisse mit den Daten, die Sie angeben, an Instanzen von Event Notifications, die in die Toolchain integriert sind. Event Notifications leitet die Ereignisse anschließend an konfigurierte Ziele wie E-Mail, SMS oder Slack weiter.
  • Geben Sie in Terraform-Konfigurationsdateien keine Anmeldeinformationen im Klartext an, z. B. wenn Sie Ressourcen für die Tool-Integration, Tekton-Pipeline-Umgebungseigenschaften oder Tekton-Pipeline-Trigger-Eigenschaften definieren. Verwalten Sie stattdessen Berechtigungsnachweise in einem Speicherservice für geheime Schlüssel und geben Sie sie durch Referenz in API-Aufrufen und Terraform-Konfigurationen an. Weitere Informationen zur Verwaltung von geheimen Schlüsseln nach Referenz finden Sie unter Berechtigungsnachweise mithilfe von Referenzen auf geheime Schlüssel schützen.

IBM Cloud bietet verschiedene Optionen für die Speicherung von Sicherheitsschlüsseln und geheimen Schlüsseln.

Weitere Informationen zum Schutz von DevOps Best Practices finden Sie unter DevOps Security.

Berechtigungsnachweise mithilfe von Referenzen auf geheime Schlüssel schützen

Viele der Eigenschaften, die Sie konfigurieren können, wenn Sie mit Continuous Delivery-Toolchains und Delivery Pipelines wie Kennwörter, API-Schlüsseln, Zertifikaten oder anderen Tokens arbeiten, werden als geheime Schlüssel oder Berechtigungsnachweise klassifiziert. Um den Wert einer sicheren Eigenschaft festzulegen, können Sie entweder Klartext oder einen Verweis auf geheime Schlüssel verwenden. Die Verwendung einer Referenz auf geheime Schlüssel ist die empfohlene Methode zum Festlegen des Werts einer sicheren Eigenschaft.

Wenn Sie eine sichere Eigenschaft mit einem geheimen Wert für Klartext festlegen, wird der Wert von Continuous Delivery aktiv verschlüsselt und intern gespeichert. Obwohl der Wert im Continuous Delivery-Service sicher bleibt, kann der Service den Wert auf der Clientseite nicht schützen. Wenn Sie eine sichere Eigenschaft über die Konsole in Ihrem Browser festlegen, eine API aufrufen oder eine Terraform-Ressource konfigurieren, wird der geheime Schlüssel im Klartext möglicherweise auf Ihren lokalen Systemen zugänglich gemacht. Klartextgeheimnisse sind auch schwieriger zu rotieren. Wenn ein geheimer Schlüssel, wie z. B. ein API-Schlüssel, turnusmäßig gewechselt wird, müssen alle sicheren Eigenschaften, die den Wert des geheimen Schlüssels enthalten, ebenfalls lokalisiert und aktualisiert werden.

Wenn Sie eine sichere Eigenschaft mit einem Wert für referenz für geheime Schlüssel festlegen, ist der Wert eine speziell formatierte Zeichenfolge, die sich auf die Position oder Adresse eines geheimen Schlüssels bezieht, der in einem Speicherservice für geheime Schlüssel wie IBM® Key Protect for IBM Cloud®, IBM Cloud® Secrets Manager oder HashiCorp Vault verwaltet wird. Obwohl Continuous Delivery den Referenzwert für geheime Schlüssel intern aktiv verschlüsselt und speichert, wird der Wert für geheime Schlüssel auf der Clientseite nicht zugänglich gemacht. Wenn Continuous Delivery den geheimen Schlüssel für die Verarbeitung in Ihrem Namen abrufen muss, wird der Wert intern aus dem referenzierten Speicher für geheime Schlüssel abgerufen. Referenzen auf geheime Schlüssel sind auch gegen Rotation widerstandsfähig. Wenn ein geheimer Schlüssel in einem Speicher für geheime Schlüssel rotiert wird, bleibt die Position oder Adresse des geheimen Schlüssels in der Regel unverändert. Nur der Wert des geheimen Schlüssels selbst wird geändert.

Es werden zwei Typen von Referenzen auf geheime Schlüssel unterstützt: nach Name oder nach Cloudressourcenname. Derzeit unterstützen nur Secrets Manager-Toolintegrationen das Referenzieren von geheimen Schlüsseln nach CRN. Dieses Format ermöglicht eine größere Flexibilität, da Sie auf geheime Schlüssel von einer Secrets Manager-Instanz in einem anderen Konto verweisen können, wenn die korrekte Berechtigung vorhanden ist.

Stellen Sie sicher, dass Sie die folgenden Voraussetzungen für die Angabe einer Referenz auf geheime Schlüssel im Geltungsbereich einer Toolchain berücksichtigen:

Wenn Sie außerhalb der Konsole arbeiten, z. B. mit der API oder Terraform, verwenden Sie das folgende Format für namentliche Verweise auf Geheimnisse:

  • {vault::SECRET_STORE_INTEGRATION_NAME.SECRET_NAME}, wenn Sie auf geheime Schlüssel in Key Protectverweisen.
  • {vault::SECRET_STORE_INTEGRATION_NAME.SECRET_GROUP_NAME.SECRET_NAME} wenn Sie auf geheime Schlüssel verweisen, die in Secrets Managerenthalten sind.
  • {vault::SECRET_STORE_INTEGRATION_NAME.SECRET_NAME.FIELD_NAME} wenn Sie auf Geheimnisse verweisen, die in HashiCorp Vault enthalten sind.

Geheimer Wert:

  • ref://secrets-manager.REGION.RESOURCE-GROUP.SECRETS-MANAGER-INSTANCE-NAME1/SECRETS-GROUP-NAME/SECRET-NAME, wenn Sie auf geheime Schlüssel in Key Protectverweisen.
  • ref://secrets-manager.eu-de.EU-RG.SM-1/default/api-key wenn Sie auf geheime Schlüssel verweisen, die in Secrets Managerenthalten sind.

Handelt es sich bei dem Geheimnis beispielsweise um einen Schlüsselwert, so können Sie den Schlüssel auswählen:

  • ref://secrets-manager.eu-gb.Default.Secrets%20Manager-zc/Default/mk-kv-pair?key=ibmcloud-api-key

Dabei gilt:

  • SECRETS-MANAGER-INSTANCE-NAME1 ist der Name der Integration des Speichers für geheime Schlüssel in der Toolchain und nicht der Name der Serviceinstanz des Speichers für geheime Schlüssel.
  • SECRET_GROUP_NAME ist der Name der Gruppe, die den geheimen Schlüssel in Secrets Managerenthält.
  • SECRET_NAME ist der Name des Geheimnisses im Geheimnisspeicher.
  • KEY_NAME ist der Name des Schlüssels im Schlüssel-Wert-Geheimnis.

Wenn Sie eine Referenz auf geheime CRN-Schlüssel verwenden möchten, rufen Sie den CRN für geheime Schlüssel direkt über die Benutzerschnittstelle von Secrets Manager oder programmgesteuert über die Befehlszeilenschnittstelle, API oder SDKs ab.

Verweise auf geheime Schlüssel über die Konsole angeben

Wenn Sie die Konsole verwenden, werden die Felder für die Konfigurationseigenschaften der Toolintegration und die Delivery Pipeline-Eigenschaften, die als sicher klassifiziert sind, mit einem Schlüsselsymbol annotiert. Klicken Sie auf dieses Symbol, um ein Dialogfenster zu öffnen, in dem Sie einen Speicher für geheime Schlüssel und einen geheimen Schlüssel auswählen können. Alternativ können Sie für Referenzen auf geheime Schlüssel nach CRN den CRN-Wert direkt in die Eigenschaft einfügen.

Angeben von Referenzen auf geheime Schlüssel mit der API

Sie können mit sicheren Eigenschaften mit Referenzwerten für geheime Schlüssel in Aufrufen an die API arbeiten, die ein IAM-Trägertokenerfordert. Wenn Sie ein SDK verwenden, rufen Sie einen IAM-API-Schlüssel ab und legen Sie die Clientoptionen mithilfe von Umgebungsvariablen fest.

export CD_TOOLCHAIN_AUTH_TYPE=iam && \
export CD_TOOLCHAIN_APIKEY={iam_api_key} && \
export CD_TOOLCHAIN_URL=https://api.us-south.devops.cloud.ibm.com/toolchain/v2

Referenzen auf geheime Schlüssel nach Namen verwenden

Das folgende Beispiel veranschaulicht, wie eine Referenz auf geheime Schlüssel nach Namen verwendet wird. Es zeigt, wie eine Slack-Tool-Integration mit einem API-Token (Slack-Webhook) erstellt wird, das in einer Instanz von Key Protectgespeichert ist. Dieses Beispiel setzt voraus, dass die Toolchain bereits eine Key Protect-Toolintegration enthält und dass eine IAM-Service-zu-Service-Berechtigungsrichtlinie aus der Quellen-Toolchain für die Key Protect-Zielserviceinstanz vorhanden ist.

curl -X POST \
https://api.us-south.devops.cloud.ibm.com/toolchain/v2/toolchains/01234567-89ab-cdef-0123-456789abcdef/tools \
-H "Authorization: Bearer $TOKEN" \
-H 'Accept: application/json' \
-H 'Content-Type: application/json' \
-d '{
    "tool_type_id": "slack",
    "parameters": {
    "api_token": "{vault::my-kms-tool-integration.my-slack-webhook}",
    "channel_name": "my_slack_channel_name",
    "team_url": "my_slack_team_name"
    }
}'
const CdToolchainV2 = require('@ibm-cloud/continuous-delivery/cd-toolchain/v2');
...
(async () => {
    const toolchainService = CdToolchainV2.newInstance();
    const slackParameters = {
        api_token: "{vault::my-kms-tool-integration.my-slack-webhook}",
        channel_name: "my_slack_channel_name",
        team_url: "my_slack_team_name"
    };

    const toolPrototypeModel = {
        toolchainId: "01234567-89ab-cdef-0123-456789abcdef",
        toolTypeId: "slack",
        parameters: slackParameters
    };

    const slackTool = await toolchainService.createTool(toolPrototypeModel);
})();
import (
    "github.com/IBM/continuous-delivery-go-sdk/cdtoolchainv2"
)
...
toolchainClientOptions := &cdtoolchainv2.CdToolchainV2Options{}
toolchainClient, err := cdtoolchainv2.NewCdToolchainV2UsingExternalConfig(toolchainClientOptions)
slackParameters := map[string]interface{}{
    "api_token": "{vault::my-kms-tool-integration.my-slack-webhook}",
    "channel_name": "my_slack_channel_name",
    "team_url": "my_slack_team_name",
}
createToolOptions := toolchainClient.NewCreateToolOptions("01234567-89ab-cdef-0123-456789abcdef", "slack")
createToolOptions.SetParameters(slackParameters)
slackTool, response, err := toolchainClient.CreateTool(createToolOptions)
from ibm_continuous_delivery.cd_toolchain_v2 import CdToolchainV2
...
toolchain_service = CdToolchainV2.new_instance()
slack_parameters = {
    "api_token": "{vault::my-kms-tool-integration.my-slack-webhook}",
    "channel_name": "my_slack_channel_name",
    "team_url": "my_slack_team_name"
}
slack_tool = toolchain_service.create_tool(
    toolchain_id = "01234567-89ab-cdef-0123-456789abcdef",
    tool_type_id = "slack",
    parameters = slack_parameters
)
   import com.ibm.cloud.continuous_delivery.cd_toolchain.v2.CdToolchain;
   import com.ibm.cloud.continuous_delivery.cd_toolchain.v2.model.*;
   ...
   CdToolchain toolchainService = CdToolchain.newInstance();
   HashMap<String, Object> slackParameters = new HashMap<>();
   slackParameters.put("api_token", "{vault::my-kms-tool-integration.my-slack-webhook}");
   slackParameters.put("channel_name", "my_slack_channel_name");
   slackParameters.put("team_url", "my_slack_team_name");
   CreateToolOptions createSlackToolOptions = new CreateToolOptions.Builder()
      .parameters(slackParameters)
      .toolchainId({toolchain_id})
      .toolTypeId("slack")
      .build();
   Response<ToolchainToolPost> response = toolchainService.createTool(createSlackToolOptions).execute();
   ToolchainToolPost slackTool = response.getResult();

In der folgenden Tabelle werden alle im vorherigen Beispiel verwendeten Referenzwerte für geheime Schlüssel aufgelistet und beschrieben.

Geheime Referenzwerte
Wert Beschreibung
my-kms-tool-integration Der Name der Integration des Tools Key Protect in die Toolchain Dies ist nicht der Name der Serviceinstanz von Key Protect.
my-slack-webhook Der Name des Standardschlüssels, der in der Key Protect-Serviceinstanz verwaltet wird

Referenzen auf geheime Schlüssel durch CRN verwenden

Das folgende Beispiel veranschaulicht, wie ein Verweis auf geheime Schlüssel durch einen geheimen CRN-Schlüssel verwendet wird. Es zeigt, wie Sie eine Integration eines Slack-Tools mit einem API-Token (Slack-Webhook) erstellen, das in einer Instanz von Secrets Managergespeichert ist. In diesem Beispiel wird davon ausgegangen, dass die Toolchain bereits eine Secrets Manager-Toolintegration enthält und dass eine IAM-Service-zu-Service-Berechtigungsrichtlinie von der Quellen-Toolchain zur Secrets Manager-Zielserviceinstanz vorhanden ist.

curl -X POST \
https://api.us-south.devops.cloud.ibm.com/toolchain/v2/toolchains/01234567-89ab-cdef-0123-456789abcdef/tools \
-H "Authorization: Bearer $TOKEN" \
-H 'Accept: application/json' \
-H 'Content-Type: application/json' \
-d '{
    "tool_type_id": "slack",
    "parameters": {
    "api_token": "crn:v1:bluemix:public:secrets-manager:us-south:a/9bb43e401a7a87d15145da761da98571:604de62c-c04f-3f5e-b7e8-4acafe0ecde7:secret:5ec17023-b631-fbcb-ef9c-4f2eb01f1dda",
    "channel_name": "my_slack_channel_name",
    "team_url": "my_slack_team_name"
    }
}'
const CdToolchainV2 = require('@ibm-cloud/continuous-delivery/cd-toolchain/v2');
...
(async () => {
    const toolchainService = CdToolchainV2.newInstance();
    const slackParameters = {
        api_token: "crn:v1:bluemix:public:secrets-manager:us-south:a/9bb43e401a7a87d15145da761da98571:604de62c-c04f-3f5e-b7e8-4acafe0ecde7:secret:5ec17023-b631-fbcb-ef9c-4f2eb01f1dda",
        channel_name: "my_slack_channel_name",
        team_url: "my_slack_team_name"
    };

    const toolPrototypeModel = {
        toolchainId: "01234567-89ab-cdef-0123-456789abcdef",
        toolTypeId: "slack",
        parameters: slackParameters
    };

    const slackTool = await toolchainService.createTool(toolPrototypeModel);
})();
import (
    "github.com/IBM/continuous-delivery-go-sdk/cdtoolchainv2"
)
...
toolchainClientOptions := &cdtoolchainv2.CdToolchainV2Options{}
toolchainClient, err := cdtoolchainv2.NewCdToolchainV2UsingExternalConfig(toolchainClientOptions)
slackParameters := map[string]interface{}{
    "api_token": "crn:v1:bluemix:public:secrets-manager:us-south:a/9bb43e401a7a87d15145da761da98571:604de62c-c04f-3f5e-b7e8-4acafe0ecde7:secret:5ec17023-b631-fbcb-ef9c-4f2eb01f1dda",
    "channel_name": "my_slack_channel_name",
    "team_url": "my_slack_team_name",
}
createToolOptions := toolchainClient.NewCreateToolOptions("01234567-89ab-cdef-0123-456789abcdef", "slack")
createToolOptions.SetParameters(slackParameters)
slackTool, response, err := toolchainClient.CreateTool(createToolOptions)
from ibm_continuous_delivery.cd_toolchain_v2 import CdToolchainV2
...
toolchain_service = CdToolchainV2.new_instance()
slack_parameters = {
    "api_token": "crn:v1:bluemix:public:secrets-manager:us-south:a/9bb43e401a7a87d15145da761da98571:604de62c-c04f-3f5e-b7e8-4acafe0ecde7:secret:5ec17023-b631-fbcb-ef9c-4f2eb01f1dda",
    "channel_name": "my_slack_channel_name",
    "team_url": "my_slack_team_name"
}
slack_tool = toolchain_service.create_tool(
    toolchain_id = "01234567-89ab-cdef-0123-456789abcdef",
    tool_type_id = "slack",
    parameters = slack_parameters
)
   import com.ibm.cloud.continuous_delivery.cd_toolchain.v2.CdToolchain;
   import com.ibm.cloud.continuous_delivery.cd_toolchain.v2.model.*;
   ...
   CdToolchain toolchainService = CdToolchain.newInstance();
   HashMap<String, Object> slackParameters = new HashMap<>();
   slackParameters.put("api_token", "crn:v1:bluemix:public:secrets-manager:us-south:a/9bb43e401a7a87d15145da761da98571:604de62c-c04f-3f5e-b7e8-4acafe0ecde7:secret:5ec17023-b631-fbcb-ef9c-4f2eb01f1dda");
   slackParameters.put("channel_name", "my_slack_channel_name");
   slackParameters.put("team_url", "my_slack_team_name");
   CreateToolOptions createSlackToolOptions = new CreateToolOptions.Builder()
      .parameters(slackParameters)
      .toolchainId({toolchain_id})
      .toolTypeId("slack")
      .build();
   Response<ToolchainToolPost> response = toolchainService.createTool(createSlackToolOptions).execute();
   ToolchainToolPost slackTool = response.getResult();

Referenzen auf geheime Schlüssel mit Terraform angeben

Sie können mit sicheren Eigenschaften mit Referenzwerten für geheime Schlüssel in Terraform arbeiten.

Referenzen auf geheime Schlüssel nach Namen verwenden

Das folgende Beispiel zeigt einen vollständigen Satz von Ressourcen für eine Key Protect-Serviceinstanz, einen Standardschlüssel (Slack-Webhook), eine Toolchain, eine IAM-Service-to-Service-Berechtigungsrichtlinie, eine Key Protect-Toolintegration und eine Slack-Toolintegration, die den geheimen Webhook nach Namen referenziert.

Dieses Beispiel enthält auch eine ibm_kms_key-Standardschlüsselressource mit einem payload, für die der geheime Slack-Webhook-Schlüssel base64-encoded festgelegt ist. Es zeigt die Beziehung zwischen dem Namen des Schlüssels und dem Wert der Referenz auf geheime Schlüssel in der Integrationsressource des Slack-Tools. In der Praxis ist es sicherer, den Standardschlüssel im Voraus aus einem separaten Terraform-Projekt oder einem anderen Prozess zu erstellen, auf den nur eingeschränktes autorisiertes Personal Zugriff hat.

variable "slack_webhook" {}
variable "slack_channel" {}
variable "slack_team" {}

data "ibm_resource_group" "rg" {
    name = "default"
}

resource "ibm_resource_instance" "kms" {
    name              = "my-kms-service-instance"
    service           = "kms"
    plan              = "tiered-pricing"
    location          = "us-south"
    resource_group_id = data.ibm_resource_group.rg.id
}

resource "ibm_kms_key" "key" {
    instance_id  = ibm_resource_instance.kms.guid
    key_name     = "my-slack-webhook"
    standard_key = true
    payload      = base64encode(var.slack_webhook)
}

resource "ibm_cd_toolchain" "toolchain" {
    name              = "tf-toolchain-secret-refs"
    resource_group_id = data.ibm_resource_group.rg.id
}

resource "ibm_iam_authorization_policy" "s2s" {
    source_service_name         = "toolchain"
    source_resource_instance_id = ibm_cd_toolchain.toolchain.id
    target_service_name         = "kms"
    target_resource_instance_id = ibm_resource_instance.kms.guid
    roles                       = ["Viewer", "ReaderPlus"]
}

resource "ibm_cd_toolchain_tool_keyprotect" "integration" {
    toolchain_id = ibm_cd_toolchain.toolchain.id
    parameters {
        name           = "my-kms-tool-integration"
        region         = var.region
        resource_group = data.ibm_resource_group.rg.name
        instance_name  = ibm_resource_instance.kms.name
    }
    depends_on = [
        ibm_iam_authorization_policy.s2s
    ]
}

resource "ibm_cd_toolchain_tool_slack" "integration" {
    toolchain_id = ibm_cd_toolchain.toolchain.id
    parameters {
        webhook      = "{vault::my-kms-tool-integration.my-slack-webhook}"
        channel_name = var.slack_channel
        team_name    = var.slack_team
    }
    depends_on = [
        ibm_cd_toolchain_tool_keyprotect.integration
        ibm_kms_key.key
    ]
}

In der folgenden Tabelle werden alle geheimen Schlüssel aufgelistet und beschrieben, die im vorherigen Beispiel verwendet werden.

Geheime Referenzwerte
Wert Beschreibung
my-kms-tool-integration Der Name der Integration des Tools Key Protect in die Toolchain Dies ist nicht der Name der Serviceinstanz von Key Protect.
my-slack-webhook Der Name des Standardschlüssels, der in der Key Protect-Serviceinstanz verwaltet wird

Referenzen auf geheime Schlüssel durch CRN verwenden

Bei dem folgenden Beispiel wird davon ausgegangen, dass eine Instanz von Secrets Manager vorhanden ist. Es zeigt Ressourcen für einen beliebigen geheimen Schlüssel (Slack-Webhook), eine Toolchain, eine IAM-Service-zu-Service-Autorisierungsrichtlinie, eine Secrets Manager-Toolintegration und eine Slack-Toolintegration, die den geheimen Webhook-Schlüssel durch CRN referenziert.

Dieses Beispiel enthält eine ibm_sm_arbitrary_secret-Schlüsselressource mit einer payload, die auf den geheimen Slack-Webhook-Schlüssel gesetzt ist. Es zeigt, wie der CRN aus der Schlüsselressource als Wert der Referenz für geheime Schlüssel in der Slack-Toolintegrationsressource verwendet wird. In der Praxis ist es sicherer, den Standardschlüssel im Voraus aus einem separaten Terraform-Projekt oder einem anderen Prozess zu erstellen, auf den nur eingeschränktes autorisiertes Personal Zugriff hat.

variable "slack_webhook" {}
variable "slack_channel" {}
variable "slack_team" {}
variable "secrets_manager_name" {}

data "ibm_resource_group" "rg" {
    name = "default"
}

data ibm_resource_instance "sm" {
    name = var.secrets_manager_name
}

resource "ibm_sm_arbitrary_secret" "key" {
    instance_id     = data.ibm_resource_instance.sm.guid
    region          = data.ibm_resource_instance.sm.location
    secret_group_id = "default"
    name            = "my-slack-webhook"
    payload         = "var.slack_webhook"
}

resource "ibm_cd_toolchain" "toolchain" {
    name              = "tf-toolchain-secret-refs"
    resource_group_id = data.ibm_resource_group.rg.id
}

resource "ibm_iam_authorization_policy" "s2s" {
    source_service_name         = "toolchain"
    source_resource_instance_id = ibm_cd_toolchain.toolchain.id
    target_service_name         = "secrets-manager"
    target_resource_instance_id = data.ibm_resource_instance.sm.guid
    roles                       = ["Viewer", "SecretsReader"]
}

resource "ibm_cd_toolchain_tool_secretsmanager" "integration" {
    toolchain_id = ibm_cd_toolchain.toolchain.id
    parameters {
        name             = "my-sm-tool-integration"
        instance_id_type = "instance-crn"
        instance_crn     = data.ibm_resource_instance.sm.resource_crn
    }
    depends_on = [
        ibm_iam_authorization_policy.s2s
    ]
}

resource "ibm_cd_toolchain_tool_slack" "integration" {
    toolchain_id = ibm_cd_toolchain.toolchain.id
    parameters {
        webhook      = ibm_sm_arbitrary_secret.key.crn
        channel_name = var.slack_channel
        team_name    = var.slack_team
    }
    depends_on = [
        ibm_cd_toolchain_tool_secretsmanager.integration
    ]
}

Schutz Ihrer Daten mit kundenverwalteten Schlüsseln

Standardmäßig verschlüsselt Continuous Delivery Ihre Daten mithilfe von internen Schlüsseln für den Service Continuous Delivery. Für mehr Sicherheit und Kontrolle können Sie Continuous Delivery so konfigurieren, dass Ihre Daten mithilfe von Schlüsseln verschlüsselt werden, die Sie verwalten. Diese Option ist nur unter dem Professional-Plan und nur zu dem Zeitpunkt verfügbar, zu dem Sie eine Instanz des Continuous Delivery-Service bereitstellen. Wenn Sie Ihren eigenen Schlüsselverwaltungsdienst auswählen, z. B. Key Protect oder IBM Cloud® Hyper Protect Crypto Services, werden die folgenden Werte mit Ihrem eigenen Schlüssel anstelle der internen Verschlüsselungsschlüssel des Dienstes Continuous Delivery verschlüsselt.

Werte, die mit Ihrem eigenen Schlüssel verschlüsselt werden
Komponente Wert
Toolchain Eigenschaften und Parameter
Pipeline
  • Eigenschaftsschlüssel und -werte
  • Jobprotokolle
  • Jobartefakte
Integrationen
  • Slack (Slack-Webhook)
  • Pagerduty (API-Zugriffsschlüssel, Integrationsschlüssel)
  • Sauce Labs (Zugriffsschlüssel)
  • Artifactory (API-Schlüssel)
  • Hashicorp Vault (Token, Role-ID, Secret-ID, Kennwort)
  • Jenkins (Jenkins API-Token)
  • JIRA (JIRA-API-Token)
  • Nexus (Authentifizierungstoken)
  • Rational Team Concert (Kennwort)
  • Sicherheits- und Compliance-Center (IBM Cloud API-Schlüssel)
  • Sonarqube (SonarQube Kennwort oder Authentifizierungstoken)
IBM Cloud® DevOps Insights Anhang in Testdatensätzen

Die folgenden Komponenten verschlüsseln personenbezogene Daten ausschließlich mit dem vom Provider verwalteten Verschlüsselungsschlüssel.

Werte, die unter Verwendung des vom Anbieter verwalteten Schlüssels verschlüsselt werden
Komponente Wert
Git Repos and Issue Tracking
  • Probleme, Pull-Anforderungen und Quellcode
  • Persönliche Informationen wie Name, E-Mail, Profilbild, Adresse und andere Informationen von der Profilseite

Weitere Informationen zum Erstellen einer Continuous Delivery-Serviceinstanz, die Daten mit einem Kundenschlüssel verschlüsselt, enthält Continuous Delivery-Serviceinstanz erstellen.

Daten schützen, wenn Sie Toolintegrationen anderer Anbieter verwenden

Wenn Sie eine Toolintegration für eine Toolchain konfigurieren, aktivieren Sie explizit die gemeinsame Datennutzung zwischen dem Continuous Delivery-Service und der Toolintegration. Welche Art von Daten gemeinsam genutzt werden und ob Daten an das Tool gesendet und/oder vom Tool empfangen werden, hängt vom Typ der Toolintegration ab.

Bevor Sie eine Toolintegration konfigurieren, stellen Sie sicher, dass Sie wissen, welche Daten gemeinsam genutzt werden. Wenn Sie mit regulierten Daten oder Daten arbeiten, die Sie als sensibel betrachten, stellen Sie sicher, dass die Nutzung des Tools eines anderen Anbieters und alle Daten, die mit ihm geteilt werden, die Vertraulichkeit, Integrität oder Verfügbarkeit Ihrer Ressourcen nicht beeinträchtigen oder anderweitig gegen gesetzliche Kontrollen verstoßen.

Weitere Informationen zu Toolintegrationen finden Sie unter Toolintegrationen konfigurieren.

Daten bei Verwendung von Git Repos and Issue Tracking schützen

Git Repos and Issue Tracking ist eine von IBM gehostete Komponente des Continuous Delivery-Service. Alle Daten, die Sie für Git Repos and Issue Tracking bereitstellen, einschließlich, aber nicht beschränkt auf Quellendateien, Probleme, Pull-Anforderungen und Projektkonfigurationseigenschaften, werden sicher in Continuous Delivery verwaltet. Git Repos and Issue Tracking unterstützt jedoch verschiedene Mechanismen zum Exportieren, Senden oder anderweitigen Teilen von Daten an Benutzer und Dritte.

Die Fähigkeit von Git Repos and Issue Tracking, Informationen auszutauschen, ist typisch für viele Social-Coding-Plattformen. Eine solche Weitergabe könnte jedoch mit den für Ihr Unternehmen geltenden gesetzlichen Bestimmungen in Konflikt geraten. Nachdem Sie ein Projekt in Git Repos and Issue Tracking erstellt haben, aber bevor Sie dem Projekt Dateien, Probleme, Datensätze oder andere Daten anvertrauen, überprüfen Sie die Projekteinstellungen und ändern Sie alle Einstellungen, die Sie für den Schutz Ihrer Daten für erforderlich halten. Zu den zu prüfenden Einstellungen gehören Sichtbarkeitsebenen, E-Mail-Benachrichtigungen, Integrationen, Web-Hooks, Zugriffstokens, Implementierungstokens und Implementierungsschlüssel.

Projekt- und Dateinamen

In Git Repos and Issue Tracking werden der Name eines Projekts und die Pfadnamen der im Projekt-Repository gespeicherten Dateien zu Segmenten in URLs, die Sie zur Interaktion mit dem Projekt verwenden, sei es über den Browser, APIs oder Terraform. Sie sollten davon ausgehen, dass URLs nicht sicher sind. Verwenden Sie daher keine sensiblen Informationen in Projektnamen und Repository-Dateipfaden-Namen und betten Sie diese nicht ein.

Projektsichtbarkeitsebenen

Git Repos and Issue Tracking-Projekte können eine der folgenden Sichtbarkeitsebenen haben: privat, intern oder öffentlich.

  • Private Projekte sind nur für Projektmitglieder sichtbar. Diese Einstellung ist die Standardsichtbarkeitsstufe für neue Projekte und die sicherste Sichtbarkeitsstufe für Ihre Daten.
  • Interne Projekte sind für alle Benutzer sichtbar, die auf IBM Cloud angemeldet sind.
  • Öffentliche Projekte sind für jeden sichtbar.

Führen Sie die folgenden Schritte aus, um den Projektzugriff auf Projektmitglieder zu beschränken:

  1. Klicken Sie in der Projektseitenleiste auf Einstellungen >Allgemein.
  2. Klicken Sie auf der Seite 'Allgemeine Einstellungen' auf Sichtbarkeit >Projektfunktionen >Berechtigungen.
  3. Suchen Sie die Einstellung für die Projektsichtbarkeit.
  4. Wählen Sie Privat aus, wenn es noch nicht ausgewählt ist.
  5. Klicken Sie auf die Option Änderungen speichern.

Projektmitgliedschaft

Git Repos and Issue Tracking ist eine in der Cloud gehostete Social-Coding-Umgebung, die für alle Continuous Delivery-Benutzer verfügbar ist. Wenn Sie ein Git Repos and Issue Tracking-Projektbetreuer oder -eigner sind, können Sie alle Benutzer und Gruppenmitglieder zum Projekt einladen. IBM Cloud legt keine Einschränkungen dafür fest, wer Sie zu einem Projekt einladen können. Da Sie jeden Benutzer in ein GitLab-Projekt einladen können, achten Sie darauf, nur die Benutzer oder Gruppen einzuladen, die Teil Ihres Unternehmens oder Ihrer Organisation sind, sofern Sie nicht explizit etwas anderes beabsichtigen.

Weitere Informationen zum Verwalten von GitLab-Projektmitgliedern finden Sie unter Mitglieder eines Projekts.

Projekt-E-Mail-Einstellungen

Standardmäßig benachrichtigt Git Repos and Issue Tracking Projektmitglieder per E-Mail über Projektaktivitäten. Diese E-Mails enthalten normalerweise kundeneigene Daten, die von Benutzern für Git Repos and Issue Tracking bereitgestellt wurden. Wenn ein Benutzer beispielsweise einen Kommentar zu einem Problem veröffentlicht, sendet Git Repos and Issue Tracking eine E-Mail an alle Abonnenten, die Informationen wie eine Kopie des Kommentars, den Benutzer, der den Kommentar veröffentlicht hat, und den Zeitpunkt, zu dem der Kommentar veröffentlicht wurde, enthalten. Gehen Sie wie folgt vor, um alle E-Mail-Benachrichtigungen für Ihr Projekt zu inaktivieren:

  1. Klicken Sie in der Projektseitenleiste auf Einstellungen >Allgemein.
  2. Klicken Sie auf der Seite 'Allgemeine Einstellungen' auf Sichtbarkeit >Projektfunktionen >Berechtigungen.
  3. Wählen Sie das Kontrollkästchen E-Mail-Benachrichtigungen inaktivieren aus.
  4. Klicken Sie auf die Option Änderungen speichern.

Projektintegrationen und Webhooks

Git Repos and Issue Tracking-Projekte können auch mit Integrationen oder Webhooks für andere Systeme konfiguriert werden oder mit Zugriffstoken, Implementierungstoken und Implementierungsschlüsseln ausgestattet sein. Führen Sie die folgenden Schritte aus, um die Integrationen, Webhooks, Tokens und Schlüssel, die mit Ihrem Projekt konfiguriert werden können, über die Projektenseitenleiste anzuzeigen oder zu ändern:

  1. Klicken Sie in der Projektseitenleiste auf Einstellungen.
  2. Klicken Sie auf Integrationen, um mit den Integrationen Ihres Projekts mit anderen Anwendungen zu arbeiten.
  3. Klicken Sie auf Webhooks, um mit den Webhooks Ihres Projekts für andere Systeme zu arbeiten.
  4. Klicken Sie auf Zugriffstoken, um mit Zugriffstoken zu arbeiten, die möglicherweise Zugriff auf Ihr Projekt erteilen.
  5. Erweitern Sie Token implementieren, um mit den Bereitstellungstoken zu arbeiten, die möglicherweise Zugriff auf Ihr Projekt gewähren.
  6. Erweitern Sie Schlüssel implementieren, um mit Implementierungsschlüsseln zu arbeiten, die möglicherweise Zugriff auf Ihr Projekt erteilen.

Weitere Informationen zur Arbeit mit Git Repos and Issue Tracking finden Sie unter Git Repos and Issue Tracking.

Daten bei Verwendung von Delivery Pipelines schützen

Continuous Delivery-Pipelines führen die von Ihnen bereitgestellten Jobs und Schritte aus. Der Continuous Delivery-Service verwaltet die Protokollausgabe und Buildartefakte, die von Ihren Pipelineausführungen erzeugt werden, sicher. Continuous Delivery beschränkt oder verwaltet jedoch nicht die Funktion Ihres Pipelinejobs oder Ihrer Schrittscripts.

Wenn Sie Ihre Pipeline-Job-und -Schrittscripts entwickeln und konfigurieren, stellen Sie sicher, dass Ihre Scripts keine Aktionen ausführen, die die Vertraulichkeit, Integrität oder Verfügbarkeit Ihrer Ressourcen beeinträchtigen oder anderweitig gegen gesetzliche Bestimmungen verstoßen.

Weitere Informationen zu Delivery Pipelines finden Sie unter Mit Pipelines arbeiten und Mit Tekton-Pipelines arbeiten.

Schützen Sie Ihre Daten, wenn Sie Terraform verwenden

Wenn Sie Terraform zum Verwalten von Continuous Delivery-Ressourcen verwenden, können einige der Variablen, Argumente und Attribute, die von Terraform verarbeitet werden, geheime Werte wie Kennwörter oder API-Tokens enthalten. Diese Werte können von Ihnen in den Sprachdateien der Terraform-Konfiguration angegeben und/oder vom Terraform-Tool abgerufen und im Terraform-Status gespeichert werden. Die folgende Liste enthält Beispiele für Werte für geheime Schlüssel, die Sie schützen müssen, wenn Sie Terraform verwenden.

  • Der IAM-API-Schlüssel, den der IBM Cloud-Terraform-Provider für die Authentifizierung bei IBM Cloudbenötigt Dieser Schlüssel wird im Argument ibmcloud_api_key des Blocks provider "ibm" Ihres Terraform-Moduls angegeben.
  • Die Argumente oder Attribute, die Kennwörter, Zugriffstoken, API-Schlüssel oder andere Arten von geheimen Schlüsseln in einigen ibm_cd_toolchain_tool-Ressourcen und -Datenquellen darstellen.
  • Eigenschaftswerte, die in einigen ibm_cd_tekton_pipeline_property-oder ibm_cd_tekton_pipeline_trigger_property-Ressourcen oder -Datenquellen als geheime Schlüssel bezeichnet werden

Verwenden Sie IBM Cloud Schematics und die folgenden Verfahren, um die Gefährdung sensibler Daten zu begrenzen:

  • Verwenden Sie Terraform-Variablen, um Werte in Terraform-Blöcke einzufügen.
  • Verwenden Sie IBM Cloud Schematics, um geheime Schlüssel sicher zu verwalten und zu teilen.
  • Verwenden Sie IBM Cloud Schematics, um den Terraform-Status sicher zu verwalten und freizugeben.
  • Verwenden Sie die Referenzen auf Continuous Delivery-geheime Schlüssel, wenn Sie geheime Schlüssel in den Ressourcen ibm_cd_toolchain_tool, ibm_cd_tekton_pipeline_property oder ibm_cd_tekton_pipeline_trigger_property angeben.

Wenn Sie das Terraform-Befehlszeilentool verwenden, verwenden Sie die folgenden Verfahren, um die Gefährdung sensibler Daten zu begrenzen:

  • Verwenden Sie Terraform-Variablen, um Werte in Terraform-Blöcke einzufügen.
  • Lassen Sie zu, dass das Terraform-Befehlszeilentool zur Eingabe von Werten auffordert, wenn Sie Befehle wie terraform plan oder terraform apply ausführen
  • Steuern Sie den Zugriff auf Ihren Terraform-Zustand, da er möglicherweise geheime Schlüssel enthält. Der lokale Terraform-Status wird in Klartext geschrieben.
  • Verwenden Sie die Referenzen auf Continuous Delivery-geheime Schlüssel, wenn Sie geheime Schlüssel in den Ressourcen ibm_cd_toolchain_tool, ibm_cd_tekton_pipeline_property oder ibm_cd_tekton_pipeline_trigger_property angeben.

Vermeiden Sie die folgenden Verfahren, um die Gefährdung sensibler Daten zu begrenzen:

  • Geheime Schlüssel in Klartext in Terraform-Blöcken schreiben, z. B. Ressourcenblöcke, Datenblöcke oder Providerblöcke.
  • Geheime Schlüssel in Klartext in den Dateien terraform.tfvars, terraform.tfvars.json, *.auto.tfvars oder *.auto.tfvars.json schreiben.
  • Bereitstellung der terraform.tfvars-, terraform.tfvars.json-, *.auto.tfvars-oder *.auto.tfvars.json-Dateien mit geheimen Schlüsseln für Quellcode-Repositorys.
  • Terraform-Status in Quellcode-Repositorys bereitstellen.

Verwenden Sie IBM Cloud Schematics anstelle des Terraform-Befehlszeilentools zur Verarbeitung Ihrer Terraform-Konfigurationen. IBM Cloud Schematics bietet verschiedene Vorteile wie die sichere Speicherung sensibler Konfigurationseigenschaften.

Weitere Informationen zu IBM Cloud Schematics finden Sie in der IBM Cloud Schematics-Dokumentation.

Weitere Informationen zu sensiblen Daten im Terraform-Status finden Sie unter Sensible Daten im Status.

Weitere Informationen zum Festlegen von Eingabevariablen in Terraform finden Sie unter Werte zu Stammmodulvariablen zuordnen.

Daten aus Continuous Delivery löschen

Wenn Sie eine Continuous Delivery-Serviceinstanz löschen, werden die zugehörigen Toolchains, Toolintegrationen, Tools und Daten (einschließlich personenbezogener Daten) nicht gelöscht. Weitere Informationen zum Verwalten und Löschen von Daten, die im Zusammenhang mit Toolchains, Toolintegrationen und Tools gespeichert werden, finden Sie in Personenbezogene Daten ändern, exportieren und löschen.