Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
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.
Avantages de l'utilisation du proxy d'authentification AlloyDB
Le proxy d'authentification présente les avantages suivants par rapport à la connexion directe des clients aux bases de données AlloyDB :
Autorisation de connexion (AuthZ) 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.
Communication sécurisée et chiffrée : le proxy d'authentification crée, utilise et gère automatiquement une connexion TLS 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.
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é (TLS 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 autorise les principaux IAM
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 valide que le compte principal IAM dispose des rôles IAM Client Cloud AlloyDB (roles/alloydb.client) et Consommateur de l'utilisation du service (roles/serviceusage.serviceUsageConsumer).
Pour localiser les identifiants IAM sur le client, le client Auth Proxy recherche chacun des éléments suivants et effectue une tentative d'authentification auprès de Google Cloudavec le premier qu'il trouve :
Identifiants fournis par l'option --credentials-file
Utilisez un compte de service pour créer et télécharger le fichier de clé JSON associé, et définissez l'option --credentials-file sur le chemin du fichier lorsque vous démarrez le client du proxy d'authentification.
Le compte de service doit disposer des rôles IAM Client AlloyDB (roles/alloydb.client) et Consommateur Service Usage (roles/serviceusage.serviceUsageConsumer) pour l'instance AlloyDB.
Pour utiliser cette option sur la ligne de commande, appelez la commande alloydb-auth-proxy avec l'option --credentials-file définie sur le chemin d'accès et le nom de fichier d'un fichier d'identifiants JSON. Le chemin d'accès peut être absolu, ou relatif au répertoire de travail actuel.
Identifiants fournis par l'option --token
Créez un jeton d'accès et appelez la commande alloydb-auth-proxy avec l'option --token définie sur un jeton d'accès OAuth 2.0.
Identifiants fournis par une variable d'environnement
Cette option est semblable à l'utilisation de l'indicateur --credentials-file, sauf que vous spécifiez le fichier d'identifiants JSON que vous définissez dans la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS au lieu d'utiliser l'indicateur --credentials-file.
Identifiants d'un client Google Cloud CLI authentifié
Si vous avez installé la gcloud CLI et que vous vous êtes authentifié avec votre compte personnel, le client Auth Proxy peut utiliser les mêmes identifiants de compte si vous activez le paramètre --gcloud-auth. Cette méthode est particulièrement utile pour rendre opérationnel un environnement de développement.
Si aucun compte n'a été sélectionné pour gcloud auth login, le client Auth Proxy recherche un compte sélectionné pour gcloud
auth application-default login. Il s'agit du comportement par défaut lorsque vous n'activez pas l'indicateur --gcloud-auth.
Identifiants associés à l'instance Compute Engine
Si vous vous connectez à AlloyDB depuis une instance Compute Engine, le client du proxy d'authentification peut utiliser le compte de service associé à l'instance Compute Engine.
Si le compte de service dispose des rôles IAM (Identity and Access Management) Client AlloyDB Cloud (roles/alloydb.client) et Consommateur Service Usage (roles/serviceusage.serviceUsageConsumer) pour l'instance AlloyDB, le client Auth Proxy s'authentifie correctement.
Si l'instance Compute Engine se trouve dans le même projet que l'instance AlloyDB, le compte de service par défaut de l'instance Compute Engine dispose des autorisations nécessaires pour authentifier AlloyDB.
Si ces deux instances sont dans des projets différents, vous devez ajouter le compte de service de l'instance Compute Engine au projet contenant l'instance AlloyDB.
Compte de service par défaut de l'environnement
Si le client Auth Proxy ne trouve pas les identifiants dans l'un des emplacements abordés précédemment, il suit la logique décrite dans la section S'authentifier en tant que compte de service.
Certains environnements (tels que Compute Engine, App Engine et d'autres) fournissent un compte de service par défaut que votre application peut utiliser pour s'authentifier par défaut. Si vous utilisez un compte de service par défaut, il doit disposer des rôles IAM Client AlloyDB (roles/alloydb.client) et Consommateur Service Usage (roles/serviceusage.serviceUsageConsumer).
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/25 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/08/25 (UTC)."],[[["\u003cp\u003eThe AlloyDB Auth Proxy enables secure, encrypted connections to AlloyDB databases using IAM-based authorization.\u003c/p\u003e\n"],["\u003cp\u003eIt provides advantages over direct connections by using IAM credentials for authorization and establishing TLS 1.3 encrypted connections with a 256-bit AES cipher.\u003c/p\u003e\n"],["\u003cp\u003eThe Auth Proxy runs a local client that communicates with the application using standard database protocols and establishes connections to AlloyDB via secure tunnels.\u003c/p\u003e\n"],["\u003cp\u003eThe Auth Proxy automatically manages and refreshes ephemeral SSL certificates, which expire every 24 hours.\u003c/p\u003e\n"],["\u003cp\u003eThe AlloyDB Auth Proxy supports various methods for locating IAM credentials, including service account JSON key files, OAuth 2.0 access tokens, environment variables, gcloud CLI credentials, and Compute Engine instance credentials.\u003c/p\u003e\n"]]],[],null,["# About the AlloyDB Auth Proxy\n\nThis page provides an overview of the AlloyDB Auth Proxy, a connector that lets you\nmake authorized, encrypted connections to AlloyDB\ndatabases.\n\nFor a step-by-step guide to using the Auth Proxy, see [Connect using the AlloyDB Auth Proxy](/alloydb/docs/auth-proxy/connect).\n\nBenefits of using the AlloyDB Auth Proxy\n----------------------------------------\n\nThe Auth Proxy provides these advantages over connecting clients directly to\nAlloyDB databases:\n\n- **IAM-based connection authorization (AuthZ):** The Auth Proxy uses\n the credentials and permissions of an Identity and Access Management (IAM) principal to authorize connections to\n AlloyDB instances.\n\n- **Secure, encrypted communication:** The Auth Proxy automatically\n creates, uses, and maintains a TLS 1.3 connection\n using a 256-bit AES cipher\n between your client and an AlloyDB instance to verify client\n and server identities and encrypt data traffic.\n\nFor more information about to connecting to AlloyDB instances,\nsee [Connection overview](/alloydb/docs/connection-overview).\n\nHow the AlloyDB Auth Proxy works\n--------------------------------\n\nThe AlloyDB Auth Proxy works by having a local client running\nin the local environment. Your application communicates with the AlloyDB Auth Proxy\nwith the standard database protocol used by your database.\n\nThe AlloyDB Auth Proxy uses a secure tunnel (TLS 1.3,\n256-bit AES cipher) to\ncommunicate with its companion process\nrunning on the server. Each connection established through the AlloyDB Auth Proxy creates\none connection to the AlloyDB instance.\n\nWhen an application connects to the AlloyDB Auth Proxy, it checks whether an existing\nconnection between it and the target AlloyDB instance is available.\nIf a connection does not exist, it calls AlloyDB Admin APIs to obtain\nan ephemeral SSL certificate and uses it to connect to AlloyDB.\nEphemeral SSL certificates expire in 24 hours. The AlloyDB Auth Proxy refreshes\nthese certificates before they expire.\n\nThe AlloyDB Auth Proxy calls APIs through the domain name `alloydb.googleapis.com`\nusing HTTPS. As a result, all egress TCP connections on port 443 (HTTPS) from\nthe client machine must be allowed by your firewall.\n\nWhile the AlloyDB Auth Proxy can listen on any port, it creates outgoing or egress\nconnections to your AlloyDB instance only on port 5433. If your client\nhost has an outbound firewall, it must allow connections to port 5433 on your\nAlloyDB instance's IP address. The client host must also allow\nconnections to port 443, which is the standard HTTPS port, to all IP addresses.\n\nHow the AlloyDB Auth Proxy authorizes IAM principals\n----------------------------------------------------\n\nTo authorize a client's connection to an AlloyDB instance, the\nAuth Proxy client authenticates to Google Cloud using IAM principal\ncredentials on the client, and then validates that the IAM principal has the\nCloud AlloyDB Client (`roles/alloydb.client`) and Service Usage Consumer\n(`roles/serviceusage.serviceUsageConsumer`) IAM roles.\n\nTo locate the IAM credentials on the client, the Auth Proxy client checks\nfor each of the following items, using the first one it\nfinds to attempt authentication to Google Cloud:\n\n1. **Credentials supplied by the --credentials-file flag**\n\n Use a [service account](/alloydb/docs/auth-proxy/best-practices#using-a-service-account) to\n create and download the associated JSON key file, and set the\n `--credentials-file` flag to the path of the file when you start\n the Auth Proxy client.\n The service account must have the Cloud AlloyDB Client\n (`roles/alloydb.client`) and Service Usage Consumer\n (`roles/serviceusage.serviceUsageConsumer`)\n IAM roles for the AlloyDB instance.\n\n To use this option on the command-line, invoke the `alloydb-auth-proxy` command with\n the `--credentials-file` flag set to the path and filename of a JSON credential\n file. The path can be absolute, or relative to the current working directory.\n2. **Credentials supplied by the --token flag**\n\n [Create an\n access token](https://developers.google.com/oauthplayground/) and invoke the `alloydb-auth-proxy` command with the\n `--token` flag set to an OAuth 2.0 access token.\n3. **Credentials supplied by an environment variable**\n\n This option is similar to using the `--credentials-file` flag, except you specify\n the JSON credential file you set in the `GOOGLE_APPLICATION_CREDENTIALS` environment\n variable instead of using the `--credentials-file` flag.\n4. **Credentials from an authenticated Google Cloud CLI client**\n\n If you installed the [gcloud CLI](/sdk/gcloud)\n and have authenticated with your personal account, the Auth Proxy client\n can use the same account credentials if you enable the\n `--gcloud-auth` flag. This method is especially helpful for\n getting a development environment up and running.\n | To enable the Auth Proxy client to use your gcloud CLI credentials, use the `gcloud auth login` command to authenticate the gcloud CLI. To determine your current gcloud CLI credentials, use the `gcloud auth list` command.\n\n If no account was selected for `gcloud auth login`, the\n Auth Proxy client checks for an account that was selected for `gcloud\n auth application-default login`. This is the default behavior when you\n don't enable the `--gcloud-auth` flag.\n5. **Credentials associated with the Compute Engine instance**\n\n If you are connecting to AlloyDB from a Compute Engine instance, the\n Auth Proxy client can use the service account associated with the Compute Engine instance.\n If the service account has the Cloud AlloyDB Client\n (`roles/alloydb.client`) and Service Usage Consumer\n (`roles/serviceusage.serviceUsageConsumer`)\n Identity and Access Management (IAM) roles for the AlloyDB instance, the Auth Proxy client\n authenticates successfully.\n\n If the Compute Engine instance is in the same project as the AlloyDB\n instance, the default service account for the Compute Engine instance has the\n necessary permissions for authenticating the AlloyDB.\n If the two instances are in different projects, you must add the Compute Engine\n instance's service account to the project containing the AlloyDB\n instance.\n6. **Environment's default service account**\n\n If the Auth Proxy client cannot find credentials in any of the places covered earlier, it\n follows the logic documented in\n [Authenticating as a service account](/docs/authentication/production).\n Some environment (such as Compute Engine, App Engine, and others) provide a\n default service account that your application can use to authenticate by default. If\n you use a default service account, it must have the Cloud AlloyDB Client\n (`roles/alloydb.client`) and Service Usage Consumer\n (`roles/serviceusage.serviceUsageConsumer`) IAM roles.\n\n For more information about Google Cloud's approach to authentication, see\n [Authentication overview](/docs/authentication).\n\nWhat's next\n-----------\n\n- [Connect using the AlloyDB Auth Proxy](/alloydb/docs/auth-proxy/connect).\n- [Explore the Google Cloud GitHub repository for the AlloyDB Auth Proxy](https://github.com/GoogleCloudPlatform/alloydb-auth-proxy)."]]
