Replies: 1 comment
|
Sorry for late. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
We use multiple BigQuery data sources in Redash, each mapped to a different service account for dataset-level isolation. Today, that effectively means storing a JSON key per data source, because the standard BigQuery runner uses
jsonKeyFilewhen a per-data-source identity is needed, and only falls back to ADC when no key is configured.We would like to use a more secure setup based on ADC / OIDC / Workload Identity Federation, without long-lived JSON keys, while still being able to choose a different effective service account per BigQuery data source.
This seems adjacent to #5760, but the goal is different:
Proposed direction:
jsonKeyFilepath for backward compatibility.impersonatedServiceAccountto the BigQuery data source configuration.jsonKeyFileis not set, usegoogle.auth.default()as the source credential.impersonatedServiceAccountis set, create BigQuery credentials viagoogle.auth.impersonated_credentials.Credentials.This would allow deployments on GKE / Cloud Run / GCE / EKS with Workload Identity or other ADC-compatible setups to avoid key distribution entirely, while still preserving per-data-source IAM separation.
A related issue is #7332, which shows there is already interest in ADC-based BigQuery usage, although that one is specifically about the
Test Connectionbehavior.Would maintainers be open to this direction? If yes, I can put together a PR for the BigQuery query runner and tests.
All reactions