Airbyte Enterprise
You set up airbyte enterprise by deploying the self-hosted platform on Kubernetes and linking single sign-on. Next, you assign role-based rules to control who can manage sources, destinations, and data syncs. Most data teams start by giving engineers broad admin roles to build pipelines fast. Broad roles create risk when users can read or alter live production data. How airbyte enterprise manages roles and workspaces The platform separates data work into isolated workspaces for different team
Passwordless Enterprise: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up airbyte enterprise by deploying the self-hosted platform on Kubernetes and linking single sign-on. Next, you assign role-based rules to control who can manage sources, destinations, and data syncs. Most data teams start by giving engineers broad admin roles to build pipelines fast. Broad roles create risk when users can read or alter live production data.
How airbyte enterprise manages roles and workspaces
The platform separates data work into isolated workspaces for different teams or projects. Admins link an identity provider so users log in with their main work accounts. Once logged in, each person gets a specific role at the instance or workspace level.
High-level roles let users manage cluster settings, upgrade connectors, and add new team members. Lower-level roles let users view sync logs, trigger manual runs, or edit source settings. This structure keeps billing and platform tasks separate from daily pipeline work.
To move data, each source and destination needs database keys or service tokens. The platform stores these secret keys in an external secret store that your team manages. When a sync runs, worker pods pull those keys to read and write data.
Why workspace roles are not enough for database security
Workspace roles solve the problem of who can click buttons inside the data tool. They stop unauthorized users from deleting a pipeline or changing a sync schedule. They also give auditors a clear log of who logged into the web interface.
Still, workspace roles do not control what happens inside the database itself. Engineers often need direct access to the source or destination database to fix broken syncs. When a schema changes or a job fails, they run manual queries to check rows.
Native roles decide who logs in, not what individual statements do in flight. If an engineer has a database key, they can run any command that role allows. A wide role lets them drop tables or read raw emails and card numbers.
Passwordless Enterprise: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Securing live database access during pipeline fixes
Data teams need a way to inspect source tables without sharing static database keys. Sharing long-lived passwords in chat or config files breaks audit trails. Everyone uses the same shared role, so database logs cannot show which person ran a query.
A better approach separates pipeline worker keys from human debugging sessions. Automated jobs keep using their strict service accounts to move bulk rows on a schedule. Human engineers log in with their own identity when they need to check a broken table.
During these human sessions, security rules should check every query before it runs. Dangerous commands can require quick peer approval in chat before they reach the database. Also, data masking can rewrite emails, phone numbers, and national IDs in query results.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How does airbyte enterprise handle user logins?
It connects to your identity provider using standard single sign-on protocols. Users log in with their work email, and admins map groups to workspace roles.
Where does the platform store database passwords?
You can link it to an external secret manager hosted in your cloud account. Worker pods fetch the keys at runtime so passwords do not sit in plain text.
Why do engineers still need direct database sessions?
Sync logs show that a job failed, but they rarely show the bad data row. Engineers query the source database to inspect data types, check locks, and test fixes.