amithmathew commented on issue #8803: URL: https://github.com/apache/airflow/issues/8803#issuecomment-649727163
Thanks for the response Jarek. I should state my assumptions :) #### Assumptions 1. Airflow is running on GCP (so workers use the instance accounts) - no long lived keys generated for the main service account. 2. Airflow is centralized and lives in its own project - DAGs can be run in other projects, and owned by other teams in the organization. #### Current model using connections and a secrets backend. - 1. The DAG owner/user should generate a long lived key 2. Either store it in the secrets backend themselves or transfer it to the team managing airflow to set it up. 3. The Airflow connection needs to be created. ##### Challenges 1. Long lived keys are generated. 2. To rotate the key used by the connection, the DAG user must coordinate with the team managing airflow (if that is how the org is setup). 3. If using terraform for these steps, the key transfer and connection setup end up adding manual steps to the process. #### Proposed model using IAM permissions for impersonation 1. The DAG owner/user determines whether to grant permissions to the Airflow service account. 2. No long lived keys generated or need to be managed. 3. Service Account user permissions (required for impersonation) can be controlled within the DAG Owner/Users project itself and does not require cross-gcp project or cross-team coordination. #### Risks: ##### Assumption: Long lived keys were generated for the main service account used by airflow, and these were compromised. ##### Detail The risk of access to all accounts remains the same in both models. They can access all connections (in the first model) and retrieve key information, or impersonate all other service accounts that have granted permissions to the main account. ###### Current Model (using connections) The resolution is harder in the current model - the compromised main account key will need to be disabled, and there's a risk that the key material for all other accounts were extracted and thus compromised as well. So keys used in all connections will need to be disabled as well. ###### Proposed Model (using IAM and impersonation) In the proposed model, only the main account key will need to be disabled. Hope this makes my request clearer. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
