Présentation de la sécurité

Découvrez comment Cloud Run met en œuvre les bonnes pratiques de sécurité pour protéger vos données, et apprenez à utiliser ces fonctionnalités pour répondre à vos exigences de sécurité.

Architecture

Cloud Run s'exécute sur Borg dans l'environnement où Google déploie des milliards de conteneurs par semaine, hébergeant certains des plus grands sites du monde, y compris Gmail et YouTube. Les composants Cloud Run partagent la même infrastructure, ils sont donc basés sur les mêmes normes de sécurité que les autres services Google.

Pour en savoir plus sur notre approche de la sécurité, consultez le livre blanc Présentation de la sécurité Google.

L'architecture Cloud Run contient de nombreux composants d'infrastructure différents. Le schéma suivant montre comment ces composants répondent aux requêtes adressées à votre service et aux appels de l'API Cloud Run Admin :

Schéma des composants de l'infrastructure Cloud Run
Figure 1. Schéma des composants de l'infrastructure Cloud Run.

Requêtes adressées à votre service

Lorsqu'une requête est envoyée à votre service Cloud Run via votre domaine personnalisé ou directement à votre URL run.app, elle est traitée par les composants suivants :

  • Google Front End (GFE) : service d'infrastructure global de Google qui met fin aux connexions TLS et applique des protections contre les attaques DoS lorsque vous envoyez une requête à l'URL run.app. Cloud Run est un service régional. Ainsi, lorsqu'une requête est accessible via l'URL run.app, le GFE transfère la requête à Cloud Run dans la région appropriée.
  • Équilibreur de charge Google Cloud : lorsque vous configurez Cloud Load Balancing pour gérer votre domaine personnalisé, il inclut la fonctionnalité GFE mentionnée précédemment. Vous pouvez également configurer les équilibreurs de charge Google Cloud pour exécuter des fonctions supplémentaires, telles que la gestion du trafic et le contrôle des accès.
  • Proxy HTTP : composant zonal qui équilibre la charge des requêtes HTTP entrantes vers les instances de vos applications de bac à sable.
  • Programmeur : sélectionne les serveurs d'applications pour héberger des instances de vos applications en bac à sable.
  • Serveur d'applications : nœud de calcul zonal et mutualisé qui crée et gère les bacs à sable qui exécutent les instances du conteneur de chaque application.
  • Bac à sable : isole le code utilisateur du système et des autres clients. Pour en savoir plus, consultez la section Sécurité des ressources de calcul ci-dessous.
  • Stockage : expose une interface de serveur de fichiers pour les images de conteneurs importées des registres de conteneurs compatibles.
  • Serveur de métadonnées : fournit des identifiants et des métadonnées spécifiques au bac à sable.
  • Mise en réseau sortante : gère le trafic sortant lancé par le bac à sable.

Appels d'API Cloud Run Admin

Lorsqu'une requête est envoyée à l'API Cloud Run Admin, elle est traitée par les composants suivants :

  • Google Front End (GFE) : service d'infrastructure global de Google qui met fin aux connexions TLS et applique des protections contre les attaques DoS.
  • Plan de contrôle : valide et écrit vos configurations d'application dans l'espace de stockage.
  • Stockage de configurations : stocke les configurations d'application dans Spanner et Bigtable pour qu'elles soient accessibles par d'autres composants, tels que le serveur d'applications, le programmeur et les éléments réseau.

Sécurité des ressources de calcul

Les composants Cloud Run s'exécutent sur Borg, le système de gestion des conteneurs de Google. Pour vos conteneurs, Cloud Run propose deux environnements d'exécution :

  • Première génération : basée sur la plate-forme de sécurité des conteneurs gVisor, cette option dispose d'un petit codebase, qui fournit une surface d'attaque plus petite. Chaque modification fait l'objet d'un examen de sécurité et la plupart des modifications sont écrites de manière sécurisée. Le renforcement de la sécurité est effectué à l'aide du filtrage des appels système du mode de calcul sécurisé (seccomp).

  • Deuxième génération : basée sur des microVM Linux, cette option offre davantage de compatibilité et de performances pour les charges de travail personnalisées. Le renforcement de la sécurité est effectué en utilisant le filtrage des appels système seccomp et les espaces de noms Linux Sandbox2.

Ces deux environnements d'exécution utilisent deux couches de bac à sable composées d'une couche matérielle basée sur une VM équivalente à une VM (virtualisation x86) et d'une couche de noyau logiciel, comme illustré dans le schéma suivant :

