amithmathew edited a comment on issue #8803: URL: https://github.com/apache/airflow/issues/8803#issuecomment-649709601
Thanks Kamil. I don't think this statement is accurate in the context I was proposing - "The implementation of this feature in the current Airflow architecture meant that DAG or the operator could access the access key or service account file that allows you to log in to any other account. This is unacceptable." The account used by the airflow worker can impersonate another service account only if granted the appropriate permissions through IAM, so I don't think you can log into *any* account. Secondly, even when using a secrets backend, your DAGs still have permissions to access any secret in there (unless I'm missing something). [This](https://cloud.google.com/iam/docs/understanding-service-accounts#directly_impersonating_a_service_account) is the relevant documentation. Not having to deal with key material allows for - 1: Do not have to deal with key rotations. 2: When airflow operations is centralized in an organization, eliminate any coordination required for key management and transfer for setup - everything is controlled through IAM. 3: Controlling IAM access through terraform becomes easier, no key generation, transfer or load required. I may be missing something, of course! ---------------------------------------------------------------- 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]
