À propos du proxy d'authentification AlloyDB

Le proxy d'authentification AlloyDB est un connecteur qui vous permet d'établir des connexions autorisées et chiffrées à vos bases de données AlloyDB pour PostgreSQL sans gérer de certificats SSL ni configurer de règles de pare-feu. Pour obtenir un guide par étapes sur l'utilisation du proxy d'authentification, consultez Se connecter à l'aide du proxy d'authentification AlloyDB.

Avantages du proxy d'authentification AlloyDB

Le proxy d'authentification offre les avantages suivants par rapport à la connexion directe des clients aux bases de données AlloyDB :

  • Autorisation de connexion basée sur Identity and Access Management (IAM). Le proxy d'authentification utilise les identifiants et les autorisations d'un compte principal IAM pour autoriser les connexions aux instances AlloyDB.

  • Authentification IAM automatisée. Le proxy d'authentification peut authentifier automatiquement les utilisateurs de la base de données en fonction du compte principal IAM qui exécute le proxy.

  • Communication sécurisée et chiffrée. Le proxy d'authentification crée, utilise et gère automatiquement une connexion TLS mutuelle (mTLS) 1.3 à l'aide d'un algorithme de chiffrement AES 256 bits entre votre client et une instance AlloyDB pour valider les identités du client et du serveur, et chiffrer le trafic de données.

Pour en savoir plus sur la connexion aux instances AlloyDB, consultez Présentation de la connexion.

Fonctionnement du proxy d'authentification AlloyDB

Le proxy d'authentification AlloyDB s'exécute en tant que processus client local (alloydb-auth-proxy) dans l'environnement de votre application et écoute les connexions sur localhost (par défaut sur le port TCP 5432) ou sur un socket de domaine Unix local. Votre application se connecte à cet écouteur local à l'aide de pilotes et de protocoles de communication PostgreSQL standards, tandis que le client du proxy d'authentification transfère le trafic via un tunnel chiffré (mTLS 1.3 avec un chiffrement AES 256 bits) vers son processus de serveur proxy d'authentification associé s'exécutant sur l'instance AlloyDB. Chaque connexion établie via le proxy d'authentification crée une connexion à l'instance AlloyDB.

Lorsqu'une application se connecte au proxy d'authentification, le proxy vérifie si une connexion existante à l'instance AlloyDB cible est disponible. Si la connexion n'existe pas, le proxy appelle l'API AlloyDB pour obtenir un certificat SSL éphémère et l'utilise pour établir le tunnel mTLS vers l'instance. Les certificats SSL éphémères expirent au bout de 24 heures, et le proxy d'authentification les actualise automatiquement avant leur expiration.

Le proxy d'authentification appelle l'API AlloyDB via le nom de domaine alloydb.googleapis.com sur HTTPS. Par conséquent, votre pare-feu doit autoriser les connexions TCP sortantes sur le port 443 (HTTPS) à partir de la machine cliente.

Bien que le proxy d'authentification puisse écouter localement sur n'importe quel port, il crée uniquement des connexions sortantes vers votre instance AlloyDB sur le port TCP 5433. Si votre hôte client dispose d'un pare-feu sortant, il doit autoriser les connexions au port 5433 sur l'adresse IP de votre instance AlloyDB et au port 443 pour toutes les adresses IP.

Vous pouvez utiliser le proxy d'authentification sur tous les chemins de connectivité réseau AlloyDB :

  • Accès aux services privés (par défaut) : se connecte à l'adresse IP interne de l'instance au sein d'un réseau cloud privé virtuel (VPC) appairé.
  • Private Service Connect : se connecte via un point de terminaison Private Service Connect et un enregistrement DNS privé lorsque vous transmettez l'option --psc.
  • Adresse IP publique : se connecte à l'adresse IP publique de l'instance lorsque vous transmettez l'option --public-ip. Étant donné que le proxy d'authentification authentifie et chiffre les connexions à l'aide d'IAM et de mTLS sur le port 5433, vous n'avez pas besoin d'ajouter l'adresse IP de votre client aux réseaux externes autorisés lorsque vous vous connectez via le proxy d'authentification.

Comment le proxy d'authentification AlloyDB authentifie et autorise les connexions

Pour autoriser la connexion d'un client à une instance AlloyDB, le client du proxy d'authentification s'authentifie auprès de Google Cloud à l'aide des identifiants du compte principal IAM sur le client, puis vérifie que le compte principal IAM dispose des rôles IAM Client AlloyDB (roles/alloydb.client) et Consommateur Service Usage (roles/serviceusage.serviceUsageConsumer).

Par défaut, le client du proxy d'authentification utilise les identifiants par défaut de l'application (ADC) pour localiser les identifiants du client. Cela fournit aux applications un moyen unifié et standard de s'authentifier automatiquement sans modifier ni coder en dur les valeurs de configuration.

Authentification standard

Pour les configurations de développement et de production standards, vous n'avez pas besoin de configurer des identifiants ou des options personnalisés. Le client du proxy d'authentification résout automatiquement les identifiants à l'aide des chemins d'environnement standards. Selon l'environnement que vous utilisez pour exécuter le client du proxy d'authentification, il localise les identifiants à partir des sources suivantes :

  • Développement local. Lorsque vous développez en local, vous pouvez vous authentifier à l'aide de votre compte utilisateur Google personnel ou d'entreprise. Le client du proxy d'authentification détecte et utilise automatiquement ces identifiants. Il s'agit de l'approche recommandée pour le développement local, car elle évite d'avoir à télécharger localement les fichiers de clé de compte de service. Pour obtenir des instructions détaillées sur la configuration d'un environnement de développement local, consultez Se connecter depuis votre ordinateur portable et Installer l'outil de ligne de commande psql.

  • Environnements gérés par Google. Lorsque vous exécutez votre application sur un serviceGoogle Cloud (par exemple, des instances Compute Engine, Google Kubernetes Engine, Cloud Run, des fonctions Cloud Run ou App Engine), les identifiants du compte de service associé sont automatiquement fournis par le serveur de métadonnées de l'environnement. Le client du proxy d'authentification découvre et utilise automatiquement ces identifiants sans configuration supplémentaire.

    • Si la ressource de calcul se trouve dans le même projet que l'instance AlloyDB, le compte de service par défaut dispose généralement des autorisations nécessaires pour s'authentifier.
    • Si la ressource de calcul et l'instance AlloyDB se trouvent dans des projets différents, vous devez ajouter le compte de service de la ressource de calcul au projet contenant l'instance AlloyDB et lui attribuer les rôles requis.

Remplacer les identifiants

Dans des scénarios spécifiques (par exemple, lors de tests, d'une exécution en dehors deGoogle Cloudou lorsque vous souhaitez contourner les identifiants d'environnement standards), vous pouvez remplacer les identifiants à l'aide de l'une des méthodes suivantes :

  • Une clé de compte de service. Fournissez la clé via la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS ou l'option --credentials-file. Les clés de compte de service constituent un risque pour la sécurité si elles ne sont pas gérées correctement. Privilégiez donc l'une des sources standards lorsque cela est possible.

  • Un jeton d'accès OAuth 2.0 existant. Fournissez le jeton via l'option --token.

  • Identifiants gcloud CLI Fournissez ces identifiants via l'option --gcloud-auth. Nous ne recommandons pas cette option. Exécutez plutôt gcloud auth application-default login.

Pour en savoir plus sur la configuration de ces identifiants sur le client, consultez Se connecter à l'aide du proxy d'authentification AlloyDB. Pour obtenir des informations générales sur l'approche de Google Cloud en matière d'authentification, consultez la présentation de l'authentification.

Étapes suivantes