Cette page a été traduite par l'API Cloud Translation.

Sécuriser le trafic d'entrée Cloud Run

1. Présentation

Cet atelier vous explique comment limiter l'accès à un service Cloud Run et n'autoriser que les requêtes provenant d'une charge de travail exécutée sur site ou dans le VPC de votre projet. Vous pouvez utiliser deux niveaux de contrôle des accès: les paramètres d'entrée et les stratégies de gestion de l'authentification et des accès (IAM).

Paramètres d'entrée

Les paramètres d'entrée vous permettent de filtrer les requêtes en fonction de leur origine réseau (interne ou externe). Par défaut, toutes les requêtes sont autorisées à passer, y compris celles provenant d'Internet public.

Règlement IAM

Les règles IAM vous permettent de filtrer les requêtes en fonction de l'identité de l'expéditeur. Elles sont couramment utilisées pour authentifier les requêtes de service à service.

Dans cet atelier, vous allez apprendre à utiliser les paramètres d'entrée et à déterminer quand les utiliser.

Les hôtes sur site se connectent via le VPC

Dans cet atelier, nous allons simuler une charge de travail sur site. Pour connecter un hôte sur site à Cloud Run, vous devez configurer l' accès privé à Google pour les hôtes sur site. Cela inclut la configuration d'une passerelle Cloud VPN dans le réseau VPC, comme illustré ci-dessous.

Simuler une charge de travail sur site à l'aide d'un serveur de saut dans le VPC

Dans cet atelier, vous allez simuler l'envoi de requêtes à partir d'un hôte sur site en envoyant des requêtes à partir d'une machine virtuelle Compute Engine dans le VPC, comme illustré ci-dessous.

La machine virtuelle Compute Engine que vous utiliserez comme serveur de saut a la même origine réseau que la passerelle VPN Cloud. Vous pouvez donc l'utiliser pour simuler l'envoi de requêtes à partir d'une charge de travail sur site.

2. Préparation

Configuration de l'environnement d'auto-formation

Connectez-vous à la console Google Cloud, puis créez un projet ou réutilisez un projet existant. (Si vous ne possédez pas encore de compte Gmail ou Google Workspace, vous devez en créer un.)

Le nom du projet est le nom à afficher pour les participants au projet. Il s'agit d'une chaîne de caractères non utilisée par les API Google. Vous pouvez le mettre à jour à tout moment.
L'ID du projet est unique parmi tous les projets Google Cloud et non modifiable une fois défini. La console Cloud génère automatiquement une chaîne unique (en général, vous n'y accordez d'importance particulière). Dans la plupart des ateliers de programmation, vous devrez indiquer l'ID de votre projet (généralement identifié par PROJECT_ID). Si l'ID généré ne vous convient pas, vous pouvez en générer un autre de manière aléatoire. Vous pouvez également en spécifier un et voir s'il est disponible. Après cette étape, l'ID n'est plus modifiable et restera donc le même pour toute la durée du projet.
Pour information, il existe une troisième valeur (le numéro de projet) que certaines API utilisent. Pour en savoir plus sur ces trois valeurs, consultez la documentation.

Vous devez ensuite activer la facturation dans la console Cloud pour utiliser les ressources/API Cloud. L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Pour désactiver les ressources et éviter ainsi que des frais ne vous soient facturés après ce tutoriel, vous pouvez supprimer le projet ou les ressources que vous avez créées. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai gratuit pour bénéficier d'un crédit de 300 $.

Configuration de l'environnement

Définissez une variable d'environnement sur l'ID de projet pour l'utiliser dans les commandes ultérieures:

export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1
export ZONE=us-central1-a

Activez les API requises pour exécuter cet atelier.

gcloud services enable \
  run.googleapis.com \
  cloudbuild.googleapis.com \
  compute.googleapis.com \
  artifactregistry.googleapis.com

Cloner le dépôt de l'application exemple et accéder au répertoire

git clone https://github.com/GoogleCloudPlatform/cymbal-eats.git

cd cymbal-eats/partner-registration-service

Définir la région et la zone par défaut pour Compute Engine et Cloud Run

gcloud config set compute/region ${REGION}
gcloud config set run/region ${REGION}
gcloud config set compute/zone ${ZONE}

3. Déployer le service

Vous allez d'abord déployer le service et le laisser accessible au public. Une fois que vous aurez vérifié que vous pouvez envoyer des requêtes depuis votre navigateur, nous verrouillerons le service et n'autoriserons que les requêtes provenant de sources réseau internes.

Lorsque vous exécutez la commande suivante, suivez ces instructions:

Emplacement du code source (...): Vérifiez que vous êtes dans le répertoire partner-registration-service, puis appuyez sur Entrée pour accepter la valeur par défaut.
Nom du service (partner-registration-service): Appuyez sur Entrée pour accepter le nom par défaut
Autoriser les appels non authentifiés à [partner-registration-service] (y/N) ? Y

