The ongoing Airflow KubernetesExecutor discussion doesn’t have the story of binding credentials (e.g., GCP service accounts) to task PODs. Depending on how the kubernetes cluster is provisioned, in the case of GKE, the default compute engine service account is inherited by the PODs created. It becomes a problem when users wish to attach different service accounts to a task POD. This document suggests a set of mechanisms to be incorporated into the Airflow KubernetesExecutor design so that any Airflow task can specify a set of credentials to be pre-configured on each task POD. We limit the scope of this document to GCP service account only, but the overall process can be seamlessly applied to other types of credentials (e.g., AWS access key).
We start by reviewing the current practice of specifying and using service accounts in Airflow. For Airflow GCP specific operators (e.g., BigQueryOperator), the service account is indirectly specified by the connection ID, which is a primary key into the connections table in Airflow metadata database. The connections table stores additional information on how to retrieve the service account details (the way how service account is stored in the connections table today is not very satisfactory, details). For other non-GCP operators (e.g., PythonOperator and BashOperator), handling service accounts is not explicitly supported in the Airflow framework and left to individual workflows/dags. This approach unfortunately mixes credential management code with workflow business logic and is potentially insecure. The Airflow Kubernetes integration work opens up the possibility to manage task credentials inside the framework and free workflows from handling sensitive account information.
This design should meet the following objectives:
Any task including GCP related tasks can independently specify a service account to be attached to the task execution environment. This particular service account is used whenever get_application_default() is invoked.
Preserve existing connection ID semantics. Specifically, workflows that include GCP operators should continue to work under this new design with zero modification.
The mechanism to specify per-task service account should be simple and doesn’t involve handling sensitive information.
We defer the following goals to a future design:
Dynamic service account binding during task execution.
Revoking a service account in the middle of task execution.
ACL support around service accounts (e.g., which group of workflow/dag users can access a particular service account).