À propos du proxy d'authentification AlloyDB

Cette page présente le proxy d'authentification AlloyDB, un connecteur qui vous permet d'établir des connexions chiffrées et autorisées aux bases de données AlloyDB.

Pour obtenir un guide détaillé sur l'utilisation du proxy d'authentification, consultez Se connecter à l'aide du proxy d'authentification AlloyDB.

Avantages de l'utilisation 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 IAM : Le proxy d'authentification utilise les identifiants et les autorisations d'un principal Identity and Access Management (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 principal IAM exécutant 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 fonctionne avec un client local qui s'exécute dans l'environnement local. Pour communiquer avec le proxy d'authentification AlloyDB, votre application utilise le protocole de base de données standard de votre base de données.

Le proxy d'authentification AlloyDB se sert d'un tunnel sécurisé (mTLS 1.3, algorithme AES 256 bits) pour communiquer avec son processus associé qui est exécuté sur le serveur. Chaque connexion établie via le proxy d'authentification AlloyDB crée une connexion à l'instance AlloyDB.

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

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

Bien que le proxy d'authentification AlloyDB puisse écouter sur n'importe quel port, il crée uniquement des connexions sortantes vers l'instance AlloyDB sur le port 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. L'hôte client doit également autoriser les connexions au port 443, qui est le port HTTPS standard, à toutes les adresses IP.

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 principal IAM sur le client, puis valide que le principal IAM dispose des rôles IAM Client Cloud AlloyDB (roles/alloydb.client) et Consommateur Service Usage (roles/serviceusage.serviceUsageConsumer).

Par défaut, le client Auth Proxy utilise les identifiants par défaut de l'application (ADC) pour localiser les identifiants du client. Cela permet aux applications de s'authentifier automatiquement de manière unifiée et standard, 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 ni des indicateurs personnalisés. Le client Auth Proxy résout automatiquement les identifiants à l'aide des chemins d'environnement standards. En fonction de l'environnement que vous utilisez pour exécuter le client Auth Proxy, il recherche les identifiants dans les sources suivantes :

  • Développement local : Lorsque vous développez en local, vous pouvez vous authentifier à l'aide de votre compte utilisateur Google personnel ou professionnel. Le client Auth Proxy détecte et utilise automatiquement ces identifiants. Il s'agit de l'approche recommandée pour le développement local, car elle évite de devoir télécharger localement les fichiers de clé de compte de service.

  • Environnements gérés par Google. Lorsque vous exécutez votre application sur un serviceGoogle Cloud , tel que 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 Auth Proxy 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 l'authentification.
    • 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, pour les tests, l'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'indicateur --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. Par conséquent, privilégiez l'une des sources standards lorsque vous le pouvez.

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

  • Vos identifiants gcloud CLI Fournissez ces identifiants à l'aide du flag --gcloud-auth. Nous ne recommandons pas cette option. Exécutez plutôt gcloud auth application-default login.

Pour savoir comment configurer 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