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 des environnements d'adresse IP privée afin que les composants Airflow qui exécutent le cluster de votre environnement ne se voient pas attribuer d'adresses IP publiques et ne communiquent que via le réseau interne de Google.
Configurez la connectivité aux API et services Google via le domaine private.googleapis.com afin que votre environnement accède aux API et services Google via des adresses IP routables uniquement depuis Google Cloud.
Examinez les règles de pare-feu générales de votre projet et du réseau VPC où se trouve votre environnement. 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.
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 et au cluster 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/26 (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/26 (UTC)."],[[["\u003cp\u003eSecuring a Cloud Composer environment involves implementing best practices for network security, Identity and Access Management (IAM), encryption, and environment configuration management.\u003c/p\u003e\n"],["\u003cp\u003eManaging environment configurations and DAGs using version control and CI/CD pipelines is crucial for ensuring code review and preventing unauthorized changes to the environment.\u003c/p\u003e\n"],["\u003cp\u003eUtilizing Private IP environments, implementing strict firewall rules, and configuring connectivity to Google APIs through the \u003ccode\u003eprivate.googleapis.com\u003c/code\u003e domain are vital for network security.\u003c/p\u003e\n"],["\u003cp\u003eIsolating permissions through dedicated service accounts and adhering to the principle of least privilege are key aspects of effective Identity and Access Management.\u003c/p\u003e\n"],["\u003cp\u003eSensitive data should be managed securely using Secret Manager, avoiding storage in DAGs or environment variables, and limiting access to environment buckets and snapshots to trusted users.\u003c/p\u003e\n"]]],[],null,["# Security best practices\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\n[Cloud Composer 3](/composer/docs/composer-3/security-practices \"View this page for Cloud Composer 3\") \\| [Cloud Composer 2](/composer/docs/composer-3/security-practices \"View this page for Cloud Composer 2\") \\| **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-1/composer-security-overview).\n\nManage environment configuration and DAGs using version control\n---------------------------------------------------------------\n\n[](/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-1/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-1/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\n\u003cbr /\u003e\n\n- Use [Private IP environments](/composer/docs/composer-1/configure-private-ip) so that Airflow components in\n that run your environment's cluster are not assigned public IP addresses\n and communicate only over Google's internal network.\n\n- [Implement strict firewall rules](/composer/docs/composer-1/configure-private-ip#private-ip-firewall-rules) to control\n traffic to and from your environment's cluster.\n\n- [Configure connectivity to Google APIs and services](/composer/docs/composer-1/configure-private-ip#connectivity-domains)\n through the `private.googleapis.com` domain so that your environment\n accesses Google APIs and services through IP addresses only routable from\n within Google Cloud.\n\n- Review the general firewall rules in your project and in the VPC network\n where your environment is located. Depending on the way you configure them,\n Airflow components of your environment, such as Airflow workers that run\n your DAGs, might access the internet.\n\nIdentity and Access Management\n------------------------------\n\n- Isolate permissions.\n [Create environment service accounts](/composer/docs/composer-1/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-1/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-1/access-control#user-account), so that only\n administrators can access the environment's bucket\n\n and the environment's cluster\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-1/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-1/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-1/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-1/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\n- [Security overview](/composer/docs/composer-1/composer-security-overview)\n- [Access control with IAM](/composer/docs/composer-1/access-control)\n- [Airflow UI Access Control](/composer/docs/composer-1/airflow-rbac)\n- [Airflow summit presentation about DAG security](https://www.youtube.com/watch?v=QhnItssm4yU)"]]
