https://linen.dev logo
Join Slack
Powered by
Hi <@U04S8PLJWMT> the global auth set in the helm ...
# replication-ask-ai
i
Hi @kapa.ai the global auth set in the helm is not working for. I see a login screen but the creds are not working that i set in the kuebernetes secret. I am seeing 401 errors
k
There are known issues with Helm-based deployments where the 
global.auth.instanceAdmin.*
settings and related Helm values are ignored, and Airbyte instead uses (or creates) the 
airbyte-auth-secrets
Secret with its own credentials. This matches what you’re seeing: login page appears, but the credentials you put in your own Secret don’t work and you get 401s. [[Deploy auth](https://docs.airbyte.com/platform/deploying-airbyte/integrations/authentication); [Helm password bug](https://github.com/airbytehq/airbyte/issues/65154)] From the docs, the only supported way (today) to control the initial admin password is: 1. Create/modify the 
airbyte-auth-secrets
Secret in your namespace:
Copy code
yaml    apiVersion: v1    kind: Secret    metadata:      name: airbyte-auth-secrets    type: Opaque    stringData:      instance-admin-password: YOUR_PASSWORD_HERE      # optional:      # instance-admin-client-id: YOUR_CLIENT_ID      # instance-admin-client-secret: YOUR_CLIENT_SECRET
Then apply it:
Copy code
bash    kubectl apply -f secret.yaml -n <YOUR_NAMESPACE>
[[Deploy auth](https://docs.airbyte.com/platform/deploying-airbyte/integrations/authentication)] 2. Restart the 
airbyte-server
pod so it picks up the new secret. [[Deploy auth](https://docs.airbyte.com/platform/deploying-airbyte/integrations/authentication)] 3. To read what Airbyte is currently using (and confirm), run:
Copy code
bash    kubectl get secret airbyte-auth-secrets -n <YOUR_NAMESPACE> -o yaml
Then base64‑decode `instance-admin-password`:
Copy code
bash    echo '<base64-value>' | base64 -d
[[Deploy auth](https://docs.airbyte.com/platform/deploying-airbyte/integrations/authentication)] Because of the chart bugs, changing 
global.auth.instanceAdmin.passwordSecretKey
/ 
secretName
in 
values.yaml
does not reliably work in chart versions noted in the GitHub issues. [[Helm password bug](https://github.com/airbytehq/airbyte/issues/65154); [passwordSecretKey issue](https://github.com/airbytehq/airbyte/issues/54685)] Recommended next steps for you 1. Ensure your password is set in 
airbyte-auth-secrets
exactly under key 
instance-admin-password
(stringData is easiest). 2. Redeploy or restart 
airbyte-server
. 3. Try logging in with: - Username: the instance admin email currently configured/created, and - Password: the value from 
instance-admin-password
in 
airbyte-auth-secrets
. If you’re relying solely on 
global.auth.instanceAdmin.passwordSecretKey
pointing to another Secret name/key, it will likely be ignored due to the current chart bug; use 
airbyte-auth-secrets
instead.
i
@kapa.ai how does the bearer auth token here works ?
k
A message from kapa.ai
The “Bearer” token you’re seeing is an access token used in HTTP 
Authorization
headers to authenticate API calls to Airbyte. 1. How you get it You first exchange a 
client_id
and 
client_secret
(from an Application in the Airbyte UI) for an access token, e.g.:
Copy code
bash    curl --request POST \         --url <https://api.airbyte.com/v1/applications/token> \         --header 'accept: application/json' \         --header 'content-type: application/json' \         --data '{           "client_id": "<YOUR_CLIENT_ID>",           "client_secret": "<YOUR_CLIENT_SECRET>",           "grant-type": "client_credentials"         }'
The response contains:
Copy code
json    {      "access_token": "<YOUR_ACCESS_TOKEN>",      "token_type": "Bearer",      "expires_in": 900    }
[[Next API token](https://docs.airbyte.com/platform/next/using-airbyte/configuring-api-access#step-2-get-an-access-token)] On self‑managed Enterprise 1.6–1.8 and “classic” docs the flow is the same (client ID + secret → POST 
/api/v1/applications/token
→ get back a Bearer token). [[1.8 API access](https://docs.airbyte.com/platform/1.8/enterprise-setup/api-access-config); [Using API access](https://docs.airbyte.com/platform/using-airbyte/configuring-api-access)] 2. How you use it On subsequent API calls you send it in the 
Authorization
header:
Copy code
bash    curl --request GET \         --url <YOUR_AIRBYTE_URL>/api/public/v1/workspaces \         --header "Authorization: Bearer <YOUR_ACCESS_TOKEN>"
[[1.8 API access](https://docs.airbyte.com/platform/1.8/enterprise-setup/api-access-config)] The server validates that Bearer token and, if it’s valid and not expired, authorizes the request according to the permissions of the Application it was issued for. 3. Lifetime / rotation - In “Using Airbyte” docs, tokens are short‑lived (typically 3 minutes) and you should fetch a new token before each request or let the SDK/Terraform provider do it. [[Using API access](https://docs.airbyte.com/platform/using-airbyte/configuring-api-access)] - In some Enterprise versions, tokens are valid for up to 60 minutes. [[1.8 API access](https://docs.airbyte.com/platform/1.8/enterprise-setup/api-access-config)] So, the “Bearer” part is just the token type in the 
Authorization
header; the value after it is the opaque access token you obtained from the 
/applications/token
endpoint, and Airbyte uses that to authenticate and authorize your API calls.
i
@kapa.ai can i use basic auth here someway ?
k
A message from kapa.ai
In Airbyte’s HTTP-based connectors and Connector Builder, Basic Auth is supported as an authentication method, but for the platform UI/API login itself (the screen where you’re seeing 401s) the docs only describe: - The built-in email + password login (backed by 
airbyte-auth-secrets
), and - Optionally turning auth off via 
global.auth.enabled: false
. [[Deploy auth](https://docs.airbyte.com/platform/deploying-airbyte/integrations/authentication)] There is no mention in the platform authentication docs of switching that login to HTTP Basic Auth, so based on the available documentation it is not supported for the UI/API login. Where you can use Basic Auth is: - In declarative/config-based connectors, via `BasicHttpAuthenticator`:
Copy code
yaml   authenticator:     type: "BasicHttpAuthenticator"     username: "hello"     password: "world"
This sets an 
Authorization: Basic <base64(user:pass)>
header on outgoing requests from the connector. [[YAML auth](https://docs.airbyte.com/platform/connector-development/config-based/understanding-the-yaml-file/authentication)] - In the Connector Builder UI, by choosing Basic HTTP under Authentication methods; it will handle the 
Authorization: Basic …
header for you. [[Builder auth methods](https://docs.airbyte.com/platform/connector-development/connector-builder-ui/authentication#authentication-methods)] So: - For logging into Airbyte itself: docs only support the built-in auth (email + password from 
airbyte-auth-secrets
) or disabling auth; Basic Auth is not documented as an option. [[Deploy auth](https://docs.airbyte.com/platform/deploying-airbyte/integrations/authentication)] - For calling external APIs from connectors: yes, you can use Basic Auth as shown above.
2 Views
Open in Slack
PreviousNext
Powered by