34282926a1
## 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>
7.5 KiB
products
| products |
|---|
| oss-community, oss-enterprise |
import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';
Secret Management
Secrets are sensitive information that should be kept confidential to protect the security and integrity of your instance.
:::info Airbyte's default behavior is to store connector secrets on your configured database. This will be stored in plain-text and not encrypted. :::
Airbyte highly recommends storing connector secrets in an external secret manager to ensure secrets are not exposed. Airbyte supports AWS Secrets Manager, Google Secrets Manager, Azure Key Vault, and Hashicorp Vault. Upon creating a new connector, secrets (e.g. OAuth tokens, database passwords) will be written to and read from the configured Secrets manager.
Secrets
apiVersion: v1
kind: Secret
metadata:
name: airbyte-config-secrets
type: Opaque
stringData:
# AWS Secret Manager
aws-secret-manager-access-key-id: ## e.g. AKIAIOSFODNN7EXAMPLE
aws-secret-manager-secret-access-key: ## e.g. wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
apiVersion: v1
kind: Secret
metadata:
name: airbyte-config-secrets
type: Opaque
stringData:
gcp.json: ## {
"type": "service_account",
"project_id": "cloud-proj",
"private_key_id": "2f3b9c8e7d5a1b4f23e697c0d84af6e1",
"private_key": "-----BEGIN PRIVATE KEY-----<REDACTED>\n-----END PRIVATE KEY-----\n",
"client_email": "cloud-proj.iam.gserviceaccount.com",
"client_id": "9876543210987654321",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/cloud-proj.iam.gserviceaccount.com"
}
apiVersion: v1
kind: Secret
metadata:
name: airbyte-config-secrets
type: Opaque
stringData:
azure-key-vault-client-id: ## 3fc863e9-4740-4871-bdd4-456903a04d4e
azure-key-vault-client-secret: ## KWP6egqixiQeQoKqFZuZq2weRbYoVxMH
Values
Modifing the configuration of connector secret storage will cause all existing connectors to fail. You will need to recreate these connectors to ensure they are reading from the appropriate secret store.
If authenticating with credentials, ensure you've already created a Kubernetes secret containing both your AWS Secrets Manager access key ID, and secret access key. By default, secrets are expected in the airbyte-config-secrets Kubernetes secret, under the aws-secret-manager-access-key-id and aws-secret-manager-secret-access-key keys. Steps to configure these are in the above prerequisites.
global:
secretsManager:
type: awsSecretManager
secretName: "airbyte-config-secrets" # Name of your Kubernetes secret.
awsSecretManager:
region: <aws-region>
authenticationType: credentials ## Use "credentials" or "instanceProfile"
tags: ## Optional - You may add tags to new secrets created by Airbyte.
- key: ## e.g. team
value: ## e.g. deployments
- key: business-unit
value: engineering
kms: ## Optional - ARN for KMS Decryption.
global:
secretsManager:
type: AWS_SECRET_MANAGER
secretName: "airbyte-config-secrets" # Name of your Kubernetes secret.
awsSecretManager:
region: <aws-region>
authenticationType: credentials ## Use "credentials" or "instanceProfile"
tags: ## Optional - You may add tags to new secrets created by Airbyte.
- key: ## e.g. team
value: ## e.g. deployments
- key: business-unit
value: engineering
kms: ## Optional - ARN for KMS Decryption.
Set authenticationType to instanceProfile if the compute infrastructure running Airbyte has pre-existing permissions (e.g. IAM role) to read and write from AWS Secrets Manager.
To decrypt secrets in the secret manager with AWS KMS, configure the kms field, and ensure your Kubernetes cluster has pre-existing permissions to read and decrypt secrets.
Ensure you've already created a Kubernetes secret containing the credentials blob for the service account to be assumed by the cluster. By default, secrets are expected in the airbyte-config-secrets Kubernetes secret, under a gcp.json file. Steps to configure these are in the above prerequisites. For simplicity, we recommend provisioning a single service account with access to both GCS and GSM.
global:
secretsManager:
type: googleSecretManager
secretName: "airbyte-config-secrets" # Name of your Kubernetes secret.
googleSecretManager:
projectId: <project-id>
region: "" ## Optional - e.g. us-central1
credentialsSecretKey: gcp.json
global:
secretsManager:
type: GOOGLE_SECRET_MANAGER
secretName: "airbyte-config-secrets" # Name of your Kubernetes secret.
googleSecretManager:
projectId: <project-id>
region: "" ## Optional - e.g. us-central1
credentialsSecretKey: gcp.json
global:
secretsManager:
type: azureKeyVault
secretsManagerSecretName: "airbyte-config-secrets" # Name of your Kubernetes secret.
azureKeyVault:
vaultUrl: ## https://my-vault.vault.azure.net/
tenantId: ## 3fc863e9-4740-4871-bdd4-456903a04d4e
tags: ## Optional - You may add tags to new secrets created by Airbyte.
- key: ## e.g. team
value: ## e.g. deployments
- key: business-unit
value: engineering
global:
secretsManager:
type: AZURE_KEY_VAULT
secretsManagerSecretName: "airbyte-config-secrets" # Name of your Kubernetes secret.
azureKeyVault:
vaultUrl: ## https://my-vault.vault.azure.net/
tenantId: ## 3fc863e9-4740-4871-bdd4-456903a04d4e
clientId: ""
clientIdSecretKey: ""
clientSecret: ""
clientSecretSecretKey: ""
tags: ## Optional - You may add tags to new secrets created by Airbyte.
- key: ## e.g. team
value: ## e.g. deployments
- key: business-unit
value: engineering
global:
secretsManager:
type: VAULT
secretsManagerSecretName: "airbyte-config-secrets" # Name of your Kubernetes secret.
vault:
address: ""
prefix: ""
authToken: ""
authTokenSecretKey: ""