Bonnes pratiques d'utilisation des comptes de service dans les pipelines

Les pipelines de déploiement vous permettent d'automatiser le processus de récupération du code ou des artefacts prédéfinis et de déployer ceux-ci dans un environnement Google Cloud. Ils peuvent servir d'alternative aux outils interactifs comme la console Google Cloud ou Google Cloud CLI.

Les pipelines de déploiement diffèrent des outils interactifs tels que la console Google Cloud ou Google Cloud CLI dans leur manière d'interagir avec Identity and Access Management. Vous devez prendre en compte ces différences lors de la sécurisation de vos ressources Google Cloud.

Avant de pouvoir accéder à une ressource Google Cloud, un contrôle des accès est effectué. Pour ce faire, Cloud IAM prend généralement en compte :

  • Votre identité
  • La ressource à laquelle vous essayez d'accéder, ainsi que ses stratégies d'autorisation et de refus IAM
  • Le contexte de votre requête (y compris éventuellement l'heure et la zone)

Dans un pipeline de déploiement, vous appelez rarement les API Google Cloud directement. À la place, vous utilisez des outils pour accéder aux ressources Google Cloud. Des outils comme la console Google Cloud ou Google Cloud CLI nécessitent d'abord que vous autorisiez l'outil à accéder aux ressources en votre nom. En accordant cette autorisation, vous permettez à l'outil à d'utiliser votre identité lors d'appels d'API.

De même que la console Google Cloud ou Google Cloud CLI, un pipeline de déploiement agit en votre nom : il récupère vos modifications, exprimées sous forme de code source, et les déploie sur Google Cloud. Toutefois, contrairement à la console Google Cloud ou Google Cloud CLI, un pipeline de déploiement n'utilise généralement pas votre identité pour effectuer le déploiement :

  1. En tant qu'utilisateur, vous n'interagissez généralement pas directement avec un pipeline de déploiement. À la place, vous interagissez avec un système de gestion de code source (SCM) en envoyant les modifications de code à un dépôt source ou en approuvant les revues de code.

  2. Le pipeline de déploiement lit les modifications de code envoyées par le système SCM et les déploie sur Google Cloud.

    Pour effectuer le déploiement, le pipeline de déploiement ne peut généralement pas utiliser votre identité pour les raisons suivantes :

    1. Le code source et ses métadonnées peuvent ne pas indiquer que vous êtes l'auteur, ou les informations de l'auteur ne sont pas infalsifiables (comme dans les commits Git non signés).
    2. L'identité que vous avez utilisée pour soumettre du code source peut être différente de votre identité Google, et les deux identités ne peuvent pas être mappées.

    La plupart des pipelines de déploiement effectuent donc des déploiements sous leur propre identité à l'aide d'un compte de service.

  3. Lorsque le pipeline de déploiement accède à Google Cloud, IAM autorise ou refuse l'accès uniquement en fonction de l'identité du compte de service utilisé par le pipeline, et non de l'identité de votre compte utilisateur.

Pipeline de déploiement

Le fait de laisser un pipeline de déploiement utiliser un compte de service pour accéder à Google Cloud présente certains avantages :

  • Le cycle de vie d'un compte de service est déconnecté du cycle de vie des comptes utilisateur. En configurant un pipeline pour utiliser un compte de service, vous vous assurez que le code peut être déployé même si l'auteur du code ne fait plus partie de votre organisation.
  • Lorsque vous gérez des ressources à l'aide d'un pipeline de déploiement, vous n'avez pas besoin d'accorder aux utilisateurs l'accès aux ressources ni de limiter les autorisations à un accès en lecture seule. Cette approche facilite la gestion des stratégies IAM et permet aux utilisateurs d'utiliser le pipeline de déploiement pour effectuer toutes les modifications.

Toutefois, l'utilisation d'un compte de service introduit également de nouvelles menaces. Exemples :

  • Spoofing : une personne malveillante peut tenter de falsifier l'identité du pipeline de déploiement ou de voler ses identifiants pour accéder aux ressources.
  • Élévation des privilèges : le pipeline peut être amené à effectuer des actions qu'il n'était pas censé effectuer, et devient ainsi un "confused deputy".
  • Non-répudiation : une fois qu'un pipeline a effectué une opération, il peut s'avérer difficile de reconstruire le motif de l'opération et par quel développeur ou code elle a été déclenchée.
  • Falsification : un pipeline peut être utilisé de manière abusive pour compromettre l'intégrité ou les contrôles de sécurité de vos environnements cloud.
  • Divulgation d'informations : des acteurs malveillants peuvent tenter d'utiliser le pipeline de déploiement pour exfiltrer des données confidentielles.

Protection contre les menaces de spoofing

Pour autoriser un pipeline de déploiement à accéder à Google Cloud, vous effectuez généralement les actions suivantes :

  1. Créer un compte de service
  2. Accorder au compte de service l'accès aux ressources requises
  3. Configurer le pipeline de déploiement pour qu'il utilise le compte de service

Du point de vue d'IAM, le compte de service représente le pipeline de déploiement, mais le pipeline de déploiement et le compte de service sont deux entités distinctes. S'il n'est pas correctement sécurisé, une personne malveillante pourrait être en mesure d'utiliser le même compte de service, ce qui lui permettrait de "falsifier" l'identité du pipeline de déploiement.

La section suivante décrit les bonnes pratiques qui vous aideront à réduire le risque de telles menaces.

Bonnes pratiques

Évitez d'associer des comptes de service aux instances de VM utilisées par les systèmes CI/CD.
Utilisez des comptes de service dédiés par pipeline de déploiement.
Utilisez la fédération d'identité de charge de travail autant que possible.
Utilisez VPC Service Controls pour réduire l'impact des identifiants piratés.

Éviter d'associer des comptes de service aux instances de VM utilisées par les systèmes CI/CD

Pour les applications déployées sur Compute Engine qui ont besoin d'accéder aux ressources Google Cloud, il est généralement préférable d'associer un compte de service à l'instance de VM sous-jacente. Pour les systèmes CI/CD qui utilisent des VM Compute Engine pour exécuter différents pipelines de déploiement, cette pratique peut poser problème si la même instance de VM peut être utilisée pour exécuter différents pipelines de déploiement nécessitant chacun l'accès à différentes ressources.

Au lieu d'utiliser des comptes de service associés pour permettre aux pipelines de déploiement d'accéder aux ressources, laissez chaque pipeline de déploiement utiliser un compte de service distinct. Évitez d'associer un compte de service aux instances de VM utilisées par les systèmes CI/CD, ou associez un compte de service limité à l'accès à des services essentiels tels que Cloud Logging.

Utiliser des comptes de service dédiés par pipeline de déploiement

Lorsque vous autorisez plusieurs pipelines de déploiement à utiliser le même compte de service, IAM ne peut pas les différencier : les pipelines ont accès aux mêmes ressources, et les journaux d'audit peuvent ne pas contenir suffisamment d'informations pour déterminer quel déploiement de pipeline a déclenché l'accès ou la modification d'une ressource.

Pour éviter cette ambiguïté, maintenez une relation un-à-un entre les pipelines de déploiement et les comptes de service. Créez un compte de service dédié pour chaque pipeline de déploiement et assurez-vous d'effectuer les opérations suivantes :

  • Intégrez le nom ou l'ID du pipeline de déploiement dans l'adresse e-mail du compte de service. Le fait de suivre un schéma de nommage cohérent vous aide à déterminer le pipeline de déploiement à partir du nom du compte de service, et inversement.
  • Accordez au compte de service un accès uniquement aux ressources dont le pipeline de déploiement spécifique a besoin.

Utiliser la fédération d'identité de charge de travail autant que possible

Certains systèmes CI/CD tels que GitHub Actions ou GitLab permettent aux pipelines de déploiement d'obtenir des jetons compatibles avec OpenID Connect qui indiquent l'identité du pipeline de déploiement. Vous pouvez autoriser les pipelines de déploiement à utiliser ces jetons pour emprunter l'identité d'un compte de service en utilisant la fédération d'identité de charge de travail.

La fédération d'identité de charge de travail vous permet d'éviter les risques associés à l'utilisation de clés de compte de service.

Utiliser VPC Service Controls pour réduire l'impact des identifiants piratés

Si une personne malveillante parvient à voler un jeton d'accès ou une clé de compte de service à partir de l'un de vos pipelines de déploiement, elle peut tenter d'utiliser ces identifiants et d'accéder à vos ressources depuis une autre machine qu'il contrôle.

Par défaut, IAM ne prend pas en compte la géolocalisation, l'adresse IP source ou le projet Google Cloud d'origine lors de la prise de décisions d'accès. Des identifiants volés peuvent donc être utilisables n'importe où.

Vous pouvez imposer des restrictions sur les sources à partir desquelles vos ressources Google Cloud sont accessibles en plaçant vos projets dans un périmètre de service VPC et en utilisant des règles d'entrée :

  • Si votre pipeline de déploiement s'exécute sur Google Cloud, vous pouvez configurer une règle d'entrée pour n'autoriser l'accès qu'à partir du projet contenant votre système CI/CD.
  • Si votre pipeline de déploiement s'exécute en dehors de Google Cloud, vous pouvez créer un niveau d'accès qui n'autorise l'accès qu'à partir de certaines zones géographiques ou plages d'adresses IP. Créez ensuite une règle d'entrée autorisant les clients qui remplissent les conditions pour ce niveau d'accès.

Protection contre les menaces de falsification

Pour certaines données que vous stockez sur Google Cloud, il peut être particulièrement important d'empêcher toute modification ou suppression non autorisée. Si certaines modifications ou suppressions non autorisées vous posent problème, vous pouvez caractériser les données en tant que données à haute intégrité.

Pour maintenir l'intégrité de vos données, vous devez vous assurer que les ressources Google Cloud que vous utilisez pour stocker et gérer ces données sont configurées de manière sécurisée et garantissent leur intégrité.

Les pipelines de déploiement peuvent vous aider à maintenir l'intégrité de vos données et de vos ressources, mais ils peuvent également présenter un risque : si le pipeline de l'un des composants ne répond pas aux exigences d'intégrité des ressources qu'il gère, le pipeline de déploiement devient un point faible qui pourrait permettre à des acteurs malveillants de manipuler vos données ou vos ressources.

La section suivante décrit les bonnes pratiques qui vous aideront à réduire le risque de menaces de falsification.

Bonnes pratiques

Évitez de laisser les pipelines de déploiement gérer les contrôles de sécurité.

Limiter l'accès aux contrôles de sécurité

Pour garantir la sécurité et l'intégrité de vos données et de vos ressources sur Google Cloud, vous utilisez des contrôles de sécurité tels que :

  • Stratégies d'autorisation et de refus
  • Contraintes liées aux règles d'administration
  • Périmètres VPC Service Controls, niveaux d'accès et règles d'entrée

Ces contrôles de sécurité sont eux-mêmes des ressources. Une falsification des contrôles de sécurité compromet l'intégrité des ressources auxquelles ils s'appliquent. Par conséquent, vous devez considérer l'intégrité des contrôles de sécurité comme étant au moins aussi importante que l'intégrité des ressources auxquelles ils s'appliquent.

Si vous laissez un pipeline de déploiement gérer les contrôles de sécurité, c'est à ce pipeline de maintenir l'intégrité des contrôles de sécurité. Par conséquent, vous devez considérer l'intégrité du pipeline de déploiement lui-même comme étant au moins aussi importante que l'intégrité des contrôles de sécurité qu'il gère et les ressources auxquelles ils s'appliquent.

Vous pouvez limiter l'impact d'un pipeline de déploiement sur l'intégrité de vos ressources de différentes manières :

  • Ne pas accorder l'accès aux pipelines de déploiement aux stratégies d'autorisation et de refus et autres contrôles de sécurité, et restreindre leur accès à d'autres ressources
  • Accorder l'accès uniquement à certains contrôles de sécurité, tels que les stratégies d'autorisation et de refus d'une ressource ou d'un projet spécifique, tout en n'accordant pas l'accès à des contrôles plus larges qui affectent plusieurs ressources ou projets

Si votre pipeline de déploiement, ses composants et l'infrastructure sous-jacente ne peuvent pas répondre aux exigences d'intégrité de certains contrôles de sécurité, il est préférable d'éviter que les pipelines de déploiement ne gèrent ces contrôles de sécurité.

Protection contre les menaces de non-répudiation

À un moment donné, il se peut que vous remarquiez une activité suspecte affectant l'une de vos ressources sur Google Cloud. Dans ce cas, vous devez être en mesure d'en savoir plus sur l'activité et, idéalement, de reconstruire la chaîne d'événements qui y a conduit.

Les journaux d'audit Cloud vous permettent de savoir quand les ressources ont été consultées ou modifiées, ainsi que les utilisateurs concernés. Bien que les journaux d'audit Cloud constituent un point de départ pour l'analyse des activités suspectes, les informations qu'ils fournissent peuvent ne pas être suffisantes : si vous utilisez des pipelines de déploiement, vous devez également pouvoir mettre en corrélation les journaux d'audit Cloud avec les journaux générés par votre pipeline de déploiement.

Cette section décrit les bonnes pratiques qui vous aideront à maintenir une piste d'audit sur Google Cloud et vos pipelines de déploiement.

Bonnes pratiques

Assurez-vous de mettre en corrélation les journaux de pipeline de déploiement avec les journaux d'audit Cloud.
Alignez les périodes de conservation des journaux de pipeline de déploiement et des journaux d'audit Cloud.

S'assurer de mettre en corrélation les journaux de pipeline de déploiement avec les journaux d'audit Cloud

Les journaux d'audit Cloud contiennent des horodatages et des informations sur l'utilisateur qui a lancé une activité. Si vous utilisez un compte de service dédié pour chaque pipeline de déploiement, ces informations vous permettent d'identifier le pipeline de déploiement qui a lancé l'activité et peuvent également vous aider à déterminer les modifications de code et les exécutions de pipeline à l'origine des exécutions. Toutefois, il peut être difficile d'identifier l'exécution de pipeline et la modification de code exactes ayant conduit à cette activité sans disposer d'autres informations permettant de mettre en corrélation les journaux d'audit Cloud avec les journaux de votre pipeline de déploiement.

Vous pouvez enrichir de différentes manière les journaux d'audit Cloud de façon à contenir davantage d'informations, par exemple :

  • Lorsque vous utilisez Terraform, spécifier un motif de requête indiquant l'exécution du pipeline CI/CD.
  • Ajouter un en-tête HTTP X-Goog-Request-Reason aux requêtes API et transmettre l'ID de l'exécution du pipeline de déploiement.
  • Utiliser un fichier User-Agent personnalisé qui intègre l'ID de l'exécution du pipeline de déploiement.

Vous pouvez également enrichir les journaux émis par votre pipeline de déploiement :

  • Requêtes API Log effectuées par chaque pipeline CI/CD
  • Chaque fois que l'API renvoie un ID d'opération, enregistrez l'ID dans les journaux du système CI/CD.

Aligner les périodes de conservation des journaux de pipeline de déploiement et des journaux d'audit Cloud

Pour analyser les activités suspectes liées à un pipeline de déploiement, vous avez généralement besoin de plusieurs types de journaux, y compris les journaux d'audit des activités d'administration, les journaux d'audit des accès aux données et les journaux de votre pipeline de déploiement.

Cloud Logging ne conserve les journaux que pendant une période donnée. Par défaut, cette période de conservation est plus courte pour les journaux d'audit des accès aux données que pour les journaux d'audit des activités d'administration. Le système qui exécute votre pipeline de déploiement peut également supprimer ses journaux après une certaine période. Selon la nature de votre pipeline de déploiement et l'importance des ressources gérées par ce pipeline, ces périodes de conservation par défaut peuvent être insuffisantes ou mal alignées.

Pour être sûr de disposer des journaux lorsque vous en avez besoin, assurez-vous que les périodes de conservation des journaux utilisés par les différents systèmes sont alignées et suffisamment longues.

Si nécessaire, personnalisez la période de conservation des journaux d'audit des accès aux données ou configurez un récepteur personnalisé pour acheminer les journaux vers un emplacement de stockage personnalisé.

Bonnes pratiques

Évitez d'accorder un accès direct aux données confidentielles.
Utilisez VPC Service Controls pour éviter l'exfiltration de données.

Protection contre les menaces de divulgation d'informations

Lorsque le compte de service d'un pipeline de déploiement a accès à des données confidentielles, une personne malveillante peut tenter d'utiliser le pipeline de déploiement pour exfiltrer ces données. L'accès d'un pipeline de déploiement aux données peut être direct ou indirect :

  • Direct : le compte de service du pipeline de déploiement peut être autorisé à lire des données confidentielles à partir de Cloud Storage, BigQuery ou d'autres emplacements. Cet accès a peut-être été accordé intentionnellement, mais il peut également s'agir d'un résultat accidentel d'une autorisation d'accès trop étendue.

    Si une personne malveillante accède à un pipeline de déploiement disposant d'un accès direct à des données confidentielles, elle peut essayer d'utiliser le jeton d'accès du compte de service pour accéder aux données et les exfiltrer.

  • Indirect : pour déployer la configuration ou de nouvelles versions logicielles, le compte de service d'un pipeline de déploiement peut être autorisé à créer ou à redéployer des instances de VM, des applications Cloud Run ou d'autres ressources de calcul. Certaines de ces ressources de calcul peuvent être associées à un compte de service qui autorise l'accès aux données confidentielles.

    Dans ce cas, une personne malveillante peut tenter de compromettre le pipeline de déploiement afin qu'il déploie du code malveillant sur l'une des ressources de calcul, puis que ce code exfiltre des données confidentielles.

Cette section décrit les bonnes pratiques qui vous aideront à limiter le risque de divulgation de données confidentielles.

Éviter d'accorder un accès direct aux données confidentielles

Pour déployer une infrastructure, une configuration ou de nouvelles versions logicielles, un pipeline de déploiement ne nécessite souvent pas d'accès aux données existantes. À la place, il est souvent suffisant de limiter l'accès aux ressources qui ne contiennent aucune donnée ou au moins qui ne contiennent pas de données confidentielles.

Les méthodes permettant de minimiser l'accès aux données existantes et potentiellement confidentielles sont les suivantes :

  • Au lieu d'accorder au compte de service d'un pipeline de déploiement l'accès à un projet entier, accorder uniquement l'accès à des ressources spécifiques.
  • Accorder l'accès en création sans autoriser l'accès en lecture. Par exemple, en attribuant le rôle Créateur d'objets Storage (roles/storage.objectCreator), vous pouvez autoriser un compte de service à importer de nouveaux objets dans un bucket Cloud Storage sans accorder d'accès en lecture aux données existantes.
  • Limiter l'IaC (Infrastructure as Code) aux ressources moins confidentielles. Par exemple, utilisez l'IaC pour gérer les instances ou les réseaux de VM, mais pas pour gérer les ensembles de données BigQuery confidentiels.

Utiliser VPC Service Controls pour empêcher l'exfiltration de données

Vous pouvez réduire le risque d'exfiltration indirecte de données en déployant vos ressources Google Cloud dans un périmètre VPC Service Controls.

Si votre pipeline de déploiement s'exécute en dehors de Google Cloud ou se trouve dans un périmètre différent, vous pouvez accorder au compte de service du pipeline l'accès au périmètre en configurant une règle d'entrée. Si possible, configurez la règle d'entrée de sorte qu'elle n'autorise l'accès qu'à partir des adresses IP utilisées par le pipeline de déploiement et qu'aux services dont le pipeline de déploiement a réellement besoin.

Protection contre les menaces d'élévation des privilèges

Lorsqu'un pipeline de déploiement utilise un compte de service pour accéder aux ressources Google Cloud, il le fait indépendamment du développeur ou de l'utilisateur qui a créé un code ou une modification de configuration. La déconnexion entre le compte de service du pipeline et l'identité du développeur rend les pipelines de déploiement sujets à des attaques de type confused deputy, dans lesquelles une personne malveillante trompe le pipeline pour qu'il exécute une action que l'acteur malintentionné n'est pas autorisé à effectuer lui-même, et que le pipeline n'est même pas censé exécuter.

Cette section décrit les bonnes pratiques qui vous aideront à réduire le risque d'utilisation abusive de votre pipeline de déploiement à des fins d'élévation des privilèges.

Bonnes pratiques

Limitez l'accès au pipeline de déploiement et à toutes les entrées.
Évitez de laisser un pipeline de déploiement modifier les stratégies.
Ne révélez pas les identifiants du compte de service dans les journaux.

Limiter l'accès au pipeline de déploiement et à toutes les entrées

La plupart des pipelines de déploiement utilisent un dépôt de code source comme source principale d'entrée et peuvent se déclencher automatiquement dès qu'ils détectent un changement de code dans certaines branches (par exemple, la branche main). Les pipelines de déploiement ne peuvent généralement pas vérifier si le code et la configuration qu'ils trouvent dans le dépôt du code source sont authentiques et fiables. La sécurité de cette architecture dépend donc des éléments suivants :

  • Contrôler qui peut envoyer du code et une configuration au dépôt et aux branches utilisés par le pipeline de déploiement
  • Appliquer des critères qui doivent être remplis pour que des modifications puissent être validées (par exemple, revues de code réussies, analyse statique ou tests automatisés).

Pour que ces contrôles soient efficaces, vous devez également vous assurer que les acteurs malintentionnés ne peuvent pas effectuer les actions de contournement suivantes :

  • Modifier la configuration du dépôt de code source ou du pipeline de déploiement.
  • Falsifier l'infrastructure (par exemple, VM et espace de stockage) sous-jacents au pipeline de déploiement.
  • Modifier ou remplacer des entrées en dehors du dépôt de code source, telles que des packages, des images de conteneurs ou des bibliothèques.

Lorsqu'elles sont gérées par un pipeline de déploiement, vos ressources sur Google Cloud ne peuvent être sécurisées que si votre pipeline de déploiement, sa configuration, son infrastructure et ses entrées le sont également. Par conséquent, vous devez protéger ces composants ainsi que vos ressources Google Cloud.

Éviter qu'un pipeline de déploiement ne modifie des stratégies

Pour la plupart des types de ressources, Cloud IAM définit une autorisation RESOURCE_TYPE.setIamPolicy. Cette autorisation permet à un utilisateur de modifier la stratégie d'autorisation IAM d'une ressource, soit pour accorder l'accès à d'autres utilisateurs, soit pour modifier et étendre son propre accès. À moins qu'elle ne soit limitée par une stratégie de refus, l'attribution d'une autorisation *.setIamPolicy à un utilisateur ou à un compte de service a pour effet de lui accorder un accès complet à la ressource.

Dans la mesure du possible, évitez d'autoriser un pipeline de déploiement à modifier l'accès aux ressources. Lorsque vous accordez au compte de service du pipeline l'accès aux ressources Google Cloud, utilisez des rôles qui n'incluent aucune autorisation *.setIamPolicy et évitez d'utiliser les rôles de base Éditeur et Propriétaire.

Pour certains pipelines de déploiement, l'autorisation de modifier des stratégies d'autorisation ou de refus peut s'avérer inévitable. Par exemple, l'objectif d'un pipeline de déploiement peut être de créer des ressources ou de gérer l'accès aux ressources existantes. Dans ces scénarios, vous pouvez toujours limiter la mesure dans laquelle le déploiement peut modifier l'accès en appliquant les mesures suivantes :

  • N'accorder l'autorisation *.setIamPolicy que pour des ressources spécifiques, et non pour l'ensemble du projet.
  • Utiliser des stratégies de refus IAM pour limiter l'ensemble d'autorisations pouvant être accordées, ou limiter les comptes principaux auxquels elles peuvent être accordées.
  • Utiliser des conditions IAM pour restreindre les rôles que le pipeline est autorisé à attribuer et n'autoriser que les rôles qui n'incluent pas les autorisations *.setIamPolicy.

Ne pas révéler les identifiants du compte de service dans les journaux

Les journaux générés par un pipeline de déploiement sont souvent accessibles à un plus grand nombre d'utilisateurs, y compris ceux qui ne sont pas autorisés à modifier la configuration du pipeline. Il est possible que ces journaux révèlent accidentellement les identifiants en renvoyant ces éléments :

  • Contenu des variables d'environnement
  • Arguments de ligne de commande
  • Résultat des diagnostics

Si des journaux révèlent accidentellement des identifiants tels que des jetons d'accès, ceux-ci peuvent être utilisés de manière abusive par des acteurs malintentionnés pour élever leurs privilèges. Les méthodes suivantes permettent d'empêcher les journaux de révéler des identifiants :

  • Éviter de transmettre des jetons d'accès ou d'autres identifiants en tant qu'arguments de ligne de commande
  • Éviter de stocker les identifiants dans des variables d'environnement
  • Configurer votre système CI/CD de sorte qu'il détecte et masque automatiquement les jetons et autres identifiants si possible

Étape suivante