Hello guys i am trying to setup airbyte using helm v2 in my helmrelease file, I want to use vault as secretmanager. I am following what is given and tried many more things then too when am creating any source in airbyte getting an error:- Configuration check failed Workload failed, source: airbyte_platform Internal message: Init container error encountered while hydrating secrets for id: 6e2-b3-4c7-xxx-4499ad_0_check. Encountered exception of type: class secrets.persistence.SecretCoordinateException. Exception message: That secret was not found in the store! Coordinate: airbyte_workspace_00000000-0000-0000-0000-000000000000_secret_f1fc-6e3c-4877-xxx-933_v1. Failure origin: airbyte_platform can someone help me this is really urgent thanks in advance

This error means Airbyte is trying to read a secret from the configured secret manager (Vault in your case), but that secret coordinate does not exist there: >

That secret was not found in the store! Coordinate: airbyte_workspace_00000000-0000-0000-0000-000000000000_secret_..._v1

A few key points from the docs that are relevant: 1. How Airbyte uses secret coordinates - When a connector has a field marked

airbyte_secret: true

, Airbyte: - Writes the real value to the configured secret store under a generated coordinate like

airbyte_workspace_<workspace-id>_secret_<uuid>_<version>

. - Stores only that coordinate in the DB / config JSON. [[Secrets usage](https://docs.airbyte.com/platform/understanding-airbyte/secrets)] - For operations like Check or Discover that are not tied to a workspace, the workspace id in the coordinate is

00000000-0000-0000-0000-000000000000

. [[Secrets usage](https://docs.airbyte.com/platform/understanding-airbyte/secrets)] Your failing coordinate is exactly one of those “non‑workspace” secrets. 2. Configuring Vault as the connector secret manager (Helm v2) For Helm v2, the

values.yaml

must have the

global.secretsManager

block set to

VAULT

, for example: [[Secret values 1.8](https://docs.airbyte.com/platform/1.8/deploying-airbyte/integrations/secrets#values); [Secret values next](https://docs.airbyte.com/platform/next/deploying-airbyte/integrations/secrets#values)]

yaml    global:      secretsManager:        type: VAULT        secretsManagerSecretName: "airbyte-config-secrets" # Name of your Kubernetes secret        vault:          address: "https://<your-vault-url>"   # e.g. <https://my-vault.vault.azure.net/> or your Vault endpoint          prefix: "kv/airbyte/"                 # or whatever path you use, must end with /          authToken: ""                         # OR          authTokenSecretKey: ""                # key in the Kubernetes secret that holds the token

And you must have a Kubernetes secret named

airbyte-config-secrets

(or whatever you set in

secretsManagerSecretName

) that actually contains the Vault token if you use

authTokenSecretKey

. [[Secret values deploy](https://docs.airbyte.com/platform/deploying-airbyte/integrations/secrets#values)] 3. Common causes of “secret not found in the store” with Vault Based on the docs, the following misconfigurations will lead to exactly this symptom: -

global.secretsManager.type

is not set to

VAULT

(or is still the default), so Airbyte is writing coordinates but not actually able to write/read from Vault. -

vault.prefix

is wrong (e.g. missing the engine name or trailing slash), so Airbyte writes to one path and then looks up in another. -

vault.address

or the Vault token (via

authToken

/

authTokenSecretKey

) is invalid, so writes fail and the coordinate is created in the DB but no secret is stored. - The

secretsManagerSecretName

Kubernetes secret is missing or does not contain the key referenced by

authTokenSecretKey

. 4. Important warning when changing secret manager The docs explicitly state: changing the connector secret storage configuration **will cause all existing connectors to fail**; you must recreate them. [[Secret values deploy](https://docs.airbyte.com/platform/deploying-airbyte/integrations/secrets#values)] So if you switched to Vault after creating some sources/destinations, you need to: - Delete those connectors. - Recreate them after Vault is correctly configured. --- ### What to check in your setup Given the above, here’s what you should verify in your HelmRelease (values) and cluster: 1. In your HelmRelease values, under `global.secretsManager`: -

type: VAULT

-

secretsManagerSecretName: "airbyte-config-secrets"

(or your chosen name) -

vault.address

,

vault.prefix

, and either

vault.authToken

or

vault.authTokenSecretKey

are set. 2. In Kubernetes: - The secret named in

secretsManagerSecretName

exists. - If you use

authTokenSecretKey

, that key exists in the secret and contains a valid Vault token with read/write permissions on the

prefix

path. 3. After fixing the configuration: - Restart / upgrade the Airbyte release so all pods pick up the new config. - Delete and recreate the failing source so its secrets are freshly written to Vault. If you can share the

global.secretsManager

section from your HelmRelease (with sensitive values redacted), I can help you pinpoint what in that block doesn’t match the documented patterns.

@kapa.ai Error: couldn't find key VAULT_TOKEN in Secret airbyte/airbyte-airbyte-secrets

A message from kapa.ai

@kapa.ai if my vault cli path:- -mount="kv/non-prod/cdp" "gke-use1-symphony-dev/airbyte" what will be prefix to use above

A message from kapa.ai

@kapa.ai other than secretmanager in values.yaml is there any other thing needed to for connecting Vault and airbyte

A message from kapa.ai

@kapa.ai i am using version: "2.0.18

A message from kapa.ai