Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Utiliser VPC Service Controls

Pour sécuriser votre configuration Network Connectivity Center (NCC), utilisez VPC Service Controls.

VPC Service Controls offre une sécurité supplémentaire pour les API et services Google, y compris votre configuration NCC. En plus d'IAM, VPC Service Controls limite les systèmes sources qui peuvent modifier la configuration NCC.

Cette page décrit un cas d'utilisation courant et un exemple de configuration permettant l'accès entre un hub NCC et des spokes VPC séparés par des périmètres de service.

Pour obtenir une documentation complète, consultez la présentation de VPC Service Controls.

Exemple : Propositions de spokes VPC multiprojets dans des périmètres de service

Si votre configuration exige qu'un hub NCC et ses spokes de VPC résident dans des projets différents appartenant à des périmètres VPC Service Controls distincts, vous devez configurer des règles d'entrée et de sortie dans les deux périmètres. Cela permet aux administrateurs de spoke de proposer un spoke VPC faisant référence au hub, et aux administrateurs de hub d'accepter les spokes proposés.

L'exemple présenté sur cette page suppose que l'administrateur du hub et les administrateurs des rayons appartiennent à des organisations distinctes.

Le tableau suivant récapitule les règles requises pour cet exemple :

Périmètre	Règle	Objectif
Périmètre spoke (projet spoke)	Règle d'Ingress 1	Autoriser l'administrateur de spoke à lancer une proposition de spoke en créant un spoke dans le projet de spoke (si la gestion s'effectue en dehors de `SpokePerimeter`)
Périmètre spoke (projet spoke)	Règle de sortie 1	Autoriser la proposition de spoke sortant à lancer l'association au hub dans le projet de hub, y compris la vérification du réseau VPC sous-jacent
Périmètre du hub (projet de hub)	Règle d'Ingress 1	Autoriser l'administrateur du hub à gérer le hub dans le projet de hub, y compris à accepter ou refuser les propositions de spoke (si le hub est géré en dehors de `HubPerimeter`)
	Règle d'Ingress 2	Autoriser la proposition de spoke entrant à initier l'association au hub
	Règle de sortie 1	Autoriser la proposition de spoke entrant à rappeler le projet de spoke pour terminer l'association du spoke au hub, y compris la vérification du réseau VPC sous-jacent

Règles concernant le périmètre des spokes

Pour activer la création et la gestion de spokes, l'administrateur de spoke configure les règles d'entrée et de sortie suivantes :

Règle Détails

Règle d'entrée 1 : création de rayons Lorsqu'un administrateur de spoke lance une proposition de spoke en exécutant la commande de création depuis l'extérieur du périmètre (par exemple, depuis un poste de travail administrateur, Cloud Shell ou la console Google Cloud ), VPC Service Controls évalue l'appel comme une requête d'entrée vers le projet de spoke. SpokePerimeter doit autoriser l'entrée à partir de l'identité et de l'origine réseau de l'administrateur du spoke pour l'API NCC.

Cette règle n'est pas nécessaire si la gestion des spokes est effectuée exclusivement à partir d'un réseau VPC protégé par SpokePerimeter.

Règle de sortie 1 : attachement du hub et validation du réseau Lorsqu'un administrateur de spoke propose un spoke, la demande lance l'association au hub dans le projet de hub. Dans la requête, l'API NCC valide également le réseau VPC sous-jacent à l'aide de l'API Compute Engine. SpokePerimeter doit autoriser la sortie de l'administrateur du spoke pour les API NCC et Compute Engine.

Règle	Détails
Règle d'entrée 1 : création de rayons	Lorsqu'un administrateur de spoke lance une proposition de spoke en exécutant la commande de création depuis l'extérieur du périmètre (par exemple, depuis un poste de travail administrateur, Cloud Shell ou la console Google Cloud ), VPC Service Controls évalue l'appel comme une requête d'entrée vers le projet de spoke. `SpokePerimeter` doit autoriser l'entrée à partir de l'identité et de l'origine réseau de l'administrateur du spoke pour l'API NCC. Cette règle n'est pas nécessaire si la gestion des spokes est effectuée exclusivement à partir d'un réseau VPC protégé par `SpokePerimeter`.
Règle de sortie 1 : attachement du hub et validation du réseau	Lorsqu'un administrateur de spoke propose un spoke, la demande lance l'association au hub dans le projet de hub. Dans la requête, l'API NCC valide également le réseau VPC sous-jacent à l'aide de l'API Compute Engine. `SpokePerimeter` doit autoriser la sortie de l'administrateur du spoke pour les API NCC et Compute Engine.

Définition du périmètre du spoke

Les exemples de règles d'entrée et de sortie des sections suivantes sont basés sur la définition de périmètre suivante.

Pour en savoir plus sur les périmètres de service, consultez Périmètres de service : détails et configuration.

# Spoke perimeter definition
name: accessPolicies/2345678901/servicePerimeters/SpokePerimeter
status:
  resources:
  - projects/222222222222
  restrictedServices:
  - networkconnectivity.googleapis.com
  - compute.googleapis.com
title: SpokePerimeter

Règle d'entrée du spoke

Cette section fournit un exemple d'implémentation de la règle d'entrée pour le périmètre spoke, comme décrit dans Règles du périmètre spoke. Cette règle n'est requise que si vous gérez des rayons en dehors de SpokePerimeter.

Pour en savoir plus sur la syntaxe des règles, consultez la documentation de référence sur les règles d'entrée. Pour appliquer des règles, consultez Configurer des règles d'entrée et de sortie.

echo """
# Rule 1: Allow the spoke administrator to initiate a spoke proposal by creating
# a spoke in the spoke project (if managing from outside SpokePerimeter)
- ingressFrom:
    identities:
    # Specify the principal identifier for the spoke administrator or deployment pipeline:
    - serviceAccount:spoke-admin-sa@spoke-project.iam.gserviceaccount.com
    # - group:spoke-admins@example.org
    # - user:spoke-admin@example.org
    sources:
    - accessLevel: accessPolicies/2345678901/accessLevels/SpokeAdminAccessLevel
    # Alternatively, specify a management project or VPC network if managing
    # from a VPC network outside the perimeter:
    # - resource: projects/MANAGEMENT_PROJECT_NUMBER
  ingressTo:
    operations:
    - serviceName: networkconnectivity.googleapis.com
      methodSelectors:
      - method: "*"
    resources:
    - projects/222222222222
""" > spoke-ingress.yaml

Nous vous recommandons de définir des règles d'entrée aussi spécifiques que possible :

identities : spécifiez uniquement l'identifiant de compte principal nécessaire pour votre environnement, plutôt que des types d'identité généraux. Dans cet exemple, la règle 1 spécifie un compte de service pour un pipeline de déploiement automatisé. Vous pouvez également spécifier un groupe Google pour l'administration de l'équipe ou un compte utilisateur individuel. Pour en savoir plus, consultez Identités compatibles avec les règles d'entrée et de sortie.
sources : restreignez les origines aux niveaux d'accès connus. Cet exemple spécifie un niveau d'accès à partir de la règle d'accès gérant SpokePerimeter pour autoriser les sources externes telles que les postes de travail des administrateurs, Cloud Shell ou la console Google Cloud . Vous pouvez également autoriser l'accès depuis un réseau VPC de gestion en dehors du périmètre en utilisant l'attribut - resource: pour spécifier le projet ou le réseau VPC. Pour en savoir plus, consultez Autoriser l'accès depuis l'extérieur d'un périmètre et Accès contextuel avec des règles d'entrée.
operations : les restrictions pour networkconnectivity.googleapis.com sont appliquées au niveau du service et nécessitent method: "*". Les méthodes plus précises ne sont pas disponibles pour ce service.
resources : spécifiez le numéro exact du projet de spoke dans resources. Évitez les caractères génériques (*).

Règle de sortie du spoke

Cette section fournit un exemple d'implémentation de la règle de sortie pour le périmètre spoke, comme décrit dans Règles du périmètre spoke.

Pour en savoir plus sur la syntaxe des règles, consultez la documentation de référence sur les règles de sortie.

echo """
# Rule 1: Allow the outbound spoke proposal to initiate attachment to the hub in
# the hub project, which includes verifying the backing VPC network
- egressTo:
    operations:
    - serviceName: networkconnectivity.googleapis.com
      methodSelectors:
      - method: "*"
    - serviceName: compute.googleapis.com
      methodSelectors:
      - method: NetworksService.Get
    resources:
    - projects/111111111111
  egressFrom:
    identities:
    # Specify the principal identifier for the spoke administrator or deployment pipeline:
    - serviceAccount:spoke-admin-sa@spoke-project.iam.gserviceaccount.com
    # - group:spoke-admins@example.org
    # - user:spoke-admin@example.org
""" > spoke-egress.yaml

Nous vous recommandons de définir des règles de sortie aussi spécifiques que possible :

identities : spécifiez uniquement l'identifiant de compte principal nécessaire pour votre environnement, plutôt que des types d'identité généraux. Dans cet exemple, la règle 1 spécifie un compte de service pour un pipeline de déploiement automatisé. Vous pouvez également spécifier un groupe Google pour l'administration de l'équipe ou un compte utilisateur individuel. Pour en savoir plus, consultez Identités compatibles avec les règles d'entrée et de sortie.
operations : les restrictions pour networkconnectivity.googleapis.com sont appliquées au niveau du service et nécessitent method: "*". Pour compute.googleapis.com, spécifiez method: NetworksService.Get afin d'autoriser la vérification du réseau VPC sous-jacent lors de l'association au hub.
resources : spécifiez le numéro exact du projet de hub dans resources. Évitez les caractères génériques (*).

Règles de périmètre du hub

Pour activer l'administration du hub et autoriser les propositions de spokes entrantes, l'administrateur du hub configure les règles d'entrée et de sortie suivantes :

Règle	Détails
Règle d'entrée 1 : gestion du hub	Lorsqu'un administrateur de hub gère le hub depuis l'extérieur du périmètre (par exemple, depuis un poste de travail administrateur, Cloud Shell ou la console Google Cloud ), VPC Service Controls évalue l'appel comme une requête d'entrée vers le projet du hub. Cette règle permet à l'administrateur du hub d'examiner les spokes proposés et de les accepter (en les faisant passer à l'état `ACTIVE`) ou de les refuser (en les faisant passer à l'état `REJECTED`). `HubPerimeter` doit autoriser l'entrée à partir de l'identité et de l'origine réseau de l'administrateur du hub. Cette règle n'est pas nécessaire si la gestion du hub est effectuée exclusivement à partir d'un réseau VPC protégé par `HubPerimeter`.
Règle d'entrée 2 : attachement du hub	Lorsqu'un administrateur de spoke propose un spoke, la demande lance l'association au hub dans le projet de hub. `HubPerimeter` doit autoriser l'entrée à partir de l'identité et de l'origine réseau de l'administrateur du spoke pour l'API NCC dans les périmètres de service.
Règle de sortie 1 : Association des spokes et validation du réseau	Lorsqu'un administrateur de spoke propose un spoke, la demande rappelle le projet de spoke pour terminer l'association du spoke au hub et le mettre à l'état `PENDING_REVIEW`. Dans la requête, l'API NCC valide également le réseau VPC sous-jacent à l'aide de l'API Compute Engine. `HubPerimeter` doit autoriser la sortie de l'administrateur du spoke pour les API NCC et Compute Engine.

Définition du périmètre du hub