Gestion des secrets dans vos chaînes d'outils

Les intégrations d'outils dans vos chaînes d'outils CI et CD nécessitent des secrets, par exemple des mots de passe, des clés API, des certificats ou d'autres jetons. Par exemple, une clé API IBM Cloud® permet d'effectuer des tâches de base liées au pipeline, telles que la connexion à IBM Cloud. De même, la clé d'API d'ID de service écrit des preuves dans le compartiment dans l'instance Cloud Object Store.

Pour des raisons de sécurité, ces secrets ne doivent pas révéler l'identité ou le compte d'une personne car les personnes disposent souvent de droits d'accès supérieurs à l'exigence d'automatisation de la chaîne d'outils. L'affiliation à l'identité ou au compte d'une personne violerait également le principe de sécurité de "moindre privilège". En outre, les personnes changent souvent de rôle, voire d'entreprise, et leurs informations d'identification doivent être supprimées, ce qui risque d'interrompre l'automatisation de la chaîne d'outils. L'utilisation d'une identité affiliée spécifiquement à des fins d'automatisation permet de séparer les tâches entre l'automatisation et les personnes qui utilisent l'automatisation.

En revanche, les secrets utilisés pour les ressources autres que IBM Cloud (telles que GitHub Enterprise ) doivent être associés à un identifiant fonctionnel au sein de votre entreprise, avec uniquement l'accès approprié nécessaire aux chaînes d'outils. De même, les secrets pour les ressources IBM Cloud doivent être associés à une clé d'API IAM service ID qui est associée à un IAM service ID. Les autorisations d'accès à l'identifiant de service IAM doivent être limitées au moindre privilège requis par les chaînes d'outils.

La gestion des données d'identification de ce type doit être effectuée en toute sécurité et conformément aux meilleures pratiques de gestion des secrets. En particulier, cela signifie qu'il faut placer les secrets requis dans un coffre-fort en utilisant un fournisseur de coffre-fort transfrontalier agréé, tel que IBM Cloud® Secrets Manager, IBM® Key Protect, ou HashiCorp Vault puis de lier les secrets de votre chaîne d'outils à ces ressources.

Les fonctionnalités de gestion des secrets fournies dans les interfaces utilisateur de la chaîne d'outils et du pipeline permettent de sélectionner des secrets protégés en utilisant les intégrations de secrets pour IBM Cloud® Secrets Manager, IBM® Key Protect, ou HashiCorp Vault. A l'aide de la boîte de dialogue Sélecteur de secrets, un éditeur de chaîne d'outils ou de pipeline peut sélectionner des secrets nommés à partir d'une intégration de secrets liés configurée par CRN (nom de ressource de cloud) ou par nom, qui est ensuite résolue par référence lors de l'exécution dans la chaîne d'outils et le pipeline. Une fois qu'un secret a été choisi, une référence de secret CRN ou canonique est injectée dans la propriété sécurisée de chaîne d'outils ou de pipeline correspondante où le format est soit crn:v1:...secret:<secret-guid> s'il s'agit d'une intégration Secrets Manager configurée par CRN, soit {vault::integration-name.secret-name} s'il s'agit d'une intégration de coffre qui utilise l'un des fournisseurs pris en charge et configurée par nom.

Le format de référence canonique par nom ne résout actuellement pas un secret qui inclut le caractère point dans le nom du secret car ce caractère est utilisé pour délimiter chaque section du chemin canonique.

Quel que soit le type de référence de secret utilisé, par CRN ou par nom, les composants de l'interface utilisateur frontale et la boîte de dialogue Secrets Picker utilisent uniquement une référence de secret. La valeur résolue d'une référence secrète par CRN ou par nom n'est jamais exposée au front-end et est toujours résolue dynamiquement lors de l'exécution dans une chaîne d'outils et un pipeline en fonction d'une autorisation autorisée (configurée à l'aide des autorisations et des règles d'accès IAM).

Au sein de IBM Cloud®, le processus dynamique de résolution par CRN et par nom des références secrètes dans les chaînes d'outils et les pipelines est effectué en utilisant des points de terminaison privés virtuels (VPE) internes à toutes les instances de fournisseurs IBM Cloud® Secrets Manager et IBM® Key Protect dans toutes les régions. Cela garantit que toutes les données de demande et de réponse entre les chaînes d'outils, les pipelines et les instances des fournisseurs IBM Cloud® Secrets Manager et IBM® Key Protect sont conservées dans le réseau privé IBM Cloud à l'intérieur des frontières et ne transitent pas par des canaux de réseau publics.

