## What Generates version 2.0 of the Airbyte platform documentation using Docusaurus's built-in versioning system. This creates a frozen snapshot of the current documentation that users can reference. Requested by ian.alton@airbyte.io via [Slack thread](https://airbytehq-team.slack.com/archives/D08FX8EC9L0/p1760490197805979?thread_ts=1760490197.805979). Link to Devin run: https://app.devin.ai/sessions/689693593bac44f4903f476aa17b872e ## How - Ran `pnpm run docusaurus docs:version:platform 2.0` in the docusaurus directory - This automatically: - Created `platform_versioned_docs/version-2.0/` containing a snapshot of all current platform docs - Created `platform_versioned_sidebars/version-2.0-sidebars.json` with the sidebar navigation structure - Updated `platform_versions.json` to add "2.0" to the version list - Ran prettier to format the JSON files - Verified the documentation builds successfully locally (build completed in ~3 minutes with only pre-existing broken anchor warnings) ## Review guide 1. **Verify timing**: Confirm this is the correct time to release version 2.0 of the documentation 2. **Version order**: Check `docusaurus/platform_versions.json` - verify "2.0" is first in the array (newest version first) 3. **Build verification**: Ensure CI/Vercel builds pass without errors 4. **Spot check**: Optionally review 2-3 files in `docusaurus/platform_versioned_docs/version-2.0/` to ensure content looks reasonable Note: This is a standard Docusaurus versioning operation that creates a frozen snapshot of the current "next" documentation. The generated files are extensive (500+ files) but follow Docusaurus conventions. ## User Impact Users will see version 2.0 available in the version dropdown on docs.airbyte.com. This provides a stable reference point for platform documentation at this point in time. Existing versions (1.6, 1.7, 1.8) remain unchanged. ## Can this PR be safely reverted and rolled back? - [x] YES 💚 This is an additive change that doesn't modify existing versioned docs. Reverting would simply remove version 2.0 from the version list and delete the associated documentation files. Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Co-authored-by: ian.alton@airbyte.io <ian.alton@airbyte.io>
4.3 KiB
products
| products |
|---|
| oss-community, oss-enterprise |
import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';
Authentication
Airbyte comes with built in authentication based on the email provided at setup and a generated password. If you need to
view your password and you are running Airbyte through abctl you can run the following:
abctl local credentials
Which should output something similar to:
{
"password": "password",
"client-id": "client_id",
"client-secret": "client_secret"
}
If you have deployed to your own Kubernetes cluster using Helm, then you can view your credentials by running the following:
kubectl get secret airbyte-auth-secrets -n <YOUR_NAMESPACE> -o yaml
Which will return something similar to:
apiVersion: v1
data:
instance-admin-client-id: Y2Q1ZTc4ZWEtMzkwNy00ZThmLWE1ZWMtMjIyNGVhZTFiYzcw
instance-admin-client-secret: cmhvQkhCODlMRmh1REdXMWt3REpHZTJMaUd3N3c2MjU=
instance-admin-password: d0V2bklvZEo1QUNHQnpPRWxrOWNSeHdFUGpJMWVzMWg=
kind: Secret
metadata:
creationTimestamp: "2024-07-31T04:22:54Z"
name: airbyte-auth-secrets
namespace: airbyte-abctl
resourceVersion: "600"
uid: f47170eb-f739-4e58-9013-b7afb3ac336a
type: Opaque
These values are base64 encoded, to decode your password run the following:
echo 'cmhvQkhCODlMRmh1REdXMWt3REpHZTJMaUd3N3c2MjU=' | base64 -d
Turning Off Authentication
There may be times when your wish to turn off authentication, for instance if you have already configured a proxy that authenticates users with your organization's SSO. In these cases you can turn off Airbyte's authentication by adding the following to your values.yaml file:
global:
auth:
enabled: false
For users that are using the abctl tool you can apply this by running the following:
abctl local install --values ./values.yaml
Setting a Password via Secrets
You can also control the default password by supplying your own values as a Kubernetes secret. Start by creating a file
called secret.yaml and add the following Kubernetes Secret into that file:
apiVersion: v1
kind: Secret
metadata:
name: airbyte-auth-secrets
type: Opaque
stringData:
instance-admin-password: # 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
If you are deploying Airbyte with abctl you can run:
abctl local install --secret secret.yaml
If you are deploying to your own Kubernetes cluster, run:
kubectl apply -f secret.yaml -n <YOUR_NAMESPACE>
You may need to restart the airbyte-server pod for the changes to take effect.
Cookie Security Settings
Disabling Secure Cookies
For users running Airbyte on a non-localhost domain without HTTPS, secure cookies cannot be set. To disable secure cookies, update your values.yaml file with the following snippet:
global:
auth:
cookieSecureSetting: "false"
global:
auth:
security:
cookieSecureSetting: "false"
This setting should only be used if HTTPS is not available, as it reduces security by allowing cookies to be transmitted over non-secure connections.
Modifying Cookie SameSite Setting
By default, Airbyte uses a cookieSameSiteSetting of "Strict". If you need to allow cookies to be sent in a cross-site context, you can change this setting to "None". Update your values.yaml file with the following:
global:
auth:
cookieSameSiteSetting: "None"
global:
auth:
security:
cookieSameSiteSetting: "None"
Note: Setting cookieSameSiteSetting to "None" may be necessary for certain integrations but should be used cautiously as it can make your application more susceptible to CSRF attacks. Make sure other security measures are in place if you configure this setting.
These changes will take effect the next time you deploy Airbyte using your updated values.yaml file.