Dans les deux environnements d'exécution, le conteneur d'utilisateur est isolé des autres charges de travail via deux couches de bac à sable.
Figure 2. Dans les deux environnements d'exécution, le conteneur d'utilisateur est isolé des autres charges de travail via deux couches de bac à sable.

Si votre service utilise une infrastructure tierce pour sécuriser les conteneurs, utilisez l'environnement d'exécution de deuxième génération.

Chiffrement et stockage des données

Les instances Cloud Run sont sans état. L'arrêt d'une instance supprime son état. Par conséquent, toutes les nouvelles instances démarrent à partir d'un nouvel écran.

Si vous disposez de données avec état, vous pouvez gérer vos données de différentes manières :

En outre, Cloud Run s'intègre à de nombreux autres systèmes Google Cloud pour gérer vos données et y accéder de différentes manières :

Dans Google Cloud, toutes vos données sont chiffrées au repos.

Cloud Run est conforme aux initiatives de transparence et de protection des données appliquées à l'échelle de Google Cloud, y compris en matière de transparence des accès et de résidence des données.

Sécurité du réseau

Cloud Run et tous les autres services Google Cloud chiffrent tout le trafic en transit. Vous pouvez intégrer à la fois des contrôles de sortie et d'entrée à vos services ou jobs Cloud Run pour ajouter une couche de restriction supplémentaire. Les administrateurs de l'organisation peuvent également appliquer ces contrôles de sortie et d'entrée en définissant des règles d'administration.

Trafic de sortie (trafic sortant)

Le trafic de sortie de Cloud Run est traité comme la couche de transport 4 (TCP et UDP).

Par défaut, le trafic de sortie passe par l'un des chemins suivants lorsque vous quittez Cloud Run :

  • La destination cible se trouve dans le réseau VPC : le trafic est acheminé vers un réseau VPC ou un réseau VPC partagé de votre projet à l'aide d'une sortie VPC directe ou d'un connecteur d'accès au VPC sans serveur. Le connecteur est une ressource régionale située directement sur le réseau VPC.
  • La destination cible ne se trouve pas dans le réseau VPC : les routes de trafic sont directement dirigées vers la destination cible dans le réseau Google ou l'Internet public.
Schéma des composants de l'infrastructure Cloud Run
Figure 3. Le trafic sortant peut être transmis par proxy à un réseau VPC via un connecteur. Il peut également transiter directement vers un VPC ou vers un réseau non-VPC (Preview).

Contrôler la sortie

Pour mieux contrôler le trafic de sortie, utilisez le paramètre de sortie VPC pour acheminer tout votre trafic vers votre réseau VPC à l'aide d'une sortie VPC directe ou de connecteurs.

Une fois sur le réseau VPC, vous pouvez gérer le trafic à l'aide d'outils VPC, par exemple :

Les administrateurs de l'organisation peuvent également appliquer la sortie en définissant la contrainte de liste des Paramètres de sortie VPC autorisés (Cloud Run).

Trafic d'entrée (trafic entrant)

Contrairement au trafic de sortie, le trafic d'entrée de Cloud Run se trouve à la couche d'application 7 (HTTP).

Cloud Run accepte le trafic entrant provenant des sources suivantes :

  • Internet public : les requêtes sont acheminées directement depuis des sources publiques vers vos services Cloud Run, avec la possibilité de router le trafic via un équilibreur de charge HTTP(S) externe.

  • Réseau VPC : vous pouvez acheminer le trafic d'un réseau VPC vers les services Cloud Run à l'aide de l'Accès privé à Google, de Private Service Connect ou d'un équilibreur de charge d'application interne. Le trafic de ce type reste toujours sur le réseau de Google.

  • Services Google Cloud : le trafic est directement dirigé vers Cloud Run à partir d'autres services Google Cloud, tels que BigQuery ou même Cloud Run. Dans certains cas, vous pouvez également configurer ces services pour qu'ils routent via un réseau VPC. Le trafic de ce type reste toujours sur le réseau de Google.

Schéma des composants de l'infrastructure Cloud Run
Figure 4. Trafic d'entrée (trafic entrant) réseau HTTP de couche 7, vers Cloud Run.