Outre la sélection manuelle des secrets choisis un par un à partir de toute intégration de secrets liés dans une chaîne d'outils, l'option d'utilisation d'un Secret Hint est également disponible. Cette option permet de prédéfinir un modèle de chaîne d'outils avec des noms de secrets suggérés (également appelés Hints) qui sont une référence de secret de format court. Le format d'une suggestion de secret est {vault::secret-name}, ce qui signifie qu'aucun nom d'intégration de secret n'est inclus. Cela offre une flexibilité à l'auteur de la chaîne d'outils dans la mesure où tous les noms de secret requis peuvent être préremplis dans un toolchain.yml, puis ces noms sont automatiquement résolus en fonction des intégrations de secrets configurées pour la chaîne d'outils.

Comme décrit précédemment, vous pouvez configurer Secrets Manager pour référencer des secrets par CRN. Pour plus d'informations, voir Cloud Resource Names(CRN). Ce format offre une plus grande flexibilité car vous pouvez référencer des secrets à partir d'une instance Secrets Manager dans un autre compte si l'autorisation correcte est en place. Pour plus d'informations, voir Configuration de Secrets Manager.

Les secrets utilisés dans l'IC et le CD sont décrits ci-dessous :

Un Hint est un nom suggéré par défaut qui est automatiquement résolu par rapport au premier secret correspondant avec le même nom dans toutes les intégrations de secrets par nom disponibles qui sont liées à la chaîne d'outils.

Secrets du pipeline DevSecOps

SecretsDevSecOps
Secret Conseil Informations
Clé d'API IBM Cloud ibmcloud-api-key Requis : CI & CD Utilisé pour s'authentifier auprès du nuage public IBM et effectuer un large éventail d'opérations
Clé privée GPG signing_key Requis : CI uniquement Il s'agit du certificat utilisé pour signer les images créées par le pipeline CI
Clé d'API du service d'agent privé IBM private-worker-service-api-key Requis : CI uniquement Clé API Service ID Utilisée pour exécuter des charges de travail de pipeline de livraison sur un service de travailleur privé Tekton
Jeton d'accès GitHub git-token Facultatif : CI & CD Utilisé pour s'authentifier auprès de GitHub et donner accès aux référentiels
Jeton d'API Artifactory artifactory-token Requis: CI & CD Utilisé pour accéder aux images utilisées par les tâches de pipeline
Webhook Slack slack-webhook Optionnel : CI & CD Ce webhook est nécessaire si vous choisissez d'utiliser l'intégration de l'outil Slack pour poster des notifications sur l'état de la chaîne d'outils
Jeton d'API ServiceNow servicenow-api-token Requis: CD uniquement Utilisé pour accéder à Service Now pour les opérations de gestion des changements
ID de rôle HashiCorp Vault role-id Nécessaire : CI & CD Utilisé pour s'authentifier auprès du serveur HashiCorp Vault
ID de secret HashiCorp Vault secret-id Nécessaire : CI & CD Utilisé pour s'authentifier auprès du serveur HashiCorp Vault
Clé d'API avec accès en écriture IBM Cloud Object Storage cos-api-key Requis: CI & CD Utilisé pour s'authentifier auprès du service Object Storage-Cette clé doit disposer de writer droits
IBM Cloud Object Storage Clé API du lecteur backup-cos-api-key Requis: CI & CD Utilisé pour s'authentifier auprès du service Object Storage-Cette clé doit disposer de Reader droits
Mot de passe ou jeton d'authentification SonarQube sonarqube-password Facultatif : CI Utilisé pour s'authentifier auprès de l'analyseur de code source SonarQube

Si vous utilisez un serveur HashiCorp Vault, assurez-vous que l'intégration de l'outil HashiCorp Vault utilise la méthode d'authentification AppRole. Lorsque vous utilisez la méthode d'authentification AppRole, vous avez besoin de role-id et secret-id pour intégrer avec succès le serveur HashiCorp Vault à la chaîne d'outils. Étant donné que role-id et secret-id sont des secrets en soi, il est recommandé de les stocker en utilisant une intégration d'outil IBM Key Protect afin qu'ils puissent être récupérés et appliqués en toute sécurité dans le flux de travail de la chaîne d'outils. Tous les autres secrets de la chaîne d'outils doivent être stockés et récupérés en utilisant l'intégration de l'outil HashiCorp Vault.

Si la propriété d'environnement du pipeline git-token n'est pas définie, ibmcloud-api-key est utilisé par défaut pour récupérer le jeton d'accès Git Repos and Issue Tracking. Cependant, si ibmcloud-api-key n'a pas accès à git, git-token doit être défini.

Configuration des magasins de secrets

