An Airbyte deployment holds working credentials for every source and destination it syncs, so access to its UI, API and database is effectively access to your data estate. This guide covers the customer side of running Airbyte securely, with most attention on self managed deployments installed with abctl or Helm: network placement, the built in authentication and its secrets, roles and SSO, API applications and tokens, external secrets managers, custom connector images and logging. It is written for data platform engineers, DevOps teams and security reviewers who own an Airbyte instance. For pipeline wide controls that apply to any ELT tool, see the ETL and ELT Pipeline Security Guide.
This is an independent guide from NHI Mgmt Group, based on Airbyte's public documentation as of November 2026. It is not sponsored or reviewed by Airbyte. Product features change, so confirm settings against Airbyte's current documentation.
Key takeaways
- Keep the instance off the open internet. Airbyte's guidance is to run it in a private network or behind a firewall, with a reverse proxy, Identity-Aware Proxy or Session Manager handling access and TLS.
- Change the generated admin password. abctl and Helm generate an instance admin password, client ID and client secret in the airbyte-auth-secrets Kubernetes secret; set your own and restrict who can read that secret.
- Move connector secrets to an external manager. By default connector credentials live in the Airbyte database; configure AWS Secrets Manager, Google Secret Manager, Azure Key Vault or HashiCorp Vault before you create connectors.
- Use a service account for API automation. API applications act with the full permissions of the user who created them, and access tokens last 15 minutes; build automation on a dedicated identity, not a person.
- Pin connector images to your own registry. Mirror platform and connector images into a private registry with global.image.registry and pull secrets, and review custom Docker connectors like any third party code.
How identity and access work in Airbyte
Airbyte has three access surfaces: the web UI, the public API served by airbyte-server, and the infrastructure underneath (the Kubernetes cluster, its secrets and the configuration database). Each needs its own control. Airbyte's own guidance is clear that for self managed Core deployments, controlling access to the host and network is the operator's responsibility, and its security commitments apply to Airbyte Cloud.
| Surface | Default | Customer action |
|---|---|---|
| Web UI login | Built in authentication: setup email plus a generated password | Set a strong password through airbyte-auth-secrets; front with an SSO proxy |
| Public API | Applications with client ID and secret; Bearer tokens valid 15 minutes | One application per automation identity; store the secret in a vault |
| Authentication switch | global.auth.enabled defaults to on for Helm deployments | Turn it off only where an authenticating proxy enforces SSO for every request |
| Session cookies | cookieSameSiteSetting is Strict | Keep Strict and keep cookieSecureSetting true with HTTPS |
| Connector secrets | Stored in the configured database | Configure global.secretsManager before creating connectors |
| Host and cluster | Your infrastructure | Private network, firewall, Kubernetes RBAC on the airbyte namespace |
Network placement
Run Airbyte in a private subnet or restrict inbound access by IP at the firewall. Put a reverse proxy in front to terminate TLS and enforce access control; Airbyte's example proxies to http://127.0.0.1:8000 and raises client_max_body_size to 200M for large uploads. On cloud hosts, Airbyte suggests GCP Identity-Aware Proxy or AWS Systems Manager Session Manager so that no port is opened to the internet at all. From version 0.44.0 Airbyte runs a security self check that tests whether the instance is reachable from the internet and whether strong authentication is configured: act on its warnings rather than dismissing them.
Connections from Airbyte to sources and destinations should be encrypted too. Most connectors offer an SSL or HTTPS option, and Airbyte recommends turning it on wherever it is offered. See the Network Segmentation Guide for placing the data integration tier.
Built in authentication
With abctl, abctl local credentials prints the instance admin password, client ID and client secret. On Helm, they sit in the airbyte-auth-secrets secret under instance-admin-password, instance-admin-client-id and instance-admin-client-secret. To set your own, create that secret with your values and install with abctl local install --secret secret.yaml or apply it with kubectl, then restart airbyte-server if needed. Anyone who can read secrets in the Airbyte namespace can read these values, so Kubernetes RBAC on that namespace is part of Airbyte access control.
Two cookie settings under global.auth.security matter: cookieSecureSetting should stay true, since false lets cookies travel over plain HTTP, and cookieSameSiteSetting should stay at its Strict default, since None widens cross site request forgery exposure.
Admin roles and privileged access
Availability: as of November 2026 Airbyte's documentation lists role based access control on the Pro and Enterprise Flex plans, and SSO through OpenID Connect on Plus, Pro and Enterprise Flex, with setup guides for Entra ID and Okta and SCIM provisioning as an add-on. On Core, Standard and Plus every user is a workspace or organisation admin. On Core, keep the user population small and put identity controls in the proxy layer.
| Workspace role | Can do | Typical holder |
|---|---|---|
| Reader | View workspace, connections and settings | Auditors, data consumers |
| Runner | Reader plus start and cancel syncs | Operations on call |
| Source editor | Runner plus manage sources, source OAuth and Connector Builder connectors | Teams that own source systems |
| Destination editor | Runner plus manage destinations and destination OAuth | Warehouse owners |
| Editor | Runner plus manage sources and destinations | Data engineers |
| Admin | All permissions, including workspace settings and connector versions | Platform owners only |
Organisation Admin adds creating and deleting workspaces, organisation settings (billing, SSO) and user role management. Plan these assignments carefully:
- Grant admin sparingly: Airbyte notes that admin roles cannot be demoted once assigned, so a mistaken grant means removing and re-adding the user.
- Remember inheritance: a workspace role can raise but never lower a user's organisation role, and group permissions combine with individual ones at the highest level.
- Split source and destination ownership: Source editor and Destination editor are separate and neither implies the other, which lets you separate the people who hold source credentials from those who hold warehouse credentials.
- Treat Kubernetes and database admins as Airbyte admins: anyone with cluster admin, secret read in the namespace, or direct access to the configuration database can bypass application roles.
See the Least Privilege Techniques Guide for role design method.
Integrations, API tokens and service accounts
Airbyte creates and uses several non-human identities: API applications, the credentials stored in each source and destination, the identity Airbyte uses to reach its secrets manager, and registry pull credentials.
API applications
An application is created under User settings, Applications, and is identified by a client ID and client secret. Exchanging them at /api/public/v1/applications/token on a self managed instance (or the Cloud API host) returns a Bearer token with expires_in of 900 seconds. The token carries the same permissions as the user it represents, checked against token scope and the workspace of each resource. Airbyte recommends a service account rather than personal credentials, so scripts keep working when someone leaves. In practice: create a dedicated user with the narrowest role that does the job, create its application, keep the client secret in a vault and request tokens on demand. See the API Key Management Guide.
External secrets managers
Configure global.secretsManager in values.yaml with one of four types:
| type value | Key settings | How Airbyte authenticates |
|---|---|---|
| AWS_SECRET_MANAGER | awsSecretManager.region, authenticationType, tags, kms | instanceProfile (IAM role) or stored access keys |
| GOOGLE_SECRET_MANAGER | googleSecretManager.projectId, region, credentialsSecretKey | Service account JSON key held in a Kubernetes secret |
| AZURE_KEY_VAULT | azureKeyVault.vaultUrl, tenantId, clientId, clientSecret | Client ID and secret |
| VAULT | vault.address, prefix, authToken | Vault token |
Prefer instanceProfile on AWS so there is no static key to rotate. Where a static credential is unavoidable, keep it in the referenced Kubernetes secret (airbyte-config-secrets by default), scope it to the Airbyte secret path or prefix only, and rotate it on a schedule. Decide this before go-live: Airbyte warns that changing secret storage breaks existing connectors, which must then be recreated. See the Secrets Management Guide.
Connector credentials
- Dedicated, read only source accounts: give each source connector its own database user or API credential with read access to the tables it syncs.
- Scoped destination accounts: the destination user needs write access only to the target schema.
- Prefer OAuth or key pair options where a connector offers them over shared passwords, and record the owner of every credential.
- Use timestamp cursors: Airbyte notes that technical logs may contain values from connection state, and recommends a timestamp cursor such as updated_at so sensitive values do not end up in logs.
Custom connectors and images
Custom Docker connectors are added under Workspace settings, Sources or Destinations, New connector, Add a new Docker connector, by giving a full image name and tag. Airbyte recommends keeping the image in a private registry that requires authentication on both push and pull; on Kubernetes the pull secret is named in JOB_KUBE_MAIN_CONTAINER_IMAGE_PULL_SECRET on airbyte-worker. To pull platform and connector images from your own registry, set global.image.registry and global.imagePullSecrets, list the platform images with abctl images manifest, and mirror connector images before adding sources. A custom connector given a fully qualified image name skips the configured registry, so require registry prefixes in review. Treat every custom connector as code that will receive production credentials: code review, image scanning and signed builds belong in its pipeline. See the Container Image Security Guide.
Logging and detection
Keep the server log level at INFO in production: Airbyte notes that at DEBUG the server can write initial user configuration to logs. Availability: Airbyte's documentation lists audit logging for Pro and Enterprise Flex organisations on Cloud, retained for 365 days in the control plane. On self managed Core, build your audit trail from the reverse proxy, Kubernetes audit logs and your secrets manager's access logs.
| Signal | Source | Why it matters |
|---|---|---|
| UI and API requests by user and source IP | Reverse proxy or IAP logs | Unexpected access paths or locations |
| Token requests to applications/token | Proxy logs | Automation outside its usual schedule or host |
| Reads of airbyte-auth-secrets and airbyte-config-secrets | Kubernetes audit log | Admin credential exposure |
| Secret reads under the Airbyte prefix | Secrets manager logs | Credential harvesting beyond normal sync volume |
| New or changed connectors and connector versions | Airbyte audit log (where available), connector configuration review | New data exfiltration path |
| Image pulls from unexpected registries | Cluster and registry logs | Unreviewed connector code |
Metrics to track: instances reachable from the internet (target zero); connectors whose secrets sit in an external manager; API applications owned by service accounts rather than people; custom connector images pulled from the approved registry; days since the admin password and secrets manager credential were last rotated. For detection content on cluster logs see the Kubernetes Audit Log Detection Guide.
Hardening baseline
- Place: deploy into a private subnet or behind a firewall allow list; publish only through a TLS reverse proxy, IAP or Session Manager.
- Authenticate: keep global.auth.enabled on, set your own instance admin password and API credentials in airbyte-auth-secrets, keep secure and Strict cookie settings.
- Restrict the cluster: limit Kubernetes RBAC on the Airbyte namespace, especially secret read, and restrict network access to the configuration database.
- Externalise secrets: configure global.secretsManager before creating connectors, preferring workload identity such as instanceProfile.
- Assign roles: where RBAC is available, give Reader or Runner by default, split Source editor and Destination editor, and keep Admin to a named few. Enable SSO and SCIM where your plan includes them.
- Control images: mirror images into a private registry, set global.image.registry and pull secrets, and review custom connectors before use.
- Log: keep INFO log level, collect proxy, Kubernetes audit and secrets manager logs into your SIEM.
- Update: apply Airbyte platform and connector updates promptly and report issues through Airbyte's vulnerability disclosure process.
Testing and rollback: trial secrets manager configuration on a fresh test instance, because switching storage on a live instance means recreating connectors. Keep a values.yaml in version control for each change so you can redeploy the previous configuration, and stage proxy and SSO changes with a break glass admin login kept in a vault.
Common misconfigurations
- Port 8000 published to the internet: a test install on a cloud VM becomes the production instance with a public IP. Put it behind a proxy or IAP before connecting production sources.
- Authentication turned off without a proxy: global.auth.enabled set to false to simplify a demo, with nothing else checking identity. Only disable it behind an authenticating proxy.
- Personal API applications in automation: CI jobs use an engineer's client secret, inheriting admin rights and failing when the person leaves.
- Secrets left in the default store: the configuration database and its backups hold every connector credential. Move them to a secrets manager early.
- Over privileged connector accounts: a source connector uses a DBA account because it was quick, so a compromised Airbyte instance becomes write access to the source.
- Unpinned connector images: custom connectors referenced by public image names or mutable tags. Use your registry and fixed tags.
Where identity fits
Airbyte is a credential concentrator: every source and destination credential it holds is a non-human identity with its own owner, scope and rotation needs. Inventory them alongside API applications and the secrets manager identity, and include them in access reviews. The NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments guide covers finding these credentials across environments.
Practitioner checklist
- Confirm the instance is unreachable from the internet and fronted by a TLS proxy, IAP or Session Manager.
- Replace the generated admin password and API credentials; restrict secret read in the Airbyte namespace.
- Keep global.auth.enabled on unless an authenticating proxy covers every request.
- Configure an external secrets manager with workload identity before creating connectors.
- Create a dedicated service account user and application for each automation; vault the client secret.
- Give every source and destination its own least privilege credential with a named owner.
- Mirror images into a private registry and review custom connectors before deployment.
- Assign Reader or Runner by default, split source and destination editing, and keep Admin to a few, where RBAC is available.
- Collect proxy, Kubernetes audit and secrets manager logs and alert on secret reads and new connectors.
Standards and references
- Airbyte: Security
- Airbyte: Authentication
- Airbyte: Secret management
- Airbyte: Role based access control
- Airbyte: Get an API access token
- Airbyte: Using custom connectors
- Airbyte: Custom image registries
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: ETL and ELT Pipeline Security Guide · Secrets Management Guide · Data Security Guide · API Key Management Guide