You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by GitBox <gi...@apache.org> on 2020/06/25 12:34:29 UTC

[GitHub] [airflow] mik-laj commented on issue #8803: Impersonate service accounts while running GCP Operators without key material (if airflow is running on GCP)

mik-laj commented on issue #8803:
URL: https://github.com/apache/airflow/issues/8803#issuecomment-649512860


   I talked to the Google team about this feature. We had serious security concerns. 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.  We must think about how to provide these feature without introducing such a security risk.  Ideally, the scheduler would not have access to any object from Connection and would only communicate using the API. However, it is unlikely to happen in the near future. 
   
   Another solution is to create a separate component that will generate the access code based on the allowed list.  Such a thing can be based on Hashicorp Vault (https://www.vaultproject.io/docs/secrets/gcp#access-tokens) or other.
   
   Another solution is to create worker for each service account and use workflow identity to provide access to access token.
   
   Probably, each of them would require a lot of work. 
   
   The easiest will be to generate keys and add them to secret backends.


----------------------------------------------------------------
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:
users@infra.apache.org