Rôles et autorisations

Cette page fournit des informations sur les rôles et les autorisations IAM (Identity and Access Management), ainsi que sur leur utilisation avec les instances Cloud SQL.

Introduction

Cette page se concentre sur les aspects d'IAM qui concernent spécifiquement Cloud SQL. Pour en savoir plus sur IAM et ses fonctionnalités générales, consultez la page Gestion de l'authentification et des accès, en particulier la section sur la gestion des stratégies IAM. IAM vous permet de contrôler qui a accès aux ressources de votre projet Google Cloud. L'ensemble des règles d'accès que vous appliquez à une ressource est appelé stratégie IAM. Une stratégie IAM appliquée à votre projet définit les actions que les utilisateurs peuvent effectuer sur toutes les ressources de votre projet.

Les membres sont les "acteurs" d'IAM. Il peut s'agir d'utilisateurs individuels, de groupes, de domaines ou même du public dans son ensemble. Les membres se voient attribuer des rôles qui leur accordent l'autorisation d'exécuter des actions dans Cloud SQL ainsi que dans Google Cloud plus généralement. Chaque rôle est un ensemble constitué d'une ou plusieurs autorisations. Les autorisations sont les unités de base d'IAM : chaque autorisation vous permet d'effectuer une action donnée. Consultez la page Rôles IAM dans Cloud SQL et Autorisations IAM dans Cloud SQL pour obtenir la liste complète des rôles et autorisations disponibles dans Cloud SQL.

Lorsque vous vous connectez à une instance Cloud SQL à l'aide d'un compte, celui-ci doit disposer du rôle Cloud SQL > Client (roles/cloudsql.client), qui inclut les autorisations requises pour la connexion.

Vous pouvez ajouter des rôles à un compte sur la page IAM et admin > IAM de la console, et identifier les correspondances entre les autorisations et les rôles sur la page IAM et admin > Rôles.

Cloud SQL utilise des comptes de service pour l'authentification entre Cloud SQL et les autres produits Google Cloud. Les comptes de service fournissent des identifiants credentials au format JSON, que vous pouvez télécharger depuis la console et utiliser pour l'authentification dans divers scénarios,

Par exemple : la connexion à partir d'une application s'exécutant dans un conteneur Docker.

Rôles et autorisations Cloud SQL avec un proxy d'authentification Cloud SQL

Si vous vous connectez à une instance Cloud SQL depuis une instance Compute Engine à l'aide du proxy d'authentification Cloud SQL, vous pouvez utiliser le compte de service Compute Engine par défaut associé à l'instance Compute Engine.

Comme pour tous les comptes se connectant à une instance Cloud SQL, le compte de service doit disposer du rôle Cloud SQL > Client.

Rôles et autorisations Cloud SQL avec des solutions sans serveur

App Engine, les fonctions Cloud Run et Cloud Run sont les solutions sans serveur de Google Cloud.

Utilisez un compte de service pour autoriser l'accès depuis ces solutions. Celui-ci vous permet d'autoriser l'accès à tous les services Cloud SQL d'un projet spécifique. Les applications ou environnements de Cloud Run Functions que vous créez se chargent de créer ce compte de service, auquel vous pouvez accéder sur la page IAM et admin > IAM, avec le suffixe approprié :

Solution sans serveur	Suffixe du compte de service
App Engine	@gae-api-prod.google.com.iam.gserviceaccount.com
Cloud Run Functions	@appspot.gserviceaccount.com
Cloud Run	compute@developer.gserviceaccount.com

Comme pour tous les comptes se connectant à une instance Cloud SQL, le compte de service doit disposer du rôle Cloud SQL > Client.

Rôles et autorisations Cloud SQL avec Cloud Storage

Les fonctionnalités d'importation et d'exportation de Cloud SQL fonctionnent conjointement. Les données exportées sont écrites dans Cloud Storage, d'où sont lues les données importées. Pour cette raison, le compte de service que vous utilisez pour effectuer ces opérations requiert des autorisations de lecture et d'écriture dans Cloud Storage :