Avec IBM Cloud, vous pouvez choisir parmi différentes offres de gestion des secrets et de protection des données qui vous aident à protéger vos données sensibles et à centraliser vos secrets. Vous pouvez choisir entre les intégrations de coffre en fonction de vos besoins, comme expliqué dans Gestion des secrets IBM Cloud. Cette documentation fournit des informations sur les conditions préalables et sur l'utilisation d'une liste de noms secrets prescrits, également connus sous le nom d'indices. En utilisant les suggestions présentées dans un modèle, des secrets préconfigurés peuvent être automatiquement définis dans la chaîne d'outils sans qu'il soit nécessaire de les sélectionner manuellement à partir des diverses intégrations de coffre qui sont associées à la chaîne d'outils.

Utilisez IBM Cloud® Secrets Manager pour stocker et appliquer en toute sécurité des secrets tels que des clés API, des signatures d'images ou des informations d'identification HashiCorp Vault qui font partie de votre chaîne d'outils.

Secrets Manager formulaire d'intégration d'outils
IBM Secrets Manager Tool Integration

Les modèles sont également accompagnés d'une intégration de l'outil HashiCorp Vault, comme dans l'exemple suivant :

HashiCorp Vault Formulaire d'intégration d'outils avec champs obligatoires et valeurs d'exemple Formulaire d'intégration d'outils avec champs obligatoires et valeurs d'exemple Intégration d'outils
HashiCorp Vault

Pour utiliser HashiCorp Vault, vous devez fournir les informations suivantes :

  • Nom : Nom de cette intégration d'outils. Il est affiché dans la chaîne d'outils.
  • URL de serveur : URL de serveur de votre instance HashiCorp Vault. Par exemple, https://<vault-service>.<org>.com:8200.
  • URL d'intégration : URL à laquelle vous souhaitez accéder lorsque vous cliquez sur la vignette Intégration de HashiCorp Vault.
  • Chemin des secrets : Chemin de montage dans lequel sont stockés les secrets de votre instance HashiCorp Vault.
  • Méthode d'authentification : Méthode d'authentification de votre instance HashiCorp Vault. Utilisez AppRole.
  • ID de rôle : Identifiant qui sélectionne l'AppRole par rapport auquel les autres données d'identification sont évaluées.
  • ID secret: Pièce d'identité requise par défaut pour toute connexion (avec secret_id) et destinée à être toujours secrète.

Les modèles sont également fournis avec une intégration d'outil IBM® Key Protect for IBM Cloud®:

Key Protect Formulaire d'intégration de l'outil avec champs obligatoires et valeurs d'exemple
Intégration de l'outilIBM Key Protect

Si vous avez préalablement stocké role id et secret id dans Key Protect, vous pouvez sélectionner l'instance Key Protect qui contient ces secrets dans la carte d'outil, comme illustré dans la figure 2. Une fois cela fait, vous pouvez cliquer sur les icônes de clé sur les champs d' identification de rôle et d' identification de secret dans la carte d'outils HashiCorp Vault, et utiliser le sélecteur pour appliquer les secrets à ces champs.

De même, tous les autres secrets utilisés dans la chaîne d'outils ont une icône de clé attachée au champ de texte. Vous pouvez utiliser le même contrôle de sélection pour appliquer les secrets HashiCorp Vault à toutes les instances restantes.

Retrouver les secrets de IBM Cloud Secrets Manager

Utilisez la commande get_env pour accéder au secret en toute sécurité. Cette méthode permet de récupérer le secret sans l'exposer dans les journaux.

Types de secret pris en charge

Actuellement, nous prenons en charge la récupération des types de secrets suivants à partir des propriétés de l'environnement dans le site Secrets Manager:

  • Arbitrage

  • Données d'identification IAM

  • Clé-valeur

Syntaxe :

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

Dans cet exemple :

  • secret_key est le nom utilisé pour stocker le secret.

  • SECRET_VALUE conserve la valeur secrète récupérée en vue d'une utilisation ultérieure.

Selon le type de secret, get_env récupère des valeurs spécifiques :

Récupération d'un secret arbitraire
  {
    "name": "my-secret",
    "secret_type": "arbitrary",
    ...
    "payload": "The quick brown fox jumped over the lazy dog."
  }

Si get_env est utilisé avec my-secret, il récupère la valeur de payload.

Récupération du secret iam_credentials
  {
    "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"
  }

Si get_env est utilisé avec my-iam-credentials, il récupère api_key.

Récupération d'un secret clé-valeur
  {
    "name": "my-kv-secret",
    "secret_type": "key-value",
    ...
    "data": "{\"key\":\"value\"}"
  }

Si get_env est utilisé avec my-kv-secret, il récupère le value à l'intérieur de la paire clé-valeur