Configurer une connexion multicloud pour le catalogue Snowflake Horizon

Une connexion cross-cloud à un catalogue Snowflake Horizon vous permet d'interroger les données de ce catalogue directement dans Google Cloud. Cette fonctionnalité unifie votre analyse de données en intégrant vos sources de données externes à votre environnementGoogle Cloud existant.

Une fois la connexion configurée, vous pouvez gérer l'accès à vos données fédérées dans un Lakehouse sans frontières.

Avant de commencer

  1. Consultez la présentation de Lakehouse pour comprendre comment Lakehouse gère l'accès aux données.
  2. Pour en savoir plus sur le fonctionnement de l'accès aux données cross-cloud, consultez Accéder aux données cross-cloud.
  3. Consultez les catalogues compatibles pour vérifier les configurations compatibles.
  4. Découvrez comment utiliser les secrets Secret Manager régionaux. Cette opération est requise pour configurer Lakehouse avec le catalogue Snowflake Horizon à l'aide de l'authentification basée sur un secret.
  5. (Facultatif) Si vous prévoyez d'acheminer les requêtes via une interconnexion privée entre votre VPC Google Cloud et le VPC de votre fournisseur de services cloud distant (par exemple, AWS), assurez-vous de disposer d'un compte actif auprès de votre fournisseur distant, provisionnez une interconnexion Cross-Cloud Interconnect dédiée ou une interconnexion Cross-Cloud Interconnect partenaire, établissez des sessions BGP avec votre Cloud Router et vérifiez que vous disposez des autorisations IAM requises dans les deux environnements cloud.
  6. Connectez-vous à votre compte Google Cloud . Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits sans frais pour exécuter, tester et déployer des charges de travail.

  7. Verify that billing is enabled for your Google Cloud project.

  8. Enable the BigLake, Secret Manager APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  9. Verify that billing is enabled for your Google Cloud project.

  10. Enable the BigLake, Secret Manager APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

    11.

Rôles requis

Pour obtenir les autorisations nécessaires pour configurer l'accès cross-cloud, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet :

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Limites et points à noter

Cette section liste les limites et les points à prendre en compte pour accéder aux données cross-cloud.

  • Fournisseurs de services cloud interconnexion cross-cloud Interconnect : l'utilisation d'une interconnexion privée avec votre lakehouse sans frontières est compatible avec les fournisseurs de services cloud distants suivants : Amazon Web Services (AWS). Vous pouvez utiliser une interconnexion Cross-Cloud dédiée ou une interconnexion Cross-Cloud partenaire.
  • Routage réseau : si une interconnexion privée (telle que Dedicated CCI ou Partner CCI) n'est pas configurée, les requêtes sont acheminées via l'Internet public. Cela peut entraîner des frais de sortie plus élevés de la part de votre fournisseur de services cloud distant et des performances moins prévisibles.
  • Tables compatibles avec le catalogue Snowflake Horizon : seules les tables Snowflake Iceberg sont synchronisées avec Lakehouse. Les tables natives Snowflake sont ignorées lors de l'actualisation des métadonnées.
  • Règle de réseau et adresses IP de sortie : lors de l'interrogation d'un compte Snowflake, Lakehouse s'appuie sur les adresses IP de sortie de l'infrastructure globale pour atteindre le point de terminaison Snowflake accessible sur Internet. La sortie provient de larges plages d'infrastructure Google. Dans votre cloud distant, utilisez goog.json pour ajouter les plages d'adresses IP de sortie Google à la liste d'autorisation de votre règle de réseau Snowflake.
  • Lecture seule : les catalogues fédérés dans Lakehouse sont des vues en lecture seule du catalogue distant. La manipulation des ressources (par exemple, la création, la mise à jour ou la suppression de ressources) n'est pas possible et doit être effectuée directement dans le catalogue distant.
  • Fraîcheur des données : l'option --refresh-interval d'un catalogue fédéré détermine la fréquence de synchronisation des métadonnées. La valeur doit être 0s (désactivé) ou au moins 300s (5 minutes). L'actualisation des métadonnées en arrière-plan d'un catalogue peut prendre plus de temps s'il existe davantage de ressources d'espace de noms et de table. Si l'actualisation précédente dépasse le délai, l'actualisation actuelle sera ignorée, mais l'actualisation suivante sera planifiée à l'intervalle suivant. Les requêtes utilisent les métadonnées du catalogue synchronisées le plus récemment. Par conséquent, les modifications apportées au catalogue distant, telles que les nouvelles tables, les mises à jour de schéma ou les données récemment validées, ne sont pas visibles dans Lakehouse tant que l'actualisation des métadonnées en arrière-plan n'est pas terminée.
  • Mise en cache Lakehouse : la mise en cache Lakehouse est activée automatiquement pour toutes les requêtes cross-cloud afin de réduire les coûts de sortie en stockant les blocs de données localement dans Google Cloud. Les clés de chiffrement gérées par le client (CMEK) ne sont pas compatibles avec la mise en cache. Les données mises en cache sont chiffrées à l'aide de Google-owned and Google-managed encryption keys. Si la contrainte de règle d'administration constraints/gcp.restrictNonCmekServices est appliquée à une table de la requête, la mise en cache est automatiquement désactivée pour cette requête. Pour en savoir plus, consultez Mise en cache intelligente.
  • Résidence des données et conformité : la création d'un catalogue ou d'une connexion fédérés dans une région Google Cloud stocke les données mises en cache au repos dans cette région cible. Si vos données cloud distantes résident dans une autre juridiction, assurez-vous que la mise en cache interrégionale est conforme aux exigences de résidence des données et de conformité réglementaire de votre organisation.

