@kapa.ai is there a way to use GCS as storage and configure it in the helm chart, without using a json credentials file ? For example our airbyte SA would have the permissions and roles on GCS

The provided knowledge sources do not mention or provide a method to configure GCS storage in the Helm chart using ambient credentials or GKE Workload Identity without providing a Service Account JSON key [issue 71828]. Currently, the documented configuration for GCS state and log storage in the Helm chart requires a Kubernetes secret containing a Service Account JSON key via

credentialsJsonSecretKey

(or

credentialsJson

):

global:  
  storage:  
    type: "gcs"  
    secretName: airbyte-config-secrets  
    bucket:
      log: airbyte-bucket  
      state: airbyte-bucket  
      workloadOutput: airbyte-bucket  
    gcs:  
      projectId: <project-id>  
      credentialsJsonSecretKey: gcp.json

[storage documentation] While AWS S3 explicitly supports an

authenticationType: instanceProfile

setting to use IAM roles without static credentials [storage documentation], no equivalent native setting for Google Application Default Credentials or Workload Identity is documented for GCS storage in the Helm chart. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai if I provide a fake json credentials file, will it fallback to GKE workload identity ?

Based on the provided knowledge sources, no—providing a fake or invalid JSON credentials file will not fall back to GKE Workload Identity. When an invalid or unrecognized JSON file is provided, the underlying Google Cloud SDK and storage clients fail during authentication or initialization instead of falling back: • If the JSON file cannot be parsed as a valid

service_account

type (e.g., using

external_account

or an invalid structure), it throws errors such as

java.io.IOException: Error reading credentials from stream, 'type' value ... not recognized. Expecting 'service_account'

[forum post 2277]. • If the credentials file cannot be properly decoded or found at the expected path, the worker and storage clients crash on startup with a

BeanInstantiationException

or

NoSuchFileException

for

GcsStorageClient

[github issue 65153; github issue 73739]. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai will it work if we don't provide credentialsJsonSecretKey, given that Airbyte pods can already talk to GCS with zero keys, via WIF token exchange ?

Based on the provided knowledge sources, no, it will not work out-of-the-box simply by omitting

credentialsJsonSecretKey

. Here is why: 1. Helm Chart Defaults to a Secret Key: In the Helm chart v2, if you omit

credentialsJsonSecretKey

, the chart defaults to looking for a secret key named

GOOGLE_APPLICATION_CREDENTIALS_JSON

inside the specified Kubernetes secret [pull request 82797; issue 70352]. 2. Missing Key / Failed Mount Errors: If the referenced secret key does not exist in your Kubernetes secret, pod creation fails at the Kubernetes volume mount stage with an error such as:MountVolume.SetUp failed for volume "gcs-log-creds-volume" : references non-existent secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON[issue 70352]. 3. Hardcoded Credential Paths: The Workload Launcher and internal storage clients expect a mounted credentials file and set

GOOGLE_APPLICATION_CREDENTIALS

to point to that file (e.g., under

/secrets/gcp-creds/

or

/secrets/gcs-log-creds/

). If that file is missing, the components fail on startup with a

BeanInstantiationException

when initializing

GcsStorageClient

or

WorkloadOutputWriter

[issue 65153; issue 73739]. The knowledge sources do not document a built-in mechanism in the Helm chart to bypass file mounting for GCS in order to rely purely on ambient Workload Identity Federation (WIF) [issue 71828; storage documentation]. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements