omar-massfih opened a new issue, #75808: URL: https://github.com/apache/airflow/issues/75808
### Description `SnowflakeHook` supports keyless Workload Identity Federation (`authenticator=WORKLOAD_IDENTITY` + `workload_identity_provider`, see #54983 / #68107). `SnowflakeSqlApiOperator` / `SnowflakeSqlApiHook` do not. With a WIF connection and no private key, `SnowflakeRestTokenProvider.get_token()` (`providers/snowflake/src/airflow/providers/snowflake/utils/_rest_auth.py`) raises: ``` Workload identity federation is not supported for Snowflake REST APIs; use OAuth, PAT, or key-pair authentication instead. ``` Snowflake's REST API documentation lists WIF as a supported authentication method ([Authenticating Snowflake REST APIs with Snowflake](https://docs.snowflake.com/en/developer-guide/snowflake-rest-api/authentication)): ``` Authorization: Bearer WIF.{provider}.{token} X-Snowflake-Authorization-Token-Type: WORKLOAD_IDENTITY_FEDERATION ``` where `{provider}` is `AWS`, `AZURE`, `GCP` or `OIDC`, and the token comes from the workload's cloud metadata service (audience `snowflakecomputing.com`; for Azure the resource is `api://fd3f753b-eed3-462c-b6a7-a4b5bb650aad`; for OIDC the token from your OIDC provider). Caveat: that page does not explicitly say the SQL API accepts WIF (its SQL API examples only show key-pair), and I have not tested this against a live account. Possible approach: add a WIF branch to `SnowflakeRestTokenProvider.get_token()` that fetches the platform token and returns `SnowflakeRestToken(token=f"WIF.{provider}.{token}", token_type="WORKLOAD_IDENTITY_FEDERATION")`. The Cortex Agent hook shares this provider, so it would benefit too. Docs inconsistency: `providers/snowflake/docs/connections/snowflake.rst` says the WIF connection "works for `SnowflakeHook`, `SnowflakeSqlApiHook`, `SnowflakeCortexAgentHook` and the `pydanticai_snowflake` connection type", but the code above rejects it for the REST-based hooks. If WIF is not going to be supported there, the docs should say so. ### Use case/motivation I want to run `SnowflakeSqlApiOperator` (including `deferrable=True`) on a cloud workload without storing any long-lived secret (password, key pair or PAT) in the Airflow connection, relying on the workload's cloud identity as `SnowflakeHook` already allows. Today the only keyless option is the connector-based hook, which loses the SQL API operator's deferrable and durable execution. ### Related issues #54983 (closed), PR #68107 (added WIF to `SnowflakeHook` only) ### Are you willing to submit a PR? - [x] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md) -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