Workflow général

Pour accéder aux données cross-cloud, suivez ces étapes générales :

  • Configurer Cross-Cloud Interconnect (facultatif) : configurez une connexion privée entre votre VPC Google Cloud et votre fournisseur de services cloud distant.
  • Configurer la fédération : configurez l'authentification et créez un catalogue fédéré dans Lakehouse.
    • Authentification basée sur un secret (PAT) : créez un secret dans Secret Manager avec les identifiants de votre catalogue distant. Ensuite, créez un catalogue fédéré dans Lakehouse et accordez au compte de service du catalogue l'accès au secret.
    • Fédération d'identité de charge de travail (WIF) : créez un catalogue fédéré dans Lakehouse en spécifiant le rôle Snowflake requis. Ensuite, associez l'ID du compte de service du catalogue à un utilisateur de service dans Snowflake. L'utilisateur du service Snowflake doit disposer d'autorisations d'utilisation sur le catalogue Snowflake Horizon distant.
  • Vérifier la connexion : vérifiez que Lakehouse peut se connecter à votre catalogue distant.
  • Interroger des données : exécutez des requêtes sur vos données fédérées à l'aide de BigQuery ou de Managed Service pour Apache Spark. La mise en cache Lakehouse est activée automatiquement pour les requêtes afin de réduire les coûts de sortie. Pour en savoir plus, consultez Interroger des données distantes.
  • Configurer les autorisations : utilisez IAM pour gérer les utilisateurs autorisés à afficher et à interroger les données fédérées.

Configurer interconnexion cross-cloud (facultatif)

Par défaut, les requêtes adressées à votre catalogue distant transitent par l'Internet public. Pour améliorer la sécurité et la conformité, fournir des performances prévisibles et réduire les coûts de transfert de données, utilisez une interconnexion privée. Cela établit une connexion réseau privée dédiée entre votre cloud privé virtuel (VPC) Google Cloudet le réseau de votre fournisseur de services cloud distant (par exemple, AWS).

Vous pouvez provisionner et configurer l'une des options d'interconnexion privée suivantes entre votre VPC Google Cloud et le VPC de votre fournisseur de services cloud distant (par exemple, AWS) :

Établissez des sessions BGP entre votre routeur Cloud Router dans Google Cloud et le VPC de votre fournisseur de services cloud distant pour assurer l'échange de routes.