Le modèle de sécurité réseau de Cloud Run inclut les propriétés de trafic d'entrée suivantes :

  • Diriger le trafic vers l'URL run.app : l'URL run.app nécessite toujours le protocole HTTPS pour que le trafic puisse entrer dans Cloud Run. L'infrastructure de diffusion d'interface de Google interrompt le protocole TLS, puis transfère le trafic à Cloud Run et à votre conteneur via un canal chiffré.
  • Trafic vers un domaine personnalisé associé à votre équilibreur de charge Google Cloud : Pour le trafic HTTPS, les équilibreurs de charge internes et externes de Google Cloud interrompent le protocole TLS et transfèrent le trafic vers Cloud Run et votre conteneur via un canal chiffré. Les équilibreurs de charge Google Cloud vous permettent également d'appliquer des fonctionnalités de sécurité supplémentaires telles que IAP, Google Cloud Armor et les règles SSL.

Pour en savoir plus sur la configuration du trafic réseau VPC vers Cloud Run, consultez la page Recevoir des requêtes provenant de réseaux VPC.

Contrôler l'entrée

Les contrôles d'entrée Cloud Run gèrent le trafic qui entre dans Cloud Run pour s'assurer que le trafic ne provient que de sources fiables.

Pour les services Cloud Run qui ne diffusent que des clients internes, vous pouvez configurer le paramètre "interne" afin que seul le trafic provenant des sources internes suivantes puisse entrer dans Cloud Run :

  • Réseaux VPC de votre projet ou périmètre VPC Service Controls, y compris les services Cloud Run qui acheminent tout leur trafic via le réseau VPC
  • Réseau VPC partagé auquel le service Cloud Run est associé
  • Certains services Google Cloud, tels que BigQuery, qui se trouvent dans votre projet ou votre périmètre VPC Service Controls
  • Trafic provenant de clients sur site qui transitent par votre réseau VPC pour atteindre Cloud Run

Les administrateurs de l'organisation peuvent également appliquer l'entrée en définissant des règles d'administration.

Pour en savoir plus sur le contrôle des entrées, consultez la section Restreindre l'entrée pour Cloud Run.

Contrôle des accès

Les contrôles d'accès permettent de restreindre l'accès à vos services et jobs Cloud Run.

Qui peut gérer votre service ou votre job

Pour contrôler qui gère votre service ou votre job Cloud Run, Cloud Run utilise IAM pour autoriser les utilisateurs et les comptes de service.

Éléments auxquels votre service ou votre job peut accéder

Pour contrôler quels éléments vos charges de travail Cloud Run peuvent atteindre via le réseau, vous pouvez forcer tout le trafic via le réseau VPC et appliquer des règles de pare-feu VPC, comme décrit précédemment dans la section Sécurité du réseau.

Si vous utilisez la sortie VPC directe, vous pouvez associer des tags réseau à la ressource Cloud Run et référencer les tags réseau dans la règle de pare-feu. Si vous utilisez l'accès au VPC sans serveur, vous pouvez appliquer des règles de pare-feu aux instances de connecteur.

Utilisez IAM pour contrôler les ressources auxquelles votre service ou votre job Cloud Run peut accéder. Les services et les jobs utilisent par défaut le compte de service Compute Engine par défaut. Pour les charges de travail sensibles, utilisez un compte de service dédié afin de pouvoir n'accorder que les autorisations nécessaires au fonctionnement de la charge de travail. Découvrez comment utiliser l'identité par service pour gérer un compte de service dédié. Pour plus d'informations sur la manière dont Cloud Run rappelle aux utilisateurs la création d'un compte de service dédié, consultez la page Sécuriser les services Cloud Run avec l'outil de recommandation.

Qui peut appeler votre service ou exécuter votre job

Cloud Run fournit plusieurs options pour contrôler qui appelle votre service ou exécute votre job.

Contrôles d'entrée

Pour gérer l'entrée des services Cloud Run au niveau de la mise en réseau, consultez la section Contrôler l'entrée dans la section précédente.

Les jobs Cloud Run ne diffusent pas de requêtes et n'utilisent donc pas les contrôles d'entrée lors de l'exécution de jobs.

IAM pour votre service

Cloud Run effectue une vérification IAM à chaque requête.

Utilisez l'autorisation run.routes.invoke pour configurer les utilisateurs autorisés à accéder à votre service Cloud Run de différentes manières :

  • Accordez l'autorisation de sélectionner des comptes de service ou des groupes pour autoriser l'accès au service. Toutes les requêtes doivent comporter un en-tête d'autorisation HTTP contenant un jeton d'identification OpenID Connect signé par Google pour l'un des comptes de service autorisés.

  • Accordez l'autorisation à tous les utilisateurs pour autoriser l'accès non authentifié.