• Pour importer des données dans et exporter des données depuis Cloud Storage, le compte de service de l'instance Cloud SQL doit disposer du rôle IAM storage.objectAdmin défini dans le projet. Vous trouverez le nom du compte de service de l'instance dans la console Google Cloud sur la page Présentation de votre instance.
• Vous pouvez attribuer ce rôle IAM au compte de service du bucket en exécutant la commande gcloud storage buckets add-iam-policy-binding.
• Pour obtenir de l'aide sur la définition des rôles et des autorisations IAM, consultez la page Utiliser des autorisations IAM.
• Pour en savoir plus, consultez la page IAM pour Cloud Storage.

Rôles et autorisations Cloud SQL avec l'authentification IAM de groupe

Lorsque vous utilisez l'authentification IAM de groupe, vous créez des groupes. Vous pouvez ensuite utiliser les groupes pour gérer les droits d'accès et de base de données à vos instances Cloud SQL.

Le tableau suivant répertorie les rôles requis pour gérer l'authentification IAM de groupe.

Action	Rôles
Créer, afficher et gérer des groupes.	roles/resourcemanager.organizationViewer
Consultez le journal des modifications d'appartenance à un groupe IAM.	roles/logging.viewer
Accordez, affichez et définissez les autorisations IAM au niveau du projet.	roles/resourcemanager.projectIamAdmin
Accordez, affichez et définissez les autorisations IAM au niveau du dossier.	roles/resourcemanager.folderIamAdmin

L'administrateur peut attribuer des rôles Cloud SQL ou attribuer des autorisations Cloud SQL individuelles à chaque groupe. Les membres de chaque groupe héritent des rôles et des autorisations concernés.

Rôles et autorisations Cloud SQL pour l'intégration de Dataplex

Pour autoriser l'accès aux métadonnées Cloud SQL sur Dataplex, vous pouvez accorder à un utilisateur le rôle roles/cloudsql.schemaViewer ou ajouter l'autorisation cloudsql.schemas.view à un rôle personnalisé.

Pour en savoir plus, consultez la page Gérer les ressources Cloud SQL avec le catalogue Dataplex.

Autorisation d'accéder aux instances Cloud SQL privées

Lorsqu'un autre service Google Cloud, tel que BigQuery, doit communiquer avec votre instance Cloud SQL pour accéder aux données et effectuer des requêtes sur ces données via une connexion privée, le service utilise unchemin d'accès interne au lieu des adresses IP privées dans le cloud privé virtuel (VPC). Le trafic ne peut être contrôlé ni restreint à aucune configuration au niveau du VPC, règles de pare-feu, règles de routage ou coupe de l'appairage.

À la place, Cloud SQL fournit une option de configuration sur votre instance qui vous permet d'activer ou de désactiver ce chemin interne pour les autres services Google Cloud accédant à votre base de données.

Contrôler et révoquer l'autorisation

Lorsqu'un autre service Google Cloud, tel que BigQuery, tente d'accéder à votre instance Cloud SQL privée, il doit fournir une identité légitime disposant de l'autorisation IAM cloudsql.instances.connect.

En règle générale, un service peut y parvenir de deux manières:

1. Transférer les identifiants de l'utilisateur Un service peut transférer l'identité IAM de l'utilisateur vers Cloud SQL afin d'évaluer l'autorisation d'accéder à une instance. Dans ce scénario, l'utilisateur doit disposer d'autorisations IAM suffisantes pour que Cloud SQL puisse établir une connexion réussie.

2. Utiliser un compte de service Un service, tel que BigQuery, peut utiliser un compte de service préconfiguré pour se connecter à une instance Cloud SQL. Dans ce cas, le compte de service doit disposer d'autorisations IAM suffisantes.

   Par exemple, pour la connexion fédérée entre BigQuery et Cloud SQL, un compte de service nommé service-{PROJECT_NUMBER}@gcp-sa-bigqueryconnection.iam.gserviceaccount.com est créé lorsque l'API de connexion BigQuery est activée. Ce compte de service dispose de deux autorisations Cloud SQL: cloudsql.instances.connect et cloudsql.instances.get. BigQuery utilise ces autorisations pour accéder à une instance Cloud SQL privée via un chemin d'accès interne.