Pour activer l'interrogation privée, vous devez configurer un chemin d'accès de Lakehouse vers votre bucket de stockage distant (par exemple, un bucket AWS Amazon S3) via votre interconnexion privée. Vous pouvez suivre deux flux architecturaux pour configurer ce routage :

  • Routage de l'équilibreur de charge réseau proxy interne régional : ce flux utilise un équilibreur de charge réseau proxy interne régionalGoogle Cloud pour répartir les requêtes entre les groupes de points de terminaison du réseau (NEG) de connectivité hybride pointant vers plusieurs interfaces réseau Elastic (ENI) AWS. Ce flux est essentiel pour l'équilibrage de charge, l'évolutivité et la haute disponibilité. Il est requis pour Partner CCI et recommandé pour Dedicated CCI pour l'équilibrage de charge, l'évolutivité et la haute disponibilité.
  • Routage direct des points de terminaison : ce flux connecte l'Annuaire des services directement à une seule adresse IP de point de terminaison d'interface VPC AWS. Ce flux ne fonctionne que pour CCI dédié et n'est pas compatible avec CCI partenaire.

Sélectionnez le flux de configuration qui correspond à vos exigences d'architecture :

Équilibreur de charge réseau proxy interne régional

Pour configurer un équilibreur de charge réseau proxy régional interne afin de répartir les requêtes entre plusieurs ENI AWS pour la haute disponibilité et l'équilibrage de charge, procédez comme suit :

Configurer la mise en réseau AWS

Commencez par créer un point de terminaison d'interface VPC Amazon S3 (AWS PrivateLink) :

  1. Dans la console AWS VPC, créez un point de terminaison d'interface pour Amazon S3.
  2. Pour le nom du service, spécifiez com.amazonaws.AWS_REGION.s3.
  3. Sélectionnez le VPC et les sous-réseaux connectés via Direct Connect à votre VPC Google Cloud .
  4. Associez des groupes de sécurité au point de terminaison pour contrôler l'accès entrant.
  5. Cette opération provisionne des interfaces réseau Elastic (ENI) dans chaque sous-réseau sélectionné. Notez les adresses IP privées de ces ENI.

Ensuite, configurez les groupes de sécurité :

  • Assurez-vous que le ou les groupes de sécurité associés aux ENI du point de terminaison Amazon S3 autorisent le trafic TCP entrant sur le port 443 depuis votre VPC Google Cloud . Cela doit inclure la plage CIDR de votre sous-réseau proxy réservéGoogle Cloud pour autoriser les vérifications d'état et le trafic transféré.

Configurer la mise en réseau Google Cloud

Pour simplifier la configuration, exécutez les commandes suivantes afin de configurer l'équilibreur de charge interne. Pour en savoir plus ou pour découvrir des configurations avancées, consultez Configurer un équilibreur de charge réseau proxy interne régional pour les points de terminaison hybrides.

gcloud compute networks subnets create PROXY_SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK \
    --range=PROXY_SUBNET_RANGE