Pour s'assurer que seuls les membres de votre organisation peuvent appeler un service Cloud Run, un administrateur de l'organisation peut définir une règle d'administration Partage restreint de domaine. Les administrateurs de l'organisation peuvent également désactiver des services Cloud Run spécifiques. Découvrez comment créer des services Cloud Run publics lorsque le partage restreint de domaine est appliqué.

Découvrez les cas d'utilisation courants de l'authentification et comment Cloud Run utilise le contrôle des accès avec IAM.

Fonctionnalités de sécurité de l'équilibreur de charge pour votre service

Si vous avez configuré un service Cloud Run en tant que backend pour un équilibreur de charge Google Cloud, sécurisez ce chemin à l'aide des méthodes suivantes :

IAM pour votre job

Utilisez l'autorisation run.jobs.run pour configurer qui peut exécuter votre job Cloud Run de différentes manières :

  • Accordez l'autorisation de sélectionner des comptes de service ou des groupes pour autoriser l'accès au job. Si le job est déclenché par un autre service, tel que Cloud Scheduler, le compte de service utilisé doit disposer de l'autorisation run.jobs.run sur le job.

  • Accordez à l'utilisateur connecté l'autorisation d'exécuter un job à partir de la console Google Cloud. Si le job est déclenché par un autre service, tel que Cloud Scheduler, le compte ou le groupe de services utilisé doit disposer de l'autorisation run.jobs.run sur le job.

Pour garantir que seuls les membres de votre organisation peuvent exécuter un job Cloud Run, un administrateur de l'organisation peut définir la contrainte de partage restreint de domaine. Les administrateurs de l'organisation peuvent également désactiver des jobs Cloud Run spécifiques.

VPC Service Controls

Vos services Cloud Run peuvent faire partie d'un périmètre VPC Service Controls pour vous permettre de contrôler les accès et de limiter le risque d'exfiltration à l'aide de VPC Service Controls. Découvrez comment utiliser VPC Service Controls.

Sécurité de la chaîne d'approvisionnement

Images de base gérées par les buildpacks de Google Cloud

Les services déployés à partir du code source à l'aide des buildpacks de Google Cloud sont créés à l'aide d'images de base fournies par Google. Google gère ces images de base et fournit des correctifs de routine chaque semaine. Dans les situations d'urgence impliquant des failles de sécurité critiques, nous sommes en mesure de rendre les correctifs disponibles en quelques heures.

Sécurité sur la chaîne d'approvisionnement interne de Cloud Run

Comme Cloud Run fonctionne sur Borg, Cloud Run met en œuvre la même sécurité de la chaîne d'approvisionnement standard à tous les services Google, tels que Gmail et YouTube. Pour en savoir plus sur les pratiques de chaîne d'approvisionnement interne de Google, consultez les livres blancs BeyondProd et Authorisation binaire pour Borg.

Autorisation binaire

Cloud Run intègre la compatibilité avec l'autorisation binaire afin de garantir que seules les images de conteneur fiables sont déployées sur Cloud Run. Pour en savoir plus, consultez la page Configurer Cloud Run.

Informations sur la sécurité de la chaîne d'approvisionnement logicielle

Les administrateurs Cloud peuvent afficher les informations de sécurité concernant la chaîne d'approvisionnement de leurs conteneurs déployés directement à partir d'un panneau de la console Google Cloud. Pour en savoir plus, consultez la page Afficher des insights sur la sécurité de la chaîne d'approvisionnement logicielle.

Sécurité de l'environnement d'exécution

Cloud Run est compatible avec les mises à jour automatiques des images de base avec des conteneurs compatibles. Les mises à jour de sécurité sont appliquées sans interruption du service en exécutant une redéfinition sur l'image de base du conteneur.

Les services déployés à partir de la source, y compris Cloud Run, utilisent les buildpacks de Google Cloud et sont compatibles avec les mises à jour de sécurité automatiques.

Les services pour lesquels les mises à jour de sécurité automatiques sont activées sont déployés à l'aide d'images de base fournies par Google. Google gère ces images de base et fournit des correctifs de routine après une période de tests de stabilité. Dans les situations d'urgence impliquant des failles de sécurité critiques, nous sommes en mesure de rendre les correctifs disponibles en quelques heures.

Pour en savoir plus sur les mises à jour de sécurité de l'environnement d'exécution, découvrez comment configurer les mises à jour de sécurité.

Étape suivante

Pour obtenir un tutoriel détaillé sur la configuration de la mise en réseau, consultez le guide de mise en réseau sans serveur de Cloud Run.