fpopic commented on PR #53801: URL: https://github.com/apache/airflow/pull/53801#issuecomment-4060195321
> @fpopic , Would a user ever not want this to happen? Do you think its worth providing a way to not automatically have the fallback to @rawwar I checked also [aws_iam](https://github.com/fpopic/airflow/blob/9c8114f1f94463f86a5aae42d54ac04910551572/providers/hashicorp/src/airflow/providers/hashicorp/_internal_client/vault_client.py#L401-L427) auth type which follows the similar approach (e.g. checks for static credentials otherwise falls back assuming short-lived credentials). One counter-example gemini cli brought: > > A common counter-example is environment isolation for security compliance. > > In some highly regulated environments (e.g., PCI-DSS or HIPAA), a single Airflow cluster might be used to run DAGs for multiple different business units. If a developer accidentally forgets to provide a service account key in their Vault connection, the system might silently fall back to the GKE/GCE Node's default identity. > > If that node identity has broad permissions (which is unfortunately a common misconfiguration), the DAG could gain unauthorized access to secrets in Vault that it shouldn't have. In such cases, the user would prefer a "Fail Fast" behavior: the task should crash immediately if the explicitly requested credentials are missing, rather than defaulting to a "powerful" environment identity. Since this pattern is already established for cloud, the concern about "silent fallback" or GCP is effectively a concern about the provider's general architecture, which this PR correctly brings into parity for Google Cloud. -- 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]
