Le 15 septembre 2026, tous les environnements Cloud Composer 1 et Cloud Composer 2 version 2.0.x atteindront leur fin de vie prévue et vous ne pourrez plus les utiliser. Nous vous recommandons de planifier la migration vers Cloud Composer 3.
Il est essentiel de sécuriser votre environnement Cloud Composer pour protéger les données sensibles et empêcher tout accès non autorisé. Cette page présente les bonnes pratiques clés, y compris des recommandations pour la sécurité du réseau, Identity and Access Management, le chiffrement et la gestion de la configuration de l'environnement.
Pour en savoir plus sur les fonctionnalités de sécurité disponibles dans Cloud Composer, consultez la section Présentation de la sécurité.
Gérer la configuration de l'environnement et les DAG à l'aide du contrôle des versions
Figure 1. Exemple de pipeline CI/CD Airflow (cliquez pour agrandir)
Créez votre environnement à l'aide de Terraform.
Vous pouvez ainsi stocker la configuration de l'environnement sous forme de code dans un dépôt. De cette manière, les modifications apportées à la configuration de votre environnement peuvent être examinées avant d'être appliquées. Vous pouvez également réduire le nombre d'utilisateurs autorisés à modifier la configuration en leur attribuant des rôles avec moins d'autorisations.
Dans Identity and Access Management, désactivez l'accès direct aux DAG et à la configuration de l'environnement pour les utilisateurs ordinaires, comme indiqué dans la section Identity and Access Management (Gestion de l'identité et des accès).
Déployez des DAG dans votre environnement avec un pipeline CI/CD afin que le code DAG soit récupéré à partir d'un dépôt. De cette manière, les DAG sont examinés et approuvés avant que les modifications ne soient fusionnées dans le système de contrôle des versions. Au cours du processus d'examen, les approbateurs s'assurent que les DAG répondent aux critères de sécurité établis au sein de leurs équipes. L'étape d'examen est essentielle pour éviter le déploiement de DAG susceptibles d'effectuer des actions indésirables.
Voici quelques aspects de sécurité importants à prendre en compte lors de l'examen des DAG:
Les DAG qui modifient le contenu du bucket de l'environnement ne doivent pas modifier le code d'autres DAG ni accéder à des données sensibles, sauf si cela est prévu.
Les DAG ne doivent pas envoyer de requêtes directes à la base de données Airflow, sauf si cela est prévu. Un DAG dans un environnement Cloud Composer a accès à toutes les tables de la base de données Airflow. Il est possible de récupérer des informations à partir de n'importe quelle table, de les traiter, puis de les stocker en dehors de la base de données Airflow.
Sécurité du réseau
Utilisez le type de réseau IP privé pour vos environnements afin que les composants Airflow de l'environnement n'aient pas accès à Internet et que leur accès privé à Google soit configuré via la plage private.googleapis.com, qui permet d'accéder aux API, services et domaines Google compatibles avec cette plage.
Examinez les règles de pare-feu dans le réseau VPC connecté à votre environnement (le cas échéant). Selon la façon dont vous les configurez, les composants Airflow de votre environnement, tels que les nœuds de calcul Airflow qui exécutent vos DAG, peuvent accéder à Internet via votre réseau VPC.
Identity and Access Management
Isolez les autorisations.
Créez des comptes de service d'environnement et utilisez des comptes de service différents pour différents environnements. N'attribuez à ces comptes de service que les autorisations strictement nécessaires pour exploiter ces environnements et effectuer les opérations définies dans les DAG Airflow qu'ils exécutent.
Évitez d'utiliser des comptes de service dotés d'autorisations étendues. Bien qu'il soit possible de créer un environnement qui utilise un compte disposant d'autorisations étendues, telles que celles accordées par le rôle de base Éditeur, cela crée un risque de DAG utilisant des autorisations plus étendues que prévu.
Ne vous appuyez pas sur les comptes de service par défaut des services Google utilisés par Cloud Composer. Il est souvent impossible de réduire les autorisations disponibles pour ces comptes de service sans affecter également les autres services Google de votre projet.
Respectez le principe du moindre privilège. N'accordez aux utilisateurs que les autorisations minimales nécessaires. Par exemple, attribuez des rôles IAM afin que seuls les administrateurs puissent accéder au bucket de l'environnement, et que l'accès direct soit désactivé pour les utilisateurs standards. Par exemple, le rôle Utilisateur Composer n'autorise l'accès qu'à l'interface utilisateur du DAG et à l'interface utilisateur d'Airflow.
Appliquez le contrôle des accès de l'interface utilisateur d'Airflow, qui permet de réduire la visibilité dans l'interface utilisateur d'Airflow et dans l'interface utilisateur du DAG en fonction du rôle Airflow de l'utilisateur. Vous pouvez également l'utiliser pour attribuer des autorisations au niveau du DAG pour des DAG individuels.
Révisez-les régulièrement. Effectuez régulièrement un audit des autorisations et des rôles IAM pour identifier et supprimer les privilèges excessifs ou inutilisés.
Veillez à ne pas transmettre ni stocker de données sensibles:
Faites preuve de prudence lorsque vous transmettez des données sensibles telles que des informations permettant d'identifier personnellement l'utilisateur ou des mots de passe. Le cas échéant, utilisez Secret Manager pour stocker en toute sécurité des connexions et des secrets Airflow, des clés API, des mots de passe et des certificats. Ne stockez pas ces informations dans vos DAG ni dans vos variables d'environnement.
Accordez des autorisations IAM au bucket de l'environnement uniquement aux utilisateurs de confiance. Si possible, utilisez des autorisations par objet.
Les considérations de sécurité pour les comptes de service de l'environnement décrivent plusieurs façons dont les utilisateurs ayant accès au bucket de l'environnement peuvent effectuer des actions au nom du compte de service de l'environnement.
Assurez-vous de connaître les données stockées dans les instantanés et n'accordez les autorisations de créer des instantanés de l'environnement et d'accéder au bucket où ils sont stockés qu'aux utilisateurs de confiance.
Toutes les interfaces externes de Cloud Composer utilisent le chiffrement par défaut. Lorsque vous vous connectez à des produits et services externes, assurez-vous d'utiliser une communication chiffrée (SSL/TLS).
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/29 (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/29 (UTC)."],[[["\u003cp\u003eSecuring Cloud Composer environments involves implementing best practices for network security, Identity and Access Management (IAM), encryption, and environment configuration management to safeguard sensitive data and prevent unauthorized access.\u003c/p\u003e\n"],["\u003cp\u003eUtilize version control with tools like Terraform for environment configuration and CI/CD pipelines for DAG deployment to ensure reviewed and approved changes, reducing the number of users with direct modification permissions.\u003c/p\u003e\n"],["\u003cp\u003eEmploy Private IP networking, disable internet access for PyPI package installation, and configure firewall rules in connected VPC networks to enhance network security and limit external access to Airflow components.\u003c/p\u003e\n"],["\u003cp\u003eIsolate permissions by creating dedicated service accounts for different environments, adhering to the principle of least privilege, and regularly auditing IAM roles to minimize the risk of unauthorized access or unintended permissions.\u003c/p\u003e\n"],["\u003cp\u003eAvoid storing sensitive data in DAGs or environment variables, instead use Secret Manager to securely store Airflow connections, API keys, and other sensitive credentials, and restrict access to the environment's bucket and snapshots to trusted users.\u003c/p\u003e\n"]]],[],null,["\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\n**Cloud Composer 3** \\| [Cloud Composer 2](/composer/docs/composer-3/security-practices \"View this page for Cloud Composer 2\") \\| [Cloud Composer 1](/composer/docs/composer-1/security-practices \"View this page for Cloud Composer 1\")\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nSecuring your Cloud Composer environment is crucial for protecting\nsensitive data and preventing unauthorized access. This page outlines key best\npractices, including recommendations for network security, Identity and Access Management,\nencryption, and environment configuration management.\n\nTo get more information about security features available in\nCloud Composer, see [Security overview](/composer/docs/composer-3/composer-security-overview).\n\nManage environment configuration and DAGs using version control [](/static/composer/docs/images/composer-airflow-secure-cicd.svg) **Figure 1.** An example of an Airflow CI/CD pipeline (click to enlarge)\n\n- [Create your environment using Terraform](/composer/docs/composer-3/terraform-create-environments).\n In this way, you can store environment's configuration as code in a\n repository. In this way, changes to your environment configuration can be\n reviewed before they are applied, and you can reduce the number of users\n who have permissions to change the configuration by assigning roles with\n less permissions.\n\n- In Identity and Access Management, disable direct access to DAGs and environment's\n configuration to regular users, as detailed in the\n [Identity and Access Management](#iam-security) section.\n\n- [Deploy DAGs in your environment with a CI/CD pipeline](/composer/docs/composer-3/dag-cicd-github),\n so that DAG code is retrieved from a repository. In this way, DAGs are\n reviewed and approved before the changes are merged to the version control\n system. During the review process, approvers make sure that DAGs meet the\n security criteria established within their teams. The review step is\n critical to prevent deployment of DAGs that might perform unwanted actions.\n\n Some important security aspects to take into account when reviewing DAGs\n are:\n - DAGs that modify the content of the environment's bucket must not modify\n the code of other DAGs or access sensitive data, unless intended.\n\n - DAGs must not make direct queries to the Airflow database, unless\n intended. A DAG in a Cloud Composer environment has\n access to all tables in the Airflow database. It is possible to retrieve\n information from any table, process it, and then store it outside of the\n Airflow database.\n\nNetwork security\n\n- Use [Private IP networking type](/composer/docs/composer-3/change-networking-type) for your environments so that\n Airflow components of the environment don't have access to the internet and\n their Private Google Access is configured through the\n `private.googleapis.com` range, which enables access to Google APIs,\n services, and domains supported by this range.\n\n- [Disable access to the internet when installing PyPI packages](/composer/docs/composer-3/packages-internet-access).\n Instead, use an Artifact Registry repository\n [as the only source of packages](/composer/docs/composer-3/install-python-dependencies#install-ar-repo).\n\n- Review the firewall rules\n [in the VPC network connected to yor environment](/composer/docs/composer-3/connect-vpc-network) (if\n connected). Depending on the way you configure them, Airflow components of\n your environment, such as Airflow workers that run your DAGs, might access\n the internet through your VPC network.\n\n\nIdentity and Access Management\n\n- Isolate permissions.\n [Create environment service accounts](/composer/docs/composer-3/access-control#service-account)\n and use different service accounts for different environments. Assign to\n these service accounts only permissions that are strictly necessary to\n operate these environments and perform operations defined in Airflow DAGs\n that they run.\n\n- Avoid using service accounts with broad permissions. While it\n is possible to create an environment that uses an account with broad\n permissions, such as those granted by the **Editor** basic role, this\n creates a risk of DAGs using broader permissions than intended.\n\n- Don't rely on default service accounts of Google services used by\n Cloud Composer. It is often impossible to reduce permissions\n available to these service accounts without also affecting other Google\n services in your project.\n\n- Make sure that you are familiar with\n [security considerations for environment's service accounts](/composer/docs/composer-3/access-control#service-account-security)\n and understand how this account interacts with permissions and roles that\n you grant to individual users in your project.\n\n- Adhere to the principle of least privilege. Grant only the minimum necessary\n permissions to users. For example,\n [assign IAM roles](/composer/docs/composer-3/access-control#user-account), so that only\n administrators can access the environment's bucket\n ,\n and direct access is disabled for regular users. For example, the\n **Composer User** role enables access only to DAG UI and Airflow UI.\n\n- Enforce [Airflow UI Access Control](/composer/docs/composer-3/airflow-rbac), which allows to reduce\n visibility in Airflow UI and DAG UI based on user's Airflow role, and can be\n used to assign DAG-level permissions for individual DAGs.\n\n- Review regularly. Regularly audit IAM permissions and roles\n to identify and remove any excessive or unused privileges.\n\n- Beware of passing and storing sensitive data:\n\n - Exercise caution when passing storing sensitive data like personally\n identifiable information or passwords. Where required,\n [use Secret Manager](/composer/docs/composer-3/configure-secret-manager) to\n securely store Airflow connections and Airflow secrets, API keys,\n passwords, and certificates. Don't store this information in your DAGs\n or environment variables.\n\n - Grant IAM permissions to the environment's bucket only\n to trusted users. Use per-object permissions, if possible.\n [Security considerations for environment's service accounts](/composer/docs/composer-3/access-control#service-account-security)\n list several ways in which users with access to the environment's\n bucket can perform actions on behalf of the environment's service\n account.\n\n - Make sure that you are familiar with\n [what data is stored in the snapshots](/composer/docs/composer-3/save-load-snapshots) and provide\n permissions to create environment snapshots and access the bucket where\n they are stored only to trusted users.\n\n - All Cloud Composer's external interfaces use encryption by\n default. When connecting to external products and services, make sure\n that you use encrypted communication (SSL/TLS).\n\nWhat's next\n\n- [Security overview](/composer/docs/composer-3/composer-security-overview)\n- [Access control with IAM](/composer/docs/composer-3/access-control)\n- [Airflow UI Access Control](/composer/docs/composer-3/airflow-rbac)\n- [Airflow summit presentation about DAG security](https://www.youtube.com/watch?v=QhnItssm4yU)"]]