Remplacez les éléments suivants :

  • PROXY_SUBNET_NAME : nom du sous-réseau proxy réservé.
  • PROXY_SUBNET_RANGE : plage CIDR inutilisée dans votre réseau VPC (par exemple, 10.129.0.0/23).

  1. Créez une vérification d'état régionale :

    gcloud compute health-checks create tcp HEALTH_CHECK_NAME \
    --region=REGION \
    --port=443

    Remplacez les éléments suivants :

    • HEALTH_CHECK_NAME : nom de la vérification de l'état.
    • REGION : région Google Cloud (par exemple, us-east4).

  2. Créez des groupes de points de terminaison du réseau (NEG) de connectivité hybride et ajoutez des points de terminaison :

    Créez un NEG hybride (NON_GCP_PRIVATE_IP_PORT) pour chaque zone :

    gcloud compute network-endpoint-groups create NEG_NAME \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=ZONE \
    --network=VPC_NETWORK

    Ajoutez l'adresse IP privée de votre ENI AWS au NEG hybride correspondant :

    gcloud compute network-endpoint-groups update NEG_NAME \
    --zone=ZONE \
    --add-endpoint="ip=AWS_S3_IP,port=443"

    Remplacez les éléments suivants :

    • NEG_NAME : nom du NEG hybride.
    • ZONE : zone Google Cloud (par exemple, us-east4-a). Cette zone doit se trouver dans la région de votre rattachement de VLAN interconnexion cross-cloud.
    • VPC_NETWORK : nom de votre réseau VPC.
    • AWS_S3_IP : adresse IP privée du point de terminaison d'un VPC Amazon S3 AWS (ENI) dans cette zone.

    Répétez ces commandes pour créer des NEG et ajouter des points de terminaison pour d'autres zones si vos ENI AWS sont répartis sur plusieurs zones.

  3. Créez et configurez le service de backend :

    Créez un service de backend régional avec l'équilibrage de charge géré interne :

    gcloud compute backend-services create BACKEND_SERVICE_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=TCP \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION

    Ajoutez vos NEG hybrides au service de backend :

    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    --region=REGION \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=ZONE \
    --balancing-mode=CONNECTION \
    --max-connections=MAX_CONNECTIONS

    Remplacez les éléments suivants :

    • BACKEND_SERVICE_NAME : nom du service de backend.
    • NEG_NAME : nom du NEG hybride que vous avez créé à l'étape précédente.
    • ZONE : zone Google Cloud (par exemple, us-east4-a).
    • MAX_CONNECTIONS : nombre maximal de connexions simultanées que le backend doit gérer (par exemple, 100).

    Répétez la commande add-backend pour chaque NEG hybride que vous avez créé.

  4. Configurez l'interface de l'équilibreur de charge :

    Créez un proxy TCP cible :

    gcloud compute target-tcp-proxies create TARGET_PROXY_NAME \
    --backend-service=BACKEND_SERVICE_NAME \
    --region=REGION

    Créez une règle de transfert pour acheminer le trafic vers le proxy cible :

    gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=VPC_NETWORK \
    --subnet=VPC_SUBNET \
    --ports=443 \
    --region=REGION \
    --target-tcp-proxy=TARGET_PROXY_NAME \
    --target-tcp-proxy-region=REGION \
    --allow-global-access

    Remplacez les éléments suivants :

    • TARGET_PROXY_NAME : nom du proxy cible.
    • FORWARDING_RULE_NAME : nom de la règle de transfert.
    • VPC_SUBNET : nom de votre sous-réseau VPC.

Après avoir créé la règle de transfert pour l'équilibreur de charge, notez l'adresse IP interne qui lui est attribuée. C'est votre ILB_IP_ADDRESS.

Configurer l'Annuaire des services

Enregistrez l'adresse IP de l'ILB dans l'Annuaire des services pour que Lakehouse puisse la découvrir.

  1. Créez un espace de noms pour votre cloud distant :

    gcloud service-directory namespaces create NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION

    Remplacez les éléments suivants :

    • NAMESPACE : identifiant unique de votre espace de noms.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • REGION : région Google Cloud . Exemple : us-east4. Cette région doit être identique à celle du catalogue fédéré.

  2. Créez un service dans l'espace de noms de l'Annuaire des services :

    gcloud service-directory services create SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION

    Remplacez les éléments suivants :

    • SERVICE_NAME : identifiant unique de votre service.

  3. Créez un point de terminaison pour l'ILB dans le service :

    gcloud service-directory endpoints create ENDPOINT_NAME \
    --project=PROJECT_ID \
    --namespace=NAMESPACE \
    --service=SERVICE_NAME \
    --location=REGION \
    --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK \
    --address=ILB_IP_ADDRESS \
    --port=443

    Remplacez les éléments suivants :

    • ENDPOINT_NAME : identifiant unique de votre point de terminaison.
    • PROJECT_NUMBER : numéro de votre projet Google Cloud. Utilisez votre numéro de projet dans l'option --network.
    • ILB_IP_ADDRESS : adresse IP interne de votre règle de transfert d'équilibreur de charge interne.

