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

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

1. Présentation

Dans cet atelier, vous allez découvrir comment restreindre 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 couches de contrôle des accès: les paramètres d'entrée et les stratégies IAM (Identity and Access Management).

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, y compris celles provenant de l'Internet public.

Règlement IAM

Les stratégies 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 découvrir comment et quand utiliser les paramètres d'entrée.

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 indiqué 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 depuis une machine virtuelle Compute Engine dans le VPC, comme indiqué ici.

La machine virtuelle Compute Engine que vous utiliserez en tant que serveur intermédiaire possède la même origine réseau que la passerelle Cloud VPN. C'est pourquoi vous pouvez 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 modifier à 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. généralement, vous ne vous souciez pas de ce que c’est. Dans la plupart des ateliers de programmation, vous devrez référencer l'ID du projet (il est généralement identifié comme PROJECT_ID). Si l'ID généré ne vous convient pas, vous pouvez en générer un autre au hasard. Vous pouvez également essayer la vôtre pour voir si elle est disponible. Il ne peut pas être modifié après cette étape et restera actif pendant toute la durée du projet.
Pour votre information, il existe une troisième valeur, le numéro de projet, utilisé par certaines API. 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 arrêter les ressources afin d'éviter que des frais ne vous soient facturés au-delà de ce tutoriel, vous pouvez supprimer les ressources que vous avez créées ou l'ensemble du projet. 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 du projet. Vous l'utiliserez dans des 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 réaliser cet atelier.

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

Clonez le dépôt de l'exemple d'application et accédez 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 commencerez par déployer le service et le laisser accessible publiquement. Après avoir 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 vous trouvez dans l'annuaire "partner-registration-service" et appuyez sur Entrée pour accepter la valeur par défaut.
Nom du service (partner-registration-service): appuyez sur Entrée pour accepter la valeur par défaut
Autoriser les appels non authentifiés à [partner-registration-service] (o/N) ? Y

gcloud run deploy

Une fois cette commande terminée, elle répertorie l'URL de votre service Cloud Run. Le résultat ressemblera à ceci:

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 de façon à 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 périmètre VPC Service Controls) que le service Cloud Run. Elles sont donc idéales 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. tels que 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 via 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 "Error: Forbidden - Access is forbidden" s'affiche.

Étant donné que votre navigateur envoie la requête au projet Google Cloud à partir d'une origine de réseau externe et non d'une origine interne, 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 intermédiaire

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 intermédiaire:

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

Le résultat de cette commande doit 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 au service depuis l'instance Compute Engine

Vous allez maintenant ouvrir un terminal sur la machine virtuelle et envoyer une requête directement à partir de la machine dans 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 à l'aide de la commande suivante:

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

Les premières lignes du résultat 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

Maintenant, copiez l'URL et envoyez une requête à partir de 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 indiquer:

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 une excellente première étape si vous connectez une charge de travail sur site à Cloud Run.

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

IAM nécessite de gérer des 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. L'utilisation de paramètres d'entrée pour restreindre l'accès aux hôtes internes uniquement est une excellente première étape, mais ce n'est pas tout !

6. Félicitations !

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

Étapes suivantes :

Découvrez d'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 des ressources supplémentaires pour en savoir plus sur les deux couches de contrôle des accès dans Cloud Run.