Cette page explique comment configurer une connexion à partir d'une application exécutée dans Google Kubernetes Engine (GKE) vers une instance Cloud SQL.
Pour obtenir des instructions détaillées sur l'exécution d'un exemple d'application Web Google Kubernetes Engine connectée à Cloud SQL, consultezDémarrage rapide pour la connexion depuis Google Kubernetes Engine.
Cloud SQL est un service de base de données entièrement géré qui vous aide à configurer, maintenir, gérer et administrer vos bases de données relationnelles dans le cloud.
Google Kubernetes Engine est un moyen simple de déployer, faire évoluer et gérer automatiquement Kubernetes.
À propos de la connexion de Google Kubernetes Engine à Cloud SQL
Pour accéder à une instance Cloud SQL depuis une application s'exécutant dans Google Kubernetes Engine, vous pouvez utiliser le proxy d'authentification Cloud SQL (avec une adresse IP publique ou privée) ou vous connecter directement à l'aide d'une adresse IP privée.
Le proxy d'authentification Cloud SQL est le mode de connexion à Cloud SQL recommandé même lorsque vous utilisez une adresse IP privée. En effet, le proxy d'authentification Cloud SQL assure un chiffrement et une authentification sécurisés à l'aide d'IAM, ce qui contribue à sécuriser votre base de données.
Les connexions aux bases de données consomment des ressources sur le serveur et sur l'application de connexion. Suivez toujours les bonnes pratiques en matière de gestion des connexions afin de réduire au maximum l'encombrement de votre application et les risques de dépassement des limites de connexion Cloud SQL. Pour en savoir plus, consultez la page Gérer les connexions à la base de données.
Avant de commencer
Pour vous connecter à Cloud SQL, vous devez disposer des éléments suivants :
Un cluster GKE sur lequel l'outil de ligne de commande
kubectl
est installé et configuré pour communiquer avec le cluster.Pour obtenir de l'aide sur la mise en route de GKE, consultez la page Déployer une application sur un cluster GKE.
Pour vous connecter à l'aide d'une adresse IP privée, le cluster GKE doit être VPC natif et appairé avec le même réseau cloud privé virtuel (VPC) que l'instance Cloud SQL.
Une instance créée
Pour savoir comment créer une instance Cloud SQL, consultez la page Créer des instances.
Un compte utilisateur MySQL configuré sur l'instance
Votre application utilisera ce compte pour se connecter à la base de données. Pour savoir comment créer un compte d'utilisateur, consultez la section Créer un utilisateur.
À propos des secrets Kubernetes
Dans Kubernetes, les secrets constituent un moyen sécurisé de transmettre les informations de configuration à votre application. Vous pouvez créer un secret contenant des informations telles que le nom de la base de données, l'utilisateur et le mot de passe, qui peuvent être injectées dans votre application sous forme de variables d'environnement.
Les secrets peuvent être utilisés de différentes manières, en fonction du type de connexion :
- Un secret d'identifiants de base de données inclut le nom d'utilisateur de la base de données avec lequel vous vous connectez, ainsi que son mot de passe pour la base de données.
- Si vous vous connectez avec le proxy d'authentification Cloud SQL, vous pouvez utiliser un secret pour conserver le fichier d'identifiants de votre compte de service.
- Si vous vous connectez avec une adresse IP privée, un secret peut être utilisé pour spécifier l'adresse IP privée de votre instance Cloud SQL.
Pour obtenir des exemples complets d'utilisation des secrets, consultez les dépôts GitHub référencés ultérieurement sur cette page.
Créer un objet Secret
Pour créer des objets Secret, utilisez la commande
kubectl create secret
.Pour créer un secret d'identifiants de base de données :
kubectl create secret generic <YOUR-DB-SECRET> \ --from-literal=username=<YOUR-DATABASE-USER> \ --from-literal=password=<YOUR-DATABASE-PASSWORD> \ --from-literal=database=<YOUR-DATABASE-NAME>
Une fois les objets créés, vous pouvez les afficher dans la section Configuration de la page Google Kubernetes Engine de Google Cloud Console.
Se connecter à Cloud SQL à l'aide du proxy d'authentification Cloud SQL
Lorsque vous vous connectez à l'aide du proxy d'authentification Cloud SQL, celui-ci est ajouté à votre pod à l'aide du modèle de conteneur sidecar
. Le conteneur du proxy d'authentification Cloud SQL se trouve dans le même pod que l'application, ce qui permet à celle-ci de se connecter au proxy Cloud SQL via localhost
, améliorant ainsi la sécurité et les performances.
Pour en savoir plus sur le proxy d'authentification Cloud SQL, consultez la page À propos du proxy d'authentification Cloud SQL. Pour plus d'informations sur l'utilisation des pods, consultez la page Présentation des pods dans la documentation Kubernetes.
Pour vous connecter à l'aide du proxy d'authentification Cloud SQL, vous avez besoin des éléments suivants :
Le nom de connexion de l'instance Cloud SQL.
Le nom de connexion de l'instance est disponible sur la page de Google Cloud Console contenant les détails de l'instance Cloud SQL, ou à l'aide de la commande
gcloud sql instances describe INSTANCE_ID
.L'emplacement du fichier de clé associé à un compte de service doté des droits appropriés pour l'instance Cloud SQL
Pour en savoir plus, consultez la section Créer un compte de service.
L'API Cloud SQL Admin activée
Fournir le compte de service au proxy d'authentification Cloud SQL
La première étape de l'exécution du proxy d'authentification Cloud SQL dans Google Kubernetes Engine consiste à créer un compte de service Google pour représenter votre application. Il est recommandé de créer un compte de service unique pour chaque application plutôt que d'utiliser le même compte de service partout. Ce modèle est plus sécurisé, car il vous permet de limiter les autorisations par application.
Le compte de service de votre application doit répondre aux critères suivants :
- Appartenir à un projet pour lequel l'API Cloud SQL Admin est activée.
- Le rôle IAM (ou équivalent) du client Cloud SQL a été attribué pour le projet contenant l'instance à laquelle vous souhaitez vous connecter.
- Si vous vous connectez à l'aide d'une adresse IP privée, vous devez utiliser un cluster GKE de VPC natif dans le même VPC que votre instance Cloud SQL.
Vous devez configurer GKE pour fournir le compte de service au proxy d'authentification Cloud SQL. Pour ce faire, deux méthodes sont recommandées : Workload Identity ou un fichier de clé du compte de service.
Workload Identity
Si vous utilisez Google Kubernetes Engine, la méthode recommandée consiste à utiliser la fonctionnalité Workload Identity de GKE. Cette méthode vous permet d'associer un compte de service Kubernetes (KSA) à un compte de service Google (GSA). Le GSA sera alors accessible aux applications utilisant le KSA correspondant.
Un compte de service Google (GSA) est une identité IAM qui représente votre application dans Google Cloud. De la même manière, un compte de service Kubernetes (KSA) est une identité qui représente votre application dans un cluster Google Kubernetes Engine.
Workload Identity associe un KSA à un GSA, ce qui entraîne l'authentification de tous les déploiements dotés de ce KSA en tant que GSA lors de leurs interactions avec Google Cloud.
- Activer Workload Identity pour votre cluster
En règle générale, chaque application possède sa propre identité, représentée par une paire KSA et GSA. Créez un KSA pour votre application en exécutant la commande
kubectl apply -f service-account.yaml
:Activez la liaison IAM entre YOUR-GSA-NAME et YOUR-KSA-NAME :
gcloud iam service-accounts add-iam-policy-binding \ --role="roles/iam.workloadIdentityUser" \ --member="serviceAccount:YOUR-GOOGLE-CLOUD-PROJECT.svc.id.goog[YOUR-K8S-NAMESPACE/YOUR-KSA-NAME]" \ YOUR-GSA-NAME@YOUR-GOOGLE-CLOUD-PROJECT.iam.gserviceaccount.com
Ajoutez une annotation à YOUR-KSA-NAME pour terminer la liaison :
kubectl annotate serviceaccount \ YOUR-KSA-NAME \ iam.gke.io/gcp-service-account=YOUR-GSA-NAME@YOUR-GOOGLE-CLOUD-PROJECT.iam.gserviceaccount.com
Enfin, assurez-vous de spécifier le compte de service pour l'objet k8s.
Fichier de clé du compte de service
Si vous ne pouvez pas utiliser Workload Identity, le modèle recommandé consiste à installer un fichier de clé de compte de service dans le pod du proxy d'authentification Cloud SQL et à utiliser l'option --credentials-file
.
Créez un fichier d'identifiants pour votre clé de compte de service :
gcloud iam service-accounts keys create ~/key.json \ --iam-account=YOUR-SA-NAME@project-id.iam.gserviceaccount.com
Transformez la clé de votre compte de service en secret k8s :
kubectl create secret generic YOUR-SA-SECRET \ --from-file=service_account.json=~/key.json
Installez le secret en tant que volume sous
spec:
pour votre objet k8s :Suivez les instructions de la section suivante pour accéder au volume à partir du pod du proxy d'authentification Cloud SQL.
Exécuter le proxy d'authentification Cloud SQL dans un modèle side-car
Nous vous recommandons d'exécuter le proxy d'authentification Cloud SQL dans un modèle sidecar
(en tant que conteneur supplémentaire partageant un pod avec votre application). Nous recommandons cette approche plutôt que de l'exécuter en tant que service distinct, pour plusieurs raisons :
- Empêcher l'exposition locale de votre trafic SQL. Le proxy d'authentification Cloud SQL assure le chiffrement des connexions sortantes mais vous devez limiter l'exposition aux connexions entrantes.
- Empêcher un point de défaillance unique : l'accès de chaque application à votre base de données est indépendant des autres, ce qui rend l'ensemble plus résilient.
- Limiter l'accès au proxy d'authentification Cloud SQL, ce qui vous permet d'utiliser les autorisations IAM par application plutôt que d'exposer la base de données à l'ensemble du cluster.
Permettre d'étendre la portée des demandes de ressources : comme le proxy d'authentification Cloud SQL consomme les ressources de façon linéaire, ce modèle vous permet de définir plus précisément la portée et les demandes des ressources pour les adapter à vos applications.
Ajoutez le proxy Cloud SQL à la configuration du pod sous
containers
:Si vous utilisez une clé de compte de service, spécifiez le volume de votre secret et ajoutez l'option
--credentials-file
à la commande :
- Si vous utilisez l'authentification de la base de données IAM, démarrez le proxy d'authentification Cloud SQL avec l'option
--auto-iam-authn
.
- Enfin, configurez votre application pour qu'elle se connecte à l'aide de
127.0.0.1
sur la valeur DB_PORT spécifiée dans la section de commande.
Exemple de fichier de configuration complet :
Workload Identity
Clé de compte de service
Se connecter à Cloud SQL sans le proxy d'authentification Cloud SQL
Bien que cela soit moins sécurisé, il est possible de se connecter à partir d'un cluster GKE de VPC natif à une instance Cloud SQL sur le même VPC à l'aide d'une adresse IP privée sans le proxy d'authentification Cloud SQL.
Créez un secret avec l'adresse IP privée de votre instance :
kubectl create secret generic <YOUR-PRIVATE-IP-SECRET> \ --from-literal=db_host=<YOUR-PRIVATE-IP-ADDRESS>
Assurez-vous ensuite d'ajouter le secret au conteneur de votre application :
Enfin, configurez votre application pour qu'elle se connecte en utilisant l'adresse IP de la variable d'environnement
DB_HOST
. Dans le cas de MySQL, il faut utiliser le port 3306.
Exemple de fichier de configuration complet :
Adresse IP privée
Dépannage
Besoin d'aide ? Pour obtenir de l'aide sur le dépannage du proxy, consultez la section Dépannage des connexions via le proxy d'authentification Cloud SQL ou la page Assistance Cloud SQL.
Étapes suivantes
Apprenez-en plus sur les adresses IP privées.
Apprenez-en plus sur le proxy d'authentification Cloud SQL et sur l'image Docker du proxy.
Obtenez de l'aide pour Dépannage des connexions via le proxy d'authentification Cloud SQL.
Apprenez-en plus sur Google Kubernetes Engine.
En savoir plus sur les Options de support