Point de terminaison direct

Pour configurer l'Annuaire des services afin d'acheminer le trafic directement vers une seule adresse IP de point de terminaison d'interface VPC AWS, procédez comme suit :

  1. Créez un point de terminaison VPC d'interface pour Amazon S3 dans votre VPC AWS. Notez l'adresse IP et le port de ce point de terminaison.

  2. Créez un espace de noms pour votre cloud distant :

    gcloud service-directory namespaces create NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION

    Remplacez les éléments suivants :

    • NAMESPACE : identifiant unique de votre espace de noms.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • REGION : région Google Cloud . Exemple : us-east4. Cette région doit être identique à celle du catalogue fédéré.

  3. Créez un service dans l'espace de noms de l'Annuaire des services :

    gcloud service-directory services create SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION

    Remplacez les éléments suivants :

    • SERVICE_NAME : identifiant unique de votre service.

  4. Créez un point de terminaison dans le service contenant les informations de routage de votre point de terminaison VPC d'interface Amazon S3 :

    gcloud service-directory endpoints create ENDPOINT_NAME \
    --service=SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION \
    --address=S3_VPCE_IP_ADDRESS \
    --port=S3_VPCE_PORT \
    --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK

    Remplacez les éléments suivants :

    • ENDPOINT_NAME : identifiant unique de votre point de terminaison.
    • S3_VPCE_IP_ADDRESS : adresse IP de votre point de terminaison d'interface VPC Amazon S3. Exemple :10.0.1.45
    • S3_VPCE_PORT : numéro de port de votre point de terminaison d'interface VPC Amazon S3. Exemple :443
    • PROJECT_NUMBER : numéro de votre projet Google Cloud. Utilisez votre numéro de projet dans l'option --network.
    • VPC_NETWORK : nom du réseau VPC Google Cloud associé à votre interconnexion privée.

Configurer la fédération

Pour interroger vos données, vous devez configurer un catalogue fédéré Lakehouse qui se connecte à votre catalogue Snowflake Horizon distant.

Configurer l'authentification

La fédération nécessite des identifiants ou une configuration de rôle pour accéder au catalogue Snowflake Horizon distant. Choisissez l'une des méthodes suivantes.

Basée sur un secret (PAT)

Cette option utilise un jeton d'accès programmatique (PAT) stocké de manière sécurisée avec des secrets Secret Manager régionaux.

  1. Générez un jeton d'accès programmatique (PAT) disposant d'un accès en lecture au catalogue cible.

  2. Créez un fichier JSON nommé credentials.json avec votre charge utile :

    {
  "client_secret": "SNOWFLAKE_PAT_TOKEN",
  "scope": "session:role:SNOWFLAKE_ROLE"
}

    Remplacez les éléments suivants :

    • SNOWFLAKE_PAT_TOKEN : votre jeton d'accès programmatique Snowflake.
    • SNOWFLAKE_ROLE : rôle Snowflake spécifique requis pour la session. Exemple :ICEBERG_VIEW

  3. Configurez le point de terminaison régional pour Secret Manager :

    Par défaut, Secret Manager utilise un point de terminaison global. Toutefois, Lakehouse nécessite que vos secrets soient stockés dans la même région que votre catalogue Lakehouse. Pour interagir avec des Secrets régionaux à l'aide de la CLI gcloud, vous devez remplacer le point de terminaison de l'API par défaut pour votre session ou votre profil actuel.

    gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/

    Remplacez les éléments suivants :

    • REGION : région Google Cloud dans laquelle votre secret Secret Manager est stocké. Exemple : us-east4. Pour éviter les problèmes de connectivité, votre secret et votre catalogue doivent être créés dans la même région.

  4. Importez la charge utile dans Secret Manager :

    gcloud secrets create SNOWFLAKE_SECRET_NAME \
  --location="REGION" \
  --project="PROJECT_ID" \
  --data-file=credentials.json

    Remplacez les éléments suivants :

    • SNOWFLAKE_SECRET_NAME : nom de votre secret Snowflake.
    • PROJECT_ID : ID de votre projet Google Cloud .