gcloud run deploy

Une fois cette commande exécutée, l'URL de votre service Cloud Run s'affiche. Le résultat ressemblera à cette liste:

Service [partner-registration-service] revision [partner-registration-service-00001-haz] has been deployed and is serving 100 percent of traffic.
Service URL: https://partner-registration-service-ssssssssss-uc.a.run.app

Ouvrez l'URL du service dans votre navigateur. Vous devriez obtenir le résultat suivant:

Partner registration service: RUNNING

Définir le service pour n'autoriser que les requêtes internes

Vous allez maintenant utiliser les paramètres d'entrée du service Cloud Run pour n'autoriser que les requêtes provenant de sources internes. Les sources internes incluent les ressources des réseaux VPC qui se trouvent dans le même projet (ou le même périmètre VPC Service Controls) que le service Cloud Run. C'est donc la solution idéale pour notre cas d'utilisation.

De plus, les requêtes provenant d'autres produits Google Cloud sont considérées comme internes, même si elles ne font pas partie du VPC. Par exemple, Pub/Sub et Workflows.

Les requêtes provenant de ces sources restent dans le réseau Google, même si elles accèdent à votre service à l'URL run.app, et l'accès public est interdit.

Mettez à jour le service pour n'autoriser que les requêtes internes:

gcloud run services update partner-registration-service --ingress=internal

Si vous ouvrez à nouveau l'URL du service, le message suivant s'affiche : Error: Forbidden - Access is forbidden (Erreur : Accès interdit).

Étant donné que votre navigateur envoie la requête à partir d'une origine réseau externe et non d'une origine interne au projet Google Cloud, c'est exactement ce que vous attendez. Votre service est désormais plus sécurisé.

4. Créer une machine virtuelle Compute Engine en tant que serveur de saut

L'étape suivante consiste à simuler les requêtes d'un serveur sur site via une passerelle Cloud VPN en créant une instance Compute Engine dans le VPC à utiliser comme serveur de saut:

gcloud compute instances create jump-server --scopes=https://www.googleapis.com/auth/cloud-platform

Le résultat de cette commande devrait ressembler à ceci:

NAME         ZONE           MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP   STATUS
jump-server  us-central1-a  n1-standard-1               10.128.0.10  34.170.108.8  RUNNING

Envoyer une requête de l'instance Compute Engine au service

Vous allez maintenant ouvrir un terminal sur la machine virtuelle et envoyer une requête directement depuis la machine sur le réseau VPC.

Si la commande suivante vous invite à configurer SSH dans Cloud Shell, suivez les instructions:

gcloud compute ssh jump-server

Obtenez l'URL du service Cloud Run avec cette commande:

gcloud run services describe partner-registration-service --region us-central1

Les premières lignes de la sortie doivent se présenter comme suit:

✔ Service partner-registration-service in region us-central1

URL:     https://partner-registration-service-ssssssssss-uc.a.run.app
Ingress: internal

Copiez l'URL, puis envoyez une requête depuis l'instance Compute Engine à l'aide de curl. Cette requête devrait aboutir, car l'instance de VM s'exécute sur le réseau VPC de votre projet. Il s'agit d'une source interne.

export SERVICE_URL=https://

curl ${SERVICE_URL}

Le résultat doit être le suivant:

Partner registration service: RUNNING

5. Qu'en est-il du contrôle des accès basé sur IAM ?

Cet atelier vous a montré comment et quand utiliser les paramètres d'entrée. Les paramètres d'entrée constituent un excellent premier pas si vous connectez une charge de travail sur site à Cloud Run.

Le contrôle des accès basé sur IAM nécessite plus d'efforts d'implémentation, en particulier si vous appelez depuis un hôte sur site:

IAM vous oblige à gérer les identifiants de compte de service de longue durée sur l'hôte
IAM nécessite des modifications de code pour signer les requêtes à l'aide des identifiants du compte de service.

Google recommande une approche multicouche pour le contrôle des accès. Utiliser des paramètres d'entrée pour limiter l'accès aux hôtes internes uniquement est un excellent premier pas, mais ne vous arrêtez pas là !

6. Félicitations !

Félicitations, vous avez terminé cet atelier de programmation.

Étapes suivantes :

Découvrez les autres ateliers de programmation Cymbal Eats:

Effectuer un nettoyage

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez chaque ressource individuellement.

Supprimer le projet

Le moyen le plus simple d'empêcher la facturation est de supprimer le projet que vous avez créé pour ce tutoriel.

Références utiles

Voici d'autres ressources qui vous aideront à en savoir plus sur les deux niveaux de contrôle des accès dans Cloud Run.