Tautvydas Varnas
03/13/2026, 1:25 PMkapa.ai
03/13/2026, 1:25 PMapiVersion: v1
kind: Secret
metadata:
name: airbyte-auth-secrets
type: Opaque
stringData:
instance-admin-password: # your-password
# Override these if you want to access the API with known credentials
#instance-admin-client-id: # my-client-id
#instance-admin-client-secret: # my-client-secret
Apply it to your cluster:
kubectl apply -f secret.yaml -n <YOUR_NAMESPACE>
[Setting a Password via Secrets]
2. Verify Your Credentials
After deployment, you can retrieve your credentials by running:
kubectl get secret airbyte-auth-secrets -n <YOUR_NAMESPACE> -o yaml
The values returned are base64 encoded. To decode your password:
echo '<base64-encoded-value>' | base64 -d
[Authentication]
3. (Optional) Turn Off Authentication
If you have an external proxy handling authentication (e.g., your organization's SSO), you can disable Airbyte's built-in auth by adding the following to your `values.yaml`:
global:
auth:
enabled: false
[Turning Off Authentication]
4. (Optional) Cookie Security Settings
If you're running without HTTPS, you may need to disable secure cookies:
global:
auth:
cookieSecureSetting: "false"
[Authentication]
-------------------------
Note: After applying secret changes to an existing deployment, you may need to restart the airbyte-server pod for the changes to take effect. [Authentication] đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Tautvydas Varnas
03/13/2026, 1:39 PMkapa.ai
03/13/2026, 1:39 PMcouldn't find key instance-admin-password in Secret airbyte-secrets indicates a mismatch between the secret name the bootloader is looking for and the secret you've created.
Root Cause
There is a known bug in the Airbyte Helm chart where the airbyte-bootloader sub-chart hardcodes the secret name to airbyte-auth-secrets instead of reading it from values.yaml. This means even if you configure a custom secret name, the bootloader ignores it. [Helm chart ignores user secrets]
Solutions
Option 1: Use the expected secret name airbyte-auth-secrets
The simplest fix is to ensure your secret is named airbyte-auth-secrets with the key instance-admin-password:
apiVersion: v1
kind: Secret
metadata:
name: airbyte-auth-secrets
type: Opaque
stringData:
instance-admin-password: your-password
#instance-admin-client-id: my-client-id
#instance-admin-client-secret: my-client-secret
Apply it:
kubectl apply -f secret.yaml -n <YOUR_NAMESPACE>
[Setting a Password via Secrets]
-------------------------
Option 2: Workaround via extraEnv in values.yaml
If you want to keep your secret under a different name (e.g., airbyte-config-secrets), you can override the bootloader's environment variable directly in your `values.yaml`:
airbyte-bootloader:
enabled: true
extraEnv:
- name: AB_INSTANCE_ADMIN_PASSWORD
valueFrom:
secretKeyRef:
name: "airbyte-config-secrets"
key: "instance-admin-password"
This bypasses the hardcoded secret name in the bootloader sub-chart. [Helm chart ignores user secrets]
-------------------------
Option 3: For Enterprise deployments (recommended structure)
If you're on Airbyte Enterprise, the recommended approach is to use a secret named airbyte-config-secrets with the key instance-admin-password, and reference it in values.yaml under `global.auth.instanceAdmin`: [Creating a Kubernetes Secret]
global:
auth:
instanceAdmin:
secretName: "airbyte-config-secrets"
passwordSecretKey: "instance-admin-password"
However, due to the known bug, you may still need the extraEnv workaround (Option 2) alongside this configuration.
-------------------------
Summary: The most reliable fix right now is either to name your secret airbyte-auth-secrets (Option 1) or use the extraEnv workaround to explicitly point the bootloader to your secret (Option 2). đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.