Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1
Cette page décrit les options de contrôle des accès disponibles dans Cloud Composer et explique comment accorder des rôles.
Pour plus d'informations sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.
Avec le contrôle des accès à l'interface utilisateur d'Airflow, vous pouvez contrôler les autorisations de l'interface utilisateur d'Airflow et de l'interface utilisateur du DAG au-delà de l'activation ou de la désactivation de l'accès à celle-ci.
Si vous souhaitez configurer l'accès des identités externes via la fédération d'identité des employés, consultez la section Accéder aux environnements avec la fédération d'identité des employés.
À propos d'Identity and Access Management dans Cloud Composer
L'API Cloud Composer utilise Identity and Access Management (IAM) pour effectuer le contrôle des accès.
Vous contrôlez l'accès à différentes fonctionnalités de Cloud Composer en accordant des rôles et des autorisations à la fois pour les comptes de service IAM et pour les comptes utilisateur de votre Google Cloud projet.
Cloud Composer utilise deux types de comptes de service IAM:
En plus de ces deux types de comptes de service, l'agent de service des API Google exécute des processus Google internes en votre nom.
Attribuer des rôles au compte d'agent de service Cloud Composer
Dans votre Google Cloud projet, le service Cloud Composer crée un agent de service, l'agent de service Cloud Composer, pour gérer les ressources liées à Cloud Composer.
L'agent de service Cloud Composer est utilisé pour tous les environnements de votre projet. Par défaut, le compte d'agent de service Cloud Composer ne dispose que du rôle Agent de service de l'API Cloud Composer. Conservez ce rôle sur ce compte de service.
Cloud Composer 2 utilise GKE Autopilot, qui nécessite Workload Identity. Pour assurer la compatibilité de Workload Identity, le compte de service de votre environnement doit comporter des liaisons au compte de service Kubernetes qui exécute le cluster de votre environnement. Ces liaisons sont nécessaires pour que les pods de votre cluster d'environnement puissent accéder aux ressources de votre Google Cloud projet. par exemple, pour lire les fichiers de définition du DAG à partir du bucket de l'environnement.
Pour créer des liaisons entre le compte de service de votre environnement et le compte de service Kubernetes du cluster de votre environnement, le compte de l'agent de service Composer doit disposer d'autorisations suffisantes. Pour ce faire, vous devez disposer des autorisations iam.serviceAccounts.getIamPolicy
et iam.serviceAccounts.setIamPolicy
, qui sont fournies par le rôle Extension de l'agent de service de l'API Cloud Composer v2 (roles/composer.ServiceAgentV2Ext
).
Ce rôle n'est pas accordé automatiquement. Vous devez l'accorder manuellement. Pour savoir comment attribuer ce rôle, consultez la section Accorder les autorisations requises au compte de service Cloud Composer.
Attribuer des rôles au compte de service d'un environnement
Lorsque vous créez un environnement, vous spécifiez un compte de service. Ce compte de service est appelé compte de service de l'environnement. Une fois un environnement créé, vous ne pouvez plus modifier le compte de service spécifié.
Votre environnement utilise ce compte de service pour effectuer la plupart des opérations, par exemple:
Exécuter des pods avec différents composants d'environnement, tels que des nœuds de calcul et des programmeurs Airflow, dans le cluster de votre environnement.
Exécuter des DAG au nom de ce compte de service Par exemple, si un DAG accède à un autre service Google, il le fait au nom du compte de service.
Compilation des images des composants Airflow lorsque des packages PyPI personnalisés sont installés dans l'environnement.
Lire et écrire des objets dans le bucket de l'environnement Par exemple, lors de la synchronisation de fichiers entre le bucket de l'environnement et les composants Airflow.
Pods en cours d'exécution lancés via KubernetesPodOperator et GKEStartPodOperator.
Cloud Composer associe ce compte de service au compte de service Kubernetes de votre environnement. Les nœuds du cluster de votre environnement s'exécutent en tant que compte de service Kubernetes et utilisent les liaisons pour accéder aux ressources de votre projetGoogle Cloud , telles que les fichiers DAG dans le bucket de votre environnement. Par conséquent, si vous souhaitez que votre environnement accède à d'autres ressources de votre projetGoogle Cloud , accordez des autorisations au compte de service de votre environnement (compte de service IAM), et non au compte de service Kubernetes.
Comptes de service existants et personnalisés pour votre environnement
Nous vous recommandons vivement de configurer un compte de service géré par l'utilisateur et de l'utiliser pour les environnements Cloud Composer. Pour ce faire :
Créez un compte de service comme décrit dans la documentation Identity and Access Management.
Attribuez-lui le rôle Nœud de calcul Composer (
composer.worker
).Si votre environnement utilise des restrictions de localisation des ressources ou installe des paquets PyPI à partir d'un dépôt Artifact Registry ou d'un dépôt privé, attribuez le rôle Utilisateur du compte de service (
iam.serviceAccountUser
) au compte de service géré par l'utilisateur qui exécute votre environnement sur lui-même (le principal et la ressource sont le même compte de service).Pour accéder à d'autres ressources de votre projet Google Cloud , accordez à ce compte de service des autorisations supplémentaires pour y accéder. Dans la plupart des cas, le rôle Nœud de calcul Composer (
composer.worker
) fournit cet ensemble d'autorisations requis. N'ajoutez des autorisations supplémentaires à ce compte de service que lorsque cela est nécessaire au fonctionnement de vos DAG.
Bien que nous vous déconseillons d'utiliser cette approche, si vous ne spécifiez pas le compte de service d'un environnement dans la Google Cloud CLI, Terraform ou l'API, votre environnement Cloud Composer utilise le compte de service Compute Engine par défaut:
- Ce compte de service dispose généralement du rôle de base Éditeur, qui contient beaucoup plus d'autorisations que nécessaire pour exécuter Cloud Composer.
- Si votre environnement utilise ce compte de service, ne modifiez pas les rôles qui lui sont attribués. Cela pourrait entraîner des problèmes avec d'autres servicesGoogle Cloud .
Nous vous recommandons d'éviter d'utiliser le compte de service Compute Engine par défaut en raison de ses autorisations étendues et de l'impossibilité de les réduire sans affecter d'autres services Google Cloud .
Éléments à prendre en compte concernant la sécurité des comptes de service de l'environnement
Nous vous recommandons vivement de configurer un compte de service géré par l'utilisateur pour les environnements Cloud Composer qui ne comporte que l'ensemble d'autorisations requis pour exécuter l'environnement et effectuer les opérations définies dans vos DAG. Dans la plupart des cas, le rôle Nœud de calcul Composer (
composer.worker
) fournit cet ensemble d'autorisations requis. N'ajoutez des autorisations supplémentaires à ce compte de service que lorsque cela est nécessaire au fonctionnement de vos DAG.Vous pouvez créer des environnements Cloud Composer qui utilisent le compte de service Compute Engine par défaut. Ce compte dispose généralement de plus d'autorisations que nécessaire pour exécuter des environnements ou des DAG Cloud Composer. Étant donné que votre environnement exécute des DAG au nom de son compte de service, il existe un risque que les DAG utilisent des autorisations plus étendues que prévu. En même temps, il est souvent impossible de réduire les autorisations de ce compte de service sans affecter les autres services susceptibles de l'utiliser dans votre projet. À la place, configurez un compte de service géré par l'utilisateur.
Veillez à n'accorder l'accès en lecture-écriture au bucket de votre environnement qu'aux utilisateurs de confiance.
Étant donné que le compte de service de l'environnement est utilisé pour exécuter des DAG, les utilisateurs autorisés à ajouter et à modifier des DAG (ou d'autres objets tels que des dépendances Python) dans le bucket de l'environnement peuvent exécuter leur code au nom du compte de service de l'environnement et accéder à toutes ses autorisations en déployant leurs propres versions de DAG. Cela peut se produire même si leurs comptes utilisateur ne disposent pas de rôles et d'autorisations explicites liés à Cloud Composer qui autorisent de telles actions.
Veillez à n'accorder l'accès aux dépôts Artifact Registry de votre projet qu'aux utilisateurs de confiance.
Les composants Airflow de votre environnement utilisent des images de conteneur stockées dans ces dépôts. Il est possible d'utiliser une image de conteneur personnalisée avec KubernetesPodOperator, GKEPodOperator ou GKEStartPodOperator à partir d'un DAG. Ces utilisateurs peuvent déployer leurs propres versions d'images de conteneur pour les composants Airflow de votre environnement (tels que les workers Airflow) ou exécuter un DAG qui utilise l'un des opérateurs listés pour exécuter une image de conteneur importée. Par conséquent, ces utilisateurs peuvent exécuter leur code au nom du compte de service de l'environnement et accéder à toutes ses autorisations.
Assurez-vous de n'autoriser que les utilisateurs de confiance à mettre à jour les environnements de votre projet.
L'autorisation
composer.environments.update
peut être utilisée au-delà de l'application des modifications de configuration. Il offre un contrôle étendu sur les ressources Cloud Composer, y compris l'exécution de code au nom du compte de service de l'environnement, qui peut exercer toutes les autorisations dont dispose ce compte de service. Par exemple, l'installation de packages PyPI implique l'exécution du code Python à partir du package. Par exemple, les variables d'environnement peuvent être utilisées pour stocker le code à exécuter par un DAG ou pour pointer vers un emplacement contenant ce code.Assurez-vous de n'autoriser que les utilisateurs de confiance à exécuter des commandes de CLI Airflow dans votre projet.
L'autorisation
composer.environment.executeairflowcommand
peut être utilisée pour exécuter le code Python disponible pour les composants Airflow au nom du compte de service de l'environnement.
Accorder des rôles aux utilisateurs
Pour déclencher une opération d'environnement, un utilisateur doit disposer d'autorisations suffisantes.
Par exemple, si vous souhaitez créer un environnement, vous devez disposer de l'autorisation composer.environments.create
.
Pour Cloud Composer, les autorisations individuelles sont regroupées en rôles prédéfinis. Vous pouvez attribuer ces rôles aux comptes principaux.
Si votre compte utilisateur dispose du rôle Éditeur de projet, vous pouvez exécuter toutes les opérations d'environnement. Toutefois, ce rôle dispose d'autorisations étendues. Pour les utilisateurs travaillant avec des environnements, nous vous recommandons d'utiliser des rôles spécifiques à Cloud Composer. De cette manière, vous pouvez réduire le champ d'application des autorisations et fournir différents niveaux d'accès à différents comptes principaux. Par exemple, un utilisateur peut disposer des autorisations nécessaires pour créer, mettre à jour, mettre à niveau et supprimer des environnements, tandis qu'un autre peut uniquement afficher les environnements et accéder à l'interface Web Airflow.
Selon le niveau d'accès que vous souhaitez fournir pour les environnements Cloud Composer, accordez les autorisations suivantes aux comptes principaux.
Gérer les environnements et les buckets d'environnement
Pour un utilisateur pouvant afficher, créer, mettre à jour, mettre à niveau et supprimer des environnements, gérer des objets (tels que des fichiers DAG) dans les buckets d'environnement, accéder à l'interface Web Airflow, exécuter des commandes CLI Airflow, afficher et déclencher des DAG à partir de l'UI DAG:
Attribuez le rôle Administrateur de l'environnement et des objets de l'espace de stockage (
composer.environmentAndStorageObjectAdmin
).Attribuez le rôle Utilisateur du compte de service (
iam.serviceAccountUser
).Pour affiner les autorisations d'un utilisateur, n'accordez ce rôle qu'au compte de service de votre environnement. Pour en savoir plus, consultez la section Attribuer ou révoquer un rôle unique.
Accordez l'autorisation
iam.serviceAccounts.actAs
au compte de service de votre environnement.
Gérer les environnements
Pour un utilisateur pouvant afficher, créer, mettre à jour, mettre à niveau et supprimer des environnements, accéder à l'interface Web Airflow, exécuter des commandes CLI Airflow, afficher et déclencher des DAG à partir de l'interface utilisateur DAG:
Attribuez le rôle Administrateur Composer (
composer.admin
).Attribuez le rôle Utilisateur du compte de service (
iam.serviceAccountUser
).Pour affiner les autorisations d'un utilisateur, n'accordez ce rôle qu'au compte de service de votre environnement. Pour en savoir plus, consultez la section Attribuer ou révoquer un rôle unique.
Accordez l'autorisation
iam.serviceAccounts.actAs
au compte de service de votre environnement.
Afficher les environnements et gérer les buckets d'environnement
Pour un utilisateur pouvant afficher les environnements, accéder à l'interface Web Airflow, afficher et déclencher des DAG à partir de l'UI DAG, et gérer les objets dans les buckets d'environnement (par exemple, pour importer de nouveaux fichiers DAG):
Attribuez le rôle Utilisateur de l'environnement et lecteur des objets de l'espace de stockage (
composer.environmentAndStorageObjectViewer
).Attribuez le rôle Administrateur des objets de l'espace de stockage (
storage.objectAdmin
).
Afficher les environnements et les buckets d'environnement
Pour un utilisateur pouvant afficher les environnements, accéder à l'interface Web Airflow, afficher et déclencher des DAG à partir de l'interface utilisateur DAG, et afficher des objets dans des buckets d'environnement, accordez le rôle Utilisateur de l'environnement et lecteur des objets de l'espace de stockage (composer.environmentAndStorageObjectViewer
).
Afficher les environnements
Pour un utilisateur pouvant afficher les environnements, afficher et déclencher des DAG à partir de l'interface utilisateur DAG et accéder à l'interface Web Airflow, attribuez le rôle Utilisateur Composer (composer.user
).
Rôles
Role | Permissions |
---|---|
Cloud Composer v2 API Service Agent Extension( Cloud Composer v2 API Service Agent Extension is a supplementary role required to manage Composer v2 environments. |
|
Composer Administrator( Provides full control of Cloud Composer resources. Lowest-level resources where you can grant this role:
|
|
Environment and Storage Object Administrator( Provides full control of Cloud Composer resources and of the objects in all project buckets. Lowest-level resources where you can grant this role:
|
|
Environment and Storage Object User( Read and use access to Cloud Composer resources and read access to Cloud Storage objects. |
|
Environment and Storage Object Viewer( Provides the permissions necessary to list and get Cloud Composer environments and operations. Provides read-only access to objects in all project buckets. Lowest-level resources where you can grant this role:
|
|
Composer Shared VPC Agent( Role that should be assigned to Composer Agent service account in Shared VPC host project |
|
Composer User( Provides the permissions necessary to list and get Cloud Composer environments and operations. Lowest-level resources where you can grant this role:
|
|
Composer Worker( Provides the permissions necessary to run a Cloud Composer environment VM. Intended for service accounts. Lowest-level resources where you can grant this role:
|
|
Rôles pour les agents de service
Rôle | Autorisations |
---|---|
Agent de service de l'API Cloud Composer( L'agent de service de l'API Cloud Composer peut gérer les environnements. |
|
Rôles de base
.Les rôles de base fonctionnent avec Cloud Composer comme suit:
- Propriétaire (
owner
): permet un contrôle complet sur les ressources Cloud Composer. - Éditeur (
editor
): permet de contrôler entièrement les ressources Cloud Composer. - Lecteur (
viewer
): permet à un utilisateur de lister et d'obtenir des ressources Cloud Composer.
Pour en savoir plus sur les rôles de base et les autorisations Cloud Composer incluses, consultez la page Documentation de référence sur les rôles IAM de base et prédéfinis.
Autorisations pour les méthodes API
Le tableau suivant répertorie les autorisations dont l'appelant doit disposer pour appeler chaque méthode d'API dans l'API Cloud Composer ou pour effectuer des tâches à l'aide des outilsGoogle Cloud qui utilisent l'API (par exemple, la console Google Cloud ou la CLI Google Cloud).
Vous pouvez créer vos propres rôles personnalisés qui incluent des autorisations individuelles. Pour en savoir plus, consultez la section Créer un rôle personnalisé.
Méthode | Autorisation |
---|---|
environments.create
|
composer.environments.create et iam.serviceAccounts.actAs sur le compte de service de l'environnement. |
environments.delete |
composer.environments.delete |
environments.get |
composer.environments.get |
environments.list |
composer.environments.list |
environments.update |
composer.environments.update |
environments.executeAirflowCommand |
composer.environment.executeairflowcommand |
environments.stopAirflowCommand |
composer.environment.executeairflowcommand |
environments.pollAirflowCommand |
composer.environment.executeairflowcommand |
operations.delete |
composer.operations.delete |
operations.get |
composer.operations.get |
operations.list |
composer.operations.list |
Autorisations pour utiliser la CLI gcloud avec des environnements
Pour utiliser gcloud
avec des environnements Cloud Composer, vous devez disposer des autorisations suivantes :
composer.environments.get
container.clusters.get
container.clusters.list
container.clusters.getCredentials
Si vous souhaitez gérer des environnements ou des buckets d'environnement à l'aide de commandes gcloud composer
, vous devez également disposer d'un rôle doté des autorisations suffisantes pour le faire.
Si vous souhaitez exécuter des commandes de CLI Airflow, vous avez besoin des autorisations supplémentaires suivantes:
container.namespaces.list
container.pods.get
container.pods.list
(Cloud Composer 2.4.0 et versions ultérieures)
composer.environment.executeAirflowCommand
(versions de Cloud Composer antérieures à 2.4.0)
container.pods.exec
Autorisations pour utiliser des DAG depuis la console Google Cloud
Les autorisations suivantes couvrent l'utilisation des DAG à partir de la console Google Cloud, via l'UI DAG:
Autorisation | Description |
---|---|
composer.dags.list
|
Affichez la liste des DAG sur la page "Détails de l'environnement". |
composer.dags.get
|
Obtenez des informations détaillées sur les DAG, les exécutions de DAG et les tâches sur la page d'informations sur le DAG. |
composer.dags.getSourceCode |
Obtenez le code source des DAG sur la page d'informations les concernant. |
composer.dags.execute |
Suspendez, réactivez et déclenchez des DAG depuis la page d'informations correspondante. |
Vous pouvez utiliser le contrôle d'accès de l'interface utilisateur d'Airflow pour contrôler davantage les autorisations DAG pour les comptes utilisateur. L'interface utilisateur du DAG nécessite à la fois des autorisations IAM et de contrôle des accès de l'interface utilisateur d'Airflow pour autoriser une action spécifique sur un DAG. En même temps, l'interface utilisateur d'Airflow ne valide l'accès des utilisateurs qu'en fonction des autorisations de contrôle des accès de l'interface utilisateur d'Airflow, en ignorant les autorisations IAM.
Par exemple, si un utilisateur dispose de l'autorisation composer.dags.execute
et du rôle Airflow Viewer
, il ne peut pas déclencher de DAG depuis la console Google Cloud. À l'inverse, si un utilisateur ne dispose pas de l'autorisation composer.dags.list
, il peut toujours afficher la liste des DAG dans l'interface utilisateur d'Airflow.
Autorisations et rôles pour la mise en réseau du VPC partagé
La mise en réseau VPC partagée nécessite des rôles et des autorisations supplémentaires pour les comptes de service dans les projets de service et hôte. Pour en savoir plus sur la configuration de ces rôles et autorisations, consultez la section Configurer la mise en réseau VPC partagé.
Utiliser un compte de service d'un autre projet
Si vous souhaitez qu'un environnement Cloud Composer d'un projet utilise un compte de service géré par l'utilisateur d'un autre projet, configurez le compte de service géré par l'utilisateur comme suit:
Assurez-vous que la règle d'administration de l'organisation du projet dans lequel se trouve votre compte de service géré par l'utilisateur autorise l'usurpation d'identité des comptes de service entre les projets.
Activez l'API Composer dans le projet où se trouve votre compte de service géré par l'utilisateur. Pour en savoir plus sur la raison pour laquelle vous devez le faire, consultez la section Où créer des comptes de service.
Attribuez des rôles IAM comme décrit dans le tableau suivant.
Créez votre environnement avec un compte de service multiprojet. Vous pouvez utiliser Google Cloud CLI, l'API ou Terraform. Dans la console Google Cloud, il n'est pas possible de sélectionner un compte de service à partir d'un autre projet.
Le tableau suivant décrit les rôles et les principaux IAM requis pour votre compte de service géré par l'utilisateur.
Projet | Ressource | Compte principal | Rôle |
---|---|---|---|
Projet dans lequel se trouve votre compte de service géré par l'utilisateur | Votre compte de service géré par l'utilisateur |
Compte d'agent de service Cloud Composer du projet dans lequel se trouve votre environnement (service-SERVICE_PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com ).
|
Utilisateur du compte de service (iam.serviceAccountUser ) |
(Cloud Composer 2 uniquement) Projet dans lequel se trouve votre compte de service géré par l'utilisateur | Votre compte de service géré par l'utilisateur |
Compte d'agent de service Cloud Composer du projet dans lequel se trouve votre environnement (service-SERVICE_PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com ).
|
Extension de l'agent de service de l'API Cloud Composer v2 (roles/composer.ServiceAgentV2Ext ). Pour en savoir plus sur l'utilisation de ce rôle, consultez Attribuer des rôles au compte d'agent de service Cloud Composer. |
Projet dans lequel se trouve votre compte de service géré par l'utilisateur | Votre compte de service géré par l'utilisateur |
Agent de service Kubernetes Engine du projet dans lequel se trouve votre environnement (service-SERVICE_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com )
|
Utilisateur du compte de service (iam.serviceAccountUser ) |
Projet dans lequel se trouve votre compte de service géré par l'utilisateur | Votre compte de service géré par l'utilisateur |
Agent de service des API Google du projet dans lequel se trouve votre environnement (SERVICE_PROJECT_NUMBER@cloudservices.gserviceaccount.com )
|
Utilisateur du compte de service (iam.serviceAccountUser ) |
Projet dans lequel se trouve votre compte de service géré par l'utilisateur | Votre compte de service géré par l'utilisateur |
Agent de service Compute Engine du projet dans lequel se trouve votre environnement (service-SERVICE_PROJECT_NUMBER@compute-system.iam.gserviceaccount.com )
|
Créateur de jetons du compte de service (roles/iam.serviceAccountTokenCreator ) |
Projet dans lequel se trouve votre environnement | Projet | Votre compte de service géré par l'utilisateur | Attribuez les rôles requis à votre compte de service géré par l'utilisateur, comme décrit dans la section Attribuer des rôles à un compte de service géré par l'utilisateur. Par exemple, dans une configuration d'adresse IP publique, votre compte de service géré par l'utilisateur nécessite le rôle Nœud de calcul Composer. |
Autoriser l'accès à l'interface utilisateur d'Airflow
Les sections suivantes expliquent comment activer l'accès à l'interface utilisateur d'Airflow dans différents scénarios.
Autoriser l'accès à l'interface utilisateur d'Airflow dans Google Workspace
Si l'option Contrôles des API > Applications tierces non configurées > Ne pas autoriser les utilisateurs à accéder aux applications tierces est activée dans Google Workspace et que l'application Apache Airflow dans Cloud Composer n'est pas explicitement autorisée, les utilisateurs ne peuvent pas accéder à l'interface utilisateur d'Airflow, sauf s'ils autorisent explicitement l'application.
Pour autoriser l'accès à l'application Apache Airflow dans Cloud Composer, procédez comme suit:
Dans la console d'administration, accédez à Menu (> Sécurité > Contrôle des accès et des données > Commandes des API.
)Cliquez sur Gérer l'accès des applications tierces pour afficher les applications configurées.
Cliquez sur Configurer une nouvelle application.
Recherchez l'ID client OAuth de l'application :
431403837536-q0odo3nmtfjocv7q291cnmedr0hnlbkh.apps.googleusercontent.com
Sélectionnez l'appli Apache Airflow dans Cloud Composer.
Sélectionnez le champ d'application des utilisateurs pour lesquels vous souhaitez configurer l'accès, puis cliquez sur Continuer.
Dans Accès aux données Google, sélectionnez Limité, puis cliquez sur Continuer.
Vérifiez les informations, puis cliquez sur Terminer.
Pour en savoir plus sur la configuration de l'accès des applications tierces, consultez Contrôler quelles applications tierces et internes ont accès aux données Google Workspace.
Autoriser l'accès à l'interface utilisateur d'Airflow dans les liaisons d'accès contextuel
Si les liaisons d'accès contextuelles Chrome Enterprise Premium sont utilisées avec des niveaux d'accès qui reposent sur des attributs d'appareil et que l'application Apache Airflow dans Cloud Composer n'est pas exemptée, il n'est pas possible d'accéder à l'interface utilisateur Airflow en raison d'une boucle de connexion.
Pour autoriser l'accès, ajoutez une exception pour Apache Airflow dans l'application Cloud Composer, comme décrit dans les étapes suivantes. L'ajout de l'exception assouplit la restriction d'origine. Toutefois, l'accès des appareils qui ne correspondent pas à la condition de niveau d'accès d'origine devrait toujours être bloqué lors de l'authentification à l'interface utilisateur d'Airflow. Si l'accès précédemment autorisé est mis en cache dans le navigateur Web, il doit expirer avant que l'accès puisse être bloqué.
Pour en savoir plus sur l'application de différents niveaux d'accès dans les liaisons d'accès contextuel, consultez la section Définir des configurations pour des applications spécifiques.
Pour autoriser l'accès à Apache Airflow dans l'application Cloud Composer:
Dans Access Context Manager, créez un niveau d'accès personnalisé équivalent au niveau d'accès actuellement associé dans les paramètres d'accès contextuel, mais avec des conditions supprimées qui reposent sur des attributs d'appareil. Si le niveau d'accès d'origine ne comportait aucune condition en dehors des attributs de l'appareil, créez un niveau d'accès personnalisé avec une expression CEL définie sur
true
.Créez un fichier vide nommé
binding.yaml
sur votre ordinateur local. Dans les étapes suivantes, vous l'utiliserez pour mettre à jour la liaison existante qui repose sur les attributs de l'appareil.Recherchez la liaison d'accès existante qui utilise le niveau d'accès basé sur les attributs de l'appareil.
Vous pouvez lister toutes les liaisons à l'aide de la commande suivante dans la Google Cloud CLI:
gcloud access-context-manager cloud-bindings list \ --organization
ORGANIZATION_ID Remplacez les éléments suivants :
ORGANIZATION_ID
: ID de ressource de l'organisation de l'organisation dans laquelle les liaisons d'accès sont définies pour vos utilisateurs.
Copiez l'intégralité de la section
scopedAccessSettings
de la liaison qui repose sur les attributs de l'appareil dans le fichierbinding.yaml
.Si cette section n'est pas incluse dans la liaison, collez-en une dans ce fichier:
scopedAccessSettings:
Ajoutez l'élément de liste suivant au fichier
binding.yaml
. Il exempte le client OAuth Apache Airflow dans Cloud Composer des vérifications des attributs de l'appareil:- scope: clientScope: restrictedClientApplication: clientId: 431403837536-q0odo3nmtfjocv7q291cnmedr0hnlbkh.apps.googleusercontent.com activeSettings: accessLevels: -
ACCESS_LEVEL_WITHOUT_DEVICE_ATTRIBUTES Remplacez les éléments suivants :
ACCESS_LEVEL_WITHOUT_DEVICE_ATTRIBUTES
: nom complet du niveau d'accès personnalisé que vous avez créé précédemment, au format :accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME
.
Mettez à jour la liaison qui repose sur les attributs de l'appareil à l'aide du fichier
binding.yaml
.gcloud access-context-manager cloud-bindings update \ --binding=
BINDING_ID \ --binding-file='binding.yaml'Remplacez les éléments suivants :
BINDING_ID
: identifiant complet de la liaison d'accès qui utilise le niveau d'accès basé sur les attributs de l'appareil. Utilisez le format suivant :organizations/ORGANIZATION/gcpUserAccessBindings/BINDING_NAME
.
Autoriser l'accès à l'interface utilisateur d'Airflow dans les règles d'entrée VPC Service Controls
Si des règles d'entrée sont configurées dans un périmètre VPC Service Controls qui protège le projet, et que la règle d'entrée qui autorise l'accès au service Cloud Composer utilise le type d'identité ANY_SERVICE_ACCOUNT
ou ANY_USER_ACCOUNT
, les utilisateurs ne peuvent pas accéder à l'interface utilisateur d'Airflow, ce qui entraîne une boucle de connexion.
Il est impossible d'utiliser des règles d'entrée avec ces types d'identité pour le service Cloud Composer et de conserver l'accès à l'interface utilisateur d'Airflow. Pour débloquer l'accès à l'UI Airflow, vous devez modifier la règle d'entrée pour utiliser le type d'identité ANY_IDENTITY
ou une liste d'identités et de groupes spécifiques. Vous pouvez également configurer un niveau d'accès qui autorise un accès supplémentaire au périmètre.
Pour obtenir la liste complète des fonctionnalités non compatibles avec les règles d'entrée, consultez la section Fonctionnalités non compatibles.