Pour contrôler l'autorisation d'utilisation de ce chemin interne, vous pouvez accorder et révoquer les autorisations IAM depuis et vers l'identité IAM de l'utilisateur que le service Google Cloud, tel que BigQuery, utilise pour se connecter à votre instance Cloud SQL. Pour en savoir plus sur l'attribution et la révocation d'autorisations dans BigQuery, consultez la page Configurer l'accès à Cloud SQL.

Rôles et autorisations Cloud SQL dans d'autres scénarios

Cloud SQL interagit avec d'autres produits et outils Google Cloud. Ces interactions nécessitent également des rôles et des autorisations spécifiques qui peuvent varier d'un scénario à l'autre. La documentation Cloud SQL fournit des informations détaillées concernant ces exigences pour chacun des cas répertoriés ci-dessous :

• Se connecter à Cloud SQL depuis des applications externes
• Utiliser des clés de chiffrement gérées par le client (CMEK)
• Rôles IAM pour l'administration de VPC Service Controls
• Pour vous connecter à une instance Cloud SQL à partir d'une application exécutée dans Google Kubernetes Engine, vous devez créer un secret pour le fichier de clé JSON du compte de service.

Utiliser IAM avec des projets

Les sections suivantes expliquent comment exécuter des tâches IAM de base sur des projets.

Pour effectuer les tâches suivantes, vous devez disposer des autorisations IAM resourcemanager.projects.getIamPolicy et resourcemanager.projects.setIamPolicy.

Ajouter un membre à une stratégie au niveau du projet

Pour obtenir la liste des rôles associés à Cloud SQL, consultez la page Rôles IAM.

Afficher la stratégie IAM pour un projet

Supprimer un membre d'une stratégie au niveau du projet

Bonnes pratiques

Comme tous les autres paramètres d'administration, IAM requiert une gestion active pour être efficace. Avant de rendre une ressource accessible aux autres utilisateurs, vous devez connaître les rôles que vous souhaitez attribuer à chacune d'entre elles. Au fil du temps, les modifications apportées au processus de gestion de projet, aux modèles d'utilisation et à la propriété organisationnelle peuvent vous contraindre à modifier les paramètres IAM associés aux projets, surtout si vous gérez Cloud SQL dans une grande organisation ou pour un grand groupe d'utilisateurs. Lorsque vous évaluez et planifiez vos paramètres de contrôle des accès, gardez à l'esprit les bonnes pratiques présentées ci-dessous.

• Utilisez le principe du moindre privilège lorsque vous accordez l'accès. Le principe du moindre privilège est une mesure de sécurité appliquée au moment d'accorder l'accès à vos ressources. Lorsque vous accordez un accès basé sur le principe du moindre privilège, vous accordez à un utilisateur uniquement l'accès dont il a besoin pour accomplir la tâche qui lui est attribuée.

• Évitez d'accorder des rôles comportant l'autorisation setIamPolicy à des personnes que vous ne connaissez pas. L'autorisation setIamPolicy permet à un utilisateur de modifier les autorisations et de prendre le contrôle des données. Vous ne devez utiliser les rôles avec l'autorisation setIamPolicy que si vous souhaitez déléguer le contrôle administratif sur les objets et les buckets.

• Veillez à déléguer le contrôle administratif de vos ressources. Vous devez vous assurer que vos ressources peuvent toujours être gérées par d'autres membres de l'équipe lorsqu'une personne dotée d'un accès administrateur quitte le groupe. Voici deux méthodes couramment utilisées :

  • Attribuez le rôle Administrateur Cloud SQL de votre projet à un groupe plutôt qu'à une personne.
  • Attribuez le rôle Administrateur Cloud SQL pour votre projet à au moins deux personnes.

Étape suivante

• En savoir plus sur le contrôle des accès