Under which category would you file this issue?
Providers
Apache Airflow version
We are facing this during a migration from Airflow 2.9 to Airflow 3.x.
What happened and how to reproduce it?
During this migration, we discovered that delegate_to is no longer available in the Google provider. The changelog indicates that delegate_to was removed and users should use impersonation_chain instead.
However, for Google Workspace use cases such as Google Drive, Google Sheets, and Admin SDK / Discovery API, impersonation_chain is not equivalent to the former delegate_to behavior.
According to the Airflow Google connection docs, impersonation_chain is for service-account impersonation. By contrast, Google auth handles Domain-Wide Delegation for a Workspace user account through delegated credentials with a user subject, for example with_subject("user@company.com").
In an enterprise / company context, especially for Google Drive and Google Sheets, acting on behalf of a real Workspace user is a very common requirement.
Typical examples:
access files owned by or shared with a specific user
preserve the normal Workspace permission model
use Admin SDK operations as a delegated admin user
avoid granting overly broad direct access to service accounts
After the removal of delegate_to, there does not seem to be a first-class way to express this common pattern in Airflow hooks/operators:
authenticate with a DWD-enabled service account
delegate to user@company.com
access user-scoped Google Workspace resources
Why this feels like a regression
This is particularly visible during migration from Airflow 2.9 to 3.x, because existing DAGs that relied on user delegation now need custom code or custom hooks.
Also, the current documentation still mentions Domain-Wide Delegation for Google Workspace-oriented usage, while public hook/operator APIs such as the Sheets hook expose impersonation_chain but not an explicit user-subject parameter. That makes the current support story confusing from a user perspective.
What you think should happen instead?
Please consider restoring first-class support for Google Workspace user-subject delegation, ideally with a parameter whose meaning is explicit, for example:
subject
delegated_subject
workspace_subject
I am not necessarily asking to restore the old delegate_to name.
A possible direction would be:
keep impersonation_chain for service-account impersonation
add a distinct parameter for Workspace user-subject delegation
internally apply credentials.with_subject(subject) when supported by the underlying credentials
expose this at least on Workspace-oriented hooks/operators such as:
GoogleDiscoveryApiHook
GoogleDriveHook
GSheetsHook
related operators/sensors/transfers
Documentation request:
At minimum, it would help to document more explicitly that:
impersonation_chain = service-account impersonation
Google Workspace Domain-Wide Delegation = delegated user subject
these are different mechanisms and are not interchangeable
If first-class support is intentionally not coming back, it would still be very helpful to provide an officially documented custom-hook pattern for Workspace DWD.
Operating System
No response
Deployment
Docker-Compose
Apache Airflow Provider(s)
google
Versions of Apache Airflow Providers
No response
Official Helm Chart version
Not Applicable
Kubernetes Version
No response
Helm Chart configuration
No response
Docker Image customizations
No response
Anything else?
There is at least one public discussion that appears to raise the same confusion/regression around the removal of delegate_to, which suggests this is not an isolated migration issue.
Would maintainers be open to a PR adding a dedicated user-subject delegation parameter for Google Workspace-oriented hooks/operators?
Are you willing to submit PR?
Code of Conduct
Under which category would you file this issue?
Providers
Apache Airflow version
We are facing this during a migration from Airflow 2.9 to Airflow 3.x.
What happened and how to reproduce it?
During this migration, we discovered that delegate_to is no longer available in the Google provider. The changelog indicates that delegate_to was removed and users should use impersonation_chain instead.
However, for Google Workspace use cases such as Google Drive, Google Sheets, and Admin SDK / Discovery API, impersonation_chain is not equivalent to the former delegate_to behavior.
According to the Airflow Google connection docs, impersonation_chain is for service-account impersonation. By contrast, Google auth handles Domain-Wide Delegation for a Workspace user account through delegated credentials with a user subject, for example with_subject("user@company.com").
In an enterprise / company context, especially for Google Drive and Google Sheets, acting on behalf of a real Workspace user is a very common requirement.
Typical examples:
access files owned by or shared with a specific user
preserve the normal Workspace permission model
use Admin SDK operations as a delegated admin user
avoid granting overly broad direct access to service accounts
After the removal of delegate_to, there does not seem to be a first-class way to express this common pattern in Airflow hooks/operators:
authenticate with a DWD-enabled service account
delegate to user@company.com
access user-scoped Google Workspace resources
Why this feels like a regression
This is particularly visible during migration from Airflow 2.9 to 3.x, because existing DAGs that relied on user delegation now need custom code or custom hooks.
Also, the current documentation still mentions Domain-Wide Delegation for Google Workspace-oriented usage, while public hook/operator APIs such as the Sheets hook expose impersonation_chain but not an explicit user-subject parameter. That makes the current support story confusing from a user perspective.
What you think should happen instead?
Please consider restoring first-class support for Google Workspace user-subject delegation, ideally with a parameter whose meaning is explicit, for example:
subject
delegated_subject
workspace_subject
I am not necessarily asking to restore the old delegate_to name.
A possible direction would be:
keep impersonation_chain for service-account impersonation
add a distinct parameter for Workspace user-subject delegation
internally apply credentials.with_subject(subject) when supported by the underlying credentials
expose this at least on Workspace-oriented hooks/operators such as:
GoogleDiscoveryApiHook
GoogleDriveHook
GSheetsHook
related operators/sensors/transfers
Documentation request:
At minimum, it would help to document more explicitly that:
impersonation_chain = service-account impersonation
Google Workspace Domain-Wide Delegation = delegated user subject
these are different mechanisms and are not interchangeable
If first-class support is intentionally not coming back, it would still be very helpful to provide an officially documented custom-hook pattern for Workspace DWD.
Operating System
No response
Deployment
Docker-Compose
Apache Airflow Provider(s)
google
Versions of Apache Airflow Providers
No response
Official Helm Chart version
Not Applicable
Kubernetes Version
No response
Helm Chart configuration
No response
Docker Image customizations
No response
Anything else?
There is at least one public discussion that appears to raise the same confusion/regression around the removal of delegate_to, which suggests this is not an isolated migration issue.
Would maintainers be open to a PR adding a dedicated user-subject delegation parameter for Google Workspace-oriented hooks/operators?
Are you willing to submit PR?
Code of Conduct