Fédération d'identité de charge de travail

La fédération d'identité de charge de travail (WIF) évite l'utilisation de secrets de longue durée en associant directement un compte de service de catalogue Lakehouse à un utilisateur de service Snowflake. Aucune configuration préalable n'est requise. Poursuivez la création du catalogue fédéré.

Créer un catalogue fédéré

Créez le catalogue fédéré à l'aide de la console Google Cloud ou de la CLI gcloud.

Console

Pour créer un catalogue fédéré :

  1. Dans la console Google Cloud , accédez à Lakehouse.

    Accéder à Lakehouse

  2. Cliquez sur Créer un catalogue.

  3. Cliquez sur Catalogue fédéré.

    La section Configuration du catalogue s'affiche.

  4. Pour Source du catalogue fédéré, sélectionnez Snowflake (Horizon).

  5. Pour Emplacement des données, sélectionnez la région Lakehouse dans laquelle vous souhaitez créer le catalogue fédéré. Exemple :us-east4 Pour minimiser la latence (même sur l'Internet public), procédez comme suit lorsque vous sélectionnez une région :

    • Si votre catalogue Snowflake Horizon se trouve sur AWS, sélectionnez la régionGoogle Cloud la plus proche de votre région AWS.
    • Si votre catalogue Snowflake Horizon se trouve dans Google Cloud, sélectionnez exactement la même région.

  6. Cliquez sur Continuer.

    La section Détails de la connexion s'affiche.

  7. Dans la section Détails du catalogue distant, dans le champ Identifiant de compte Snowflake, saisissez l'identifiant de votre compte Snowflake. Par exemple : my_org-my_account.

  8. Dans le champ Entrepôt Snowflake, saisissez le nom de votre entrepôt Snowflake. Il s'agit également du nom de la base de données dans le catalogue Snowflake Horizon.

  9. Sélectionnez une option pour Méthode d'authentification :

    • Dans le champ Secret, saisissez le nom de votre secret pour Basé sur un secret (PAT). Utilisez le format suivant : projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME.
    • Pour OIDC, saisissez votre rôle Snowflake pour la fédération d'identité de charge de travail. Par exemple : ICEBERG_VIEW.

  10. Facultatif : Dans le champ Nom de l'annuaire des services, saisissez le chemin d'accès à votre service de l'Annuaire des services. Exemple : projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME. Cette étape n'est requise que si vous configurez une interconnexion privée (interconnexion cross-cloud).

  11. Cliquez sur Créer.

gcloud

Basée sur un secret (PAT)

Si vous utilisez l'authentification basée sur un secret, vous devez spécifier --secret-name.

Internet public (pas de CCI)

Si vous ne configurez pas CCI, la connexion transite de manière sécurisée sur l'Internet public.

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS"

Appartenant au client (CCI)

Si vous avez configuré une interconnexion privée (telle que Dedicated CCI ou Partner CCI), indiquez la référence du service de l'Annuaire des services.

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME"

Remplacez les éléments suivants :

  • FEDERATED_CATALOG_NAME : nom de votre catalogue fédéré.
  • PROJECT_ID : ID de votre projet Google Cloud .
  • REGION : région Lakehouse dans laquelle le catalogue fédéré est créé. Cette région doit être identique à celle de l'espace de noms de l'Annuaire des services et du secret régional.
  • SNOWFLAKE_SECRET_NAME : nom de votre secret Snowflake.
  • SNOWFLAKE_ACCOUNT_IDENTIFIER : identifiant de votre compte Snowflake.
  • SNOWFLAKE_WAREHOUSE : entrepôt Snowflake avec lequel vous souhaitez effectuer la fédération. Il s'agit également du nom de la base de données dans le catalogue Snowflake Horizon.
  • REFRESH_INTERVAL (facultatif) : spécifie la fréquence d'actualisation des métadonnées en arrière-plan. Définissez cette valeur en tant que durée, par exemple 330s ou 5m30s.
  • NAMESPACE_FILTERS : (facultatif) liste d'espaces de noms à fédérer, séparés par une virgule. Exemple :ns1,ns2 Si cette option est omise, tous les espaces de noms seront inclus.
  • Si vous utilisez une interconnexion privée (CCI) :
    • SERVICE_DIRECTORY_NAMESPACE : espace de noms de l'Annuaire des services que vous avez créé lors de la configuration de l'interconnexion privée.
    • SERVICE_NAME : nom du service de l'Annuaire des services que vous avez créé lors de la configuration de l'interconnexion privée.

Fédération d'identité de charge de travail

Si vous utilisez la fédération d'identité de charge de travail, vous devez spécifier --snowflake-role.

Internet public (pas de CCI)

Si vous ne configurez pas CCI, la connexion transite de manière sécurisée sur l'Internet public.

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --snowflake-role="SNOWFLAKE_ROLE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS"

Appartenant au client (CCI)

Si vous avez configuré une interconnexion privée (telle que Dedicated CCI ou Partner CCI), indiquez la référence du service de l'Annuaire des services.

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --snowflake-role="SNOWFLAKE_ROLE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME"

Remplacez les éléments suivants :

  • FEDERATED_CATALOG_NAME : nom de votre catalogue fédéré.
  • PROJECT_ID : ID de votre projet Google Cloud .
  • REGION : région Lakehouse dans laquelle le catalogue fédéré est créé. Cette région doit être identique à celle de l'espace de noms de l'Annuaire des services et du secret régional.
  • SNOWFLAKE_ACCOUNT_IDENTIFIER : identifiant de votre compte Snowflake.
  • SNOWFLAKE_WAREHOUSE : entrepôt Snowflake avec lequel vous souhaitez effectuer la fédération. Il s'agit également du nom de la base de données dans le catalogue Snowflake Horizon.
  • SNOWFLAKE_ROLE : rôle Snowflake spécifique requis pour la session. Exemple :ICEBERG_VIEW
  • REFRESH_INTERVAL : indique la fréquence d'actualisation des métadonnées en arrière-plan. Définissez cette valeur en tant que durée, par exemple 330s ou 5m30s.
  • NAMESPACE_FILTERS : (facultatif) liste d'espaces de noms à fédérer, séparés par une virgule. Exemple :ns1,ns2 Si cette option est omise, tous les espaces de noms seront inclus.
  • Si vous utilisez une interconnexion privée (CCI) :
    • SERVICE_DIRECTORY_NAMESPACE : espace de noms de l'Annuaire des services que vous avez créé lors de la configuration de l'interconnexion privée.
    • SERVICE_NAME : nom du service de l'Annuaire des services que vous avez créé lors de la configuration de l'interconnexion privée.

Terminer la configuration de l'authentification

Suivez la procédure d'authentification en utilisant le type d'authentification que vous avez choisi.

Basée sur un secret (PAT)

Lorsque le catalogue est créé, Lakehouse provisionne un compte de service unique pour celui-ci (renvoyé sous la forme biglake-service-account dans la description de la ressource).

Vous devez accorder à ce compte de service l'autorisation d'accéder au secret que vous avez créé précédemment. Notez que la propagation des stratégies IAM peut prendre quelques minutes.

Accordez au compte de service du catalogue l'autorisation d'accéder au secret :

gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
gcloud secrets add-iam-policy-binding SNOWFLAKE_SECRET_NAME \
  --project="PROJECT_ID" \
  --location="REGION" \
  --member="serviceAccount:$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
      --project="PROJECT_ID" \
      --format='value(biglake-service-account)')" \
  --role="roles/secretmanager.secretAccessor"

Pour vérifier que le compte de service du catalogue fédéré a accès au secret, exécutez la commande suivante :

gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
gcloud secrets get-iam-policy SNOWFLAKE_SECRET_NAME \
    --project="PROJECT_ID" \
    --location="REGION"

Dans le résultat, vérifiez que le rôle roles/secretmanager.secretAccessor est attribué au compte de service biglake-service-account.

Fédération d'identité de charge de travail

Après avoir créé le catalogue, vous devez associer l'identité de son compte de service à un utilisateur de service dans Snowflake.

  1. Extrayez l'ID du compte de service Lakehouse (Objet) des détails du catalogue.

    Vous pouvez l'obtenir à partir de la réponse JSON de la commande de création (champ biglake-service-account-id).

    Vous pouvez également exécuter la commande describe sur le catalogue pour obtenir la valeur :

    gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
  --project="PROJECT_ID"

    Recherchez biglake-service-account-id dans le résultat.

  2. Connectez-vous à votre instance de gestion Snowflake et exécutez le script suivant pour établir la relation de confiance avec l'identité de service Lakehouse :

    USE ROLE ACCOUNTADMIN;

CREATE USER SNOWFLAKE_SERVICE_USER
  TYPE = SERVICE
  WORKLOAD_IDENTITY = (
    TYPE = GCP
    SUBJECT = 'LAKEHOUSE_SERVICE_ACCOUNT_ID'
  )
  DEFAULT_ROLE = SNOWFLAKE_ROLE
  COMMENT = 'Service user for Lakehouse federation over WIF';

-- Also explicitly GRANT permissions to the role
GRANT ROLE SNOWFLAKE_ROLE TO USER SNOWFLAKE_SERVICE_USER;

    Remplacez les éléments suivants :

    • SNOWFLAKE_SERVICE_USER : nom du nouvel utilisateur de service dans Snowflake.
    • LAKEHOUSE_SERVICE_ACCOUNT_ID : ID du compte de service extrait à l'étape précédente.
    • SNOWFLAKE_ROLE : rôle Snowflake (doit correspondre au rôle spécifié lors de la création du catalogue).

Terminer la configuration de l'interconnexion privée (interconnexion cross-cloud uniquement)

Si vous acheminez le trafic via une interconnexion privée (CCI dédiée ou partenaire), vous devez accorder au compte de service du catalogue Lakehouse les autorisations nécessaires pour découvrir et autoriser les connexions via l'Annuaire des services.

Console

  1. Dans la console Google Cloud , accédez à la page IAM.

    Accéder à IAM

  2. Cliquez sur Accorder l'accès (ou Ajouter).

  3. Dans le champ Nouveaux comptes principaux, saisissez l'adresse e-mail du compte de service du catalogue Lakehouse. Vous pouvez récupérer cette adresse e-mail en décrivant le catalogue (voir l'onglet gcloud).

  4. Dans le menu Rôle, sélectionnez Lecteur de l'Annuaire des services (roles/servicedirectory.viewer).

  5. Cliquez sur Ajouter un autre rôle, puis sélectionnez Service autorisé PSC de l'Annuaire des services (roles/servicedirectory.pscAuthorizedService).

  6. Cliquez sur Enregistrer.

gcloud

Attribuez les rôles requis au compte de service du catalogue :

# Grant Service Directory Viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account)')" \
--role="roles/servicedirectory.viewer"

# Grant Service Directory PSC Authorized Service
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account)')" \
--role="roles/servicedirectory.pscAuthorizedService"

Vérifier la connexion

Vérifiez que le cycle d'actualisation des métadonnées en arrière-plan du catalogue s'est terminé correctement et que les espaces de noms et les tables sont synchronisés.

  1. Vérifiez que l'état de l'actualisation indique que l'opération a réussi :

    gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
  --project="PROJECT_ID"

  2. Vérifiez que les espaces de noms sont synchronisés :

    gcloud alpha biglake iceberg namespaces list \
  --project="PROJECT_ID" \
  --catalog="FEDERATED_CATALOG_NAME"

  3. Vérifiez que les tables d'un espace de noms sont synchronisées :

    gcloud alpha biglake iceberg tables list \
  --project="PROJECT_ID" \
  --catalog="FEDERATED_CATALOG_NAME" \
  --namespace="NAMESPACE_ID"

Étapes suivantes