Why OpenMetadata security hardening goes beyond turning on SSO
Turning on single sign-on decides who can log in to OpenMetadata, but it does not decide what the catalog can reach once a user or service is inside. If you are deploying OpenMetadata in your own cloud accounts, data centers or air-gapped network, you will need to show assessors that the catalog cannot become a route into the data sources it describes. That is a question about configuration, credentials and network paths, and it needs its own review before go-live. Start by listing every place the platform connects to a source, every identity that can act on those connections, and every setting you have left at its default.
The catalog is an attractive target because it holds a map of your estate. It stores connection details for each source it ingests from, and the project lists more than 130 connectors covering warehouses, BI tools, pipelines and ML platforms. Ingestion bots authenticate with tokens that often need broad read access to pull schemas, profiles and lineage. The default setup is built for getting started quickly, so the settings that make a trial easy, such as permissive roles, long-lived tokens or open internal routes, are the first ones to review. Check each default against your own security policy before accepting it.
The hardening work covers six areas. Login covers how people authenticate, which means SSO with your identity provider and a decision on whether any local accounts remain. Bot tokens need a named owner, a scope that matches each connector's job and a rotation process. Connector credentials should be managed through your secrets tooling, and you should confirm how the platform stores and displays them. Source network access determines which hosts the ingestion runners can reach, so limit it to the sources each pipeline needs. TLS should protect client sessions, service-to-service traffic and the links to the database and search tier. Least-privilege on sensitive assets means checking which roles can view or edit classifications, policies and tagged columns.
The 2.0 release changes two things you should check before go-live. First, embedding credentials moved into an llmConfiguration block, so any secret stored in an earlier location must be found, moved and removed from old configuration, and you should confirm how your upgrade handled it. Second, MCP is enabled by default. Decide whether it should run at all, and if it does, confirm that the access it exposes follows the same role and token limits as the REST APIs and Python SDK. Record each decision, its owner and the supporting evidence, because these are the items an assessor is likely to ask you to show.
Which OpenMetadata components hold access and secrets
Six components account for most of the access and credential exposure in an OpenMetadata deployment. They are linked because each one authenticates to the next: users sign in to the server, the server reads from its database and search services, and bots, connectors and API clients reach into the catalog and your sources. Map the identity and credential at each point before you set access policies.
Server and authentication
The OpenMetadata server handles every API call, UI session and ingestion request, so it is the main control point. Its authentication configuration decides who can sign in and which identity provider issues tokens. OpenMetadata documents SSO with several providers and does not allow SSO and basic authentication to run at the same time. Confirm the exact auth configuration keys for your version in the security docs, check that basic authentication is off, and record where the OIDC client secret is stored.
Database and search services
The MySQL or PostgreSQL database holds the catalog's metadata and configuration. Elasticsearch or OpenSearch holds indexed copies of that metadata so users can search it. The server connects to both with its own credentials, so both sit inside the platform's trust boundary. Confirm which credentials the server uses for each service, restrict network access to those ports, and check who can query the search cluster directly.
Ingestion workflows and bot identities
Ingestion workflows run on a schedule and use bot identities to write metadata into the catalog. The bot's token and role determine which entities the workflow can create or change. Confirm in the security docs how bot tokens are generated, rotated and scoped in your version, and keep bot roles separate from human administrator accounts. Review which bots can edit sensitive assets before each upgrade, since upgrade notes can change how identities are configured.
Connector connection settings
Each connector stores the host, account and credentials it needs to read a warehouse, BI tool or pipeline platform. These settings are the main path from the catalog into your source systems, so a leaked connector credential can expose data beyond what the catalog displays. Confirm where each connector keeps its secret, whether your version supports an external secret manager for it, and use read-only service accounts limited to the schemas the catalog needs.
REST, Python, TypeScript and Java access
OpenMetadata exposes REST APIs and provides a Python SDK, TypeScript packages and Java libraries. Each path authenticates with a token tied to a user or bot, so every script, notebook and service that uses these libraries carries that access. Inventory the scripts and applications that call the API, keep tokens out of source control, and confirm the token lifetime and revocation options for your version in the security docs.
MCP server access
OpenMetadata 2.0 enables MCP by default, which lets AI clients query catalog metadata through the platform. Treat MCP as a separate access path from the UI and the SDKs. Confirm which tools it exposes, which identity it runs under, and whether it can write as well as read. If your team does not need MCP, confirm how to disable it in your version before exposing the server to AI tooling.
Which authentication and secrets model fits your identity setup
This table compares the main ways to authenticate people and hold connector credentials in OpenMetadata, from SSO through an existing OIDC provider to brokered identity and external secrets storage. Read each row for when the option fits and what it asks your team to run afterward. The main takeaway is that SSO and basic authentication cannot run together, so break-glass planning must be settled before you switch basic authentication off.
| Option | When it fits | Operational cost | What to confirm |
|---|---|---|---|
| SSO with an existing OIDC provider (Okta, Azure, Google, Keycloak, Auth0, Amazon Cognito, OneLogin) | You already run one of these identity providers and want staff to sign in with existing accounts and group membership. | Client registration, redirect URI maintenance, and periodic client secret rotation in the identity provider and the OpenMetadata configuration. | Confirm the exact OIDC settings and claim mapping your provider supports against the OpenMetadata security documentation. |
| SSO with a custom OIDC provider | Your corporate identity platform is OIDC-compliant but not on the documented list of named providers. | Same as named providers, plus more validation work on claims, token lifetimes and discovery endpoints. | Confirm with your identity team that the provider's discovery document, token claims and signing keys meet OpenMetadata's requirements. |
| Brokered identity layer in front of OpenMetadata | Several applications share one login policy, or upstream sources such as SAML directories must feed a single OIDC front end. | An additional component to patch, monitor and include in incident response, and a second place where session and group logic can break. | Confirm that group and role claims pass through the broker unchanged and that the broker supports the OIDC flow OpenMetadata uses. |
| Basic authentication for local accounts | A short proof of concept or a small test instance where no identity provider is available yet. | Password policy, account lifecycle and offboarding are manual, so access reviews must cover these accounts separately. | Plan the switch-off date. Basic authentication and SSO are not supported together, so the cutover is a single planned change. |
| Break-glass administrator access | Any production instance, because a failed identity provider or misconfigured OIDC setting can lock every user out. | A documented emergency path, stored credentials under dual control, and a test of the path before cutover. | Confirm with the OpenMetadata security documentation how an administrator can recover access if SSO fails, and who approves its use. |
| Connector credentials held in the catalog | A small estate with few sources and a team that accepts stored credentials inside the metadata platform. | Credentials must be rotated in OpenMetadata each time the source password changes, and access to the catalog becomes access to source systems. | Ask who can view or edit connection configurations and whether your assessor will accept this storage for each source. |
| Connector credentials in an external secrets manager | Your security policy requires centralized secret storage, audit logging and automated rotation for database and cloud credentials. | Integration work per secrets backend, reference configuration in each connector, and joint testing after every rotation. | Confirm which secrets managers your OpenMetadata version supports for connector references and how ingestion pipelines authenticate to them. |
| Bot tokens for ingestion and API access | Scheduled ingestion, automation scripts and the Python SDK need non-human identities with limited roles. | Token expiry, rotation schedules and owner assignment for each bot account, recorded in your access review. | Confirm the token lifetime options and role scope for bots in your OpenMetadata release before you set a rotation policy. |
How to harden OpenMetadata in sequence
This sequence moves an OpenMetadata deployment from default access to a controlled state: verified release and prerequisites, SSO-only sign-in, scoped bot identities, secrets kept out of configuration, restricted network paths, TLS on every hop, least-privilege access to sensitive assets, and a reviewed MCP and 2.0 LLM configuration. Each step ends with a check that confirms it is closed.
Confirm release and prerequisites first
Your platform team confirms the OpenMetadata version, then checks the host against the documented bare metal prerequisites: Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. If you are on 2.0, read the breaking changes before you touch configuration, including the embedding credential move, the new Databricks auth format, the Python 3.12 rebuild of custom ingestion images, and the Great Expectations 1.3 migration. Close the step when the running version and every component version match your written baseline, and the release notes have been reviewed against your connectors and custom images. Confirm the sizing against the documented minimums and your expected load with the vendor or your own environment team.
Enable SSO and disable basic authentication
Your identity team connects OpenMetadata to the chosen provider, such as Okta, Azure, Google, Keycloak or a custom OIDC provider, and tests sign-in with a small pilot group. OpenMetadata does not run SSO and basic authentication together, so basic authentication is switched off only after SSO works end to end. Before cutover, define a break-glass path that your team has rehearsed in a non-production copy, and confirm with the vendor documentation how an administrator regains access if the identity provider is unavailable. Close the step when pilot users sign in through SSO, the rehearsed recovery procedure succeeds, and basic login is confirmed as disabled.
Scope bot and ingestion identities
Platform engineering creates a dedicated bot identity for each ingestion pipeline or connector group, rather than reusing a human account or one shared token. Each bot receives only the roles its connectors need to read metadata and write the results back. Tokens get a named owner, a documented rotation procedure and an expiry decision made in advance. Close the step when every scheduled ingestion run authenticates as its own bot, a test run succeeds, and a deliberate attempt to perform an action outside that bot's role is denied and logged.
Move connector credentials out of configuration
Your engineers find every place a source password, service key or bot token is written in plain text: ingestion workflow files, container environment definitions, Helm values and version control history. Each credential moves into the secret store your deployment already uses, and the workflow references the secret instead of holding the value. Confirm with the vendor documentation which secret reference formats your version supports. Close the step when a repository and configuration search returns no live credentials, the old copies are revoked or rotated, and a test ingestion run pulls its secrets from the store.
Restrict database, search and source paths
Network engineers write an allow list for each traffic path: OpenMetadata servers to the database, OpenMetadata servers to the search service, ingestion runners to their source systems, and users to the web endpoint. Everything else is denied by default, including direct access from user networks to the database and search tiers. Confirm each allowed path against the source systems and the connector list before you apply it. Close the step when connectivity tests from each network segment succeed only on the approved paths, and a scan from outside the allowed segments finds no open database or search ports.
Enforce TLS on every hop
Your security engineers enable TLS on each connection: browser to the OpenMetadata server, server to the database, server to Elasticsearch or OpenSearch, ingestion runners to sources, and the SSO callback. Certificates come from your internal or public certificate authority, and clients validate them instead of accepting any certificate. Plaintext listeners are removed once the encrypted path works. Close the step when every hop negotiates TLS with a validated certificate, a port scan shows no plaintext listener on the service ports, and the SSO callback completes over HTTPS.
Set least-privilege policies on sensitive assets
Data owners and stewards define which domains, teams and roles can view, edit and classify assets, with sensitive tables and columns tagged through classifications and glossary terms. Access is granted through roles and teams rather than individual exceptions, and each exception has a named approver. Write the access matrix before configuring it, then test it with a user from each role. Close the step when test accounts for each role see and change exactly the assets the matrix allows, and the matrix is stored with the change record for your compliance team.
Review MCP and the 2.0 LLM configuration
In 2.0, MCP is enabled by default, so your team decides whether it stays on, and if it stays on, which clients may reach it and under which identities. Embedding credentials move into the llmConfiguration block, so the team removes the old settings and confirms the new block loads during upgrade. Check that no API key appears in plain configuration. Close the step when MCP access is limited to approved clients and identities, the llmConfiguration block loads without errors in a test environment, and the old credential locations are empty.
How least-privilege policies protect sensitive assets
A catalog holds descriptions of your most sensitive data, so its permissions matter as much as the warehouse behind it. The cards below cover who can change governed metadata, who can see sample data, which bots can write, and how credentials and certificates are stored and rotated.
Mapping identity groups to ownership
Map teams and roles from your identity provider groups to OpenMetadata teams and ownership, so access follows the people accountable for each domain rather than individual accounts. Check that a user removed from an identity group loses catalog rights at the next sign-in, and confirm how OpenMetadata applies group membership changes in your SSO setup. Test with accounts from at least two domains to confirm that ownership does not leak across them.
Restricting edits to governed assets
Glossaries, classifications and domains define how the rest of the catalog is read, so edit rights on them should sit with a small set of stewards. Review which roles can create, rename or delete glossary terms, classification tags and domains, and confirm that ordinary data consumers can only suggest changes. Record who approved each role assignment so the change history can be audited later.
Limiting access to profiles and sample data
Table profiles, column statistics and sample rows can expose personal or regulated values even when the schema itself is harmless. Decide which roles may view sample data for tables tagged as sensitive, and test that a consumer without that role sees the schema and classification but not the rows. Confirm how the profiler and sampling settings interact with these view permissions in the version you run.
Controlling which bots can write metadata
Ingestion, lineage and quality bots write metadata on behalf of pipelines, and a bot with broad write access can change owners, tags or descriptions across the whole catalog. Give each connector or pipeline its own bot with write rights limited to the services it actually ingests. Review bot roles after every new connector is onboarded, because the default scope often grows with the catalog.
Testing over-broad bot roles
An over-broad bot role is one that can edit entities outside its connector's scope, such as glossary terms or another team's tables. To test it, run each bot's token against assets it should not touch and confirm that the API rejects the write and that the attempt appears in the audit trail. Repeat the test after each upgrade, since role defaults can change between releases.
Storing connector credentials securely
Connector credentials for warehouses, BI tools and pipelines are the keys to your data sources, so they should never sit in plain configuration files or shared notes. Store them in your organization's secrets manager or Kubernetes secrets, inject them at runtime, and restrict who can read them. Confirm which secret storage options your OpenMetadata version supports and plan rotation for each connector.
Managing API tokens for programmatic clients
The REST APIs, Python SDK and other client libraries authenticate with tokens, and a leaked token gives the same rights as the account it belongs to. Issue one token per client or pipeline, keep each token's scope narrow, and document an owner and expiry date for every token. Confirm how revocation works in your version and test that a revoked token is refused immediately.
Handling certificates for TLS
TLS protects logins, API traffic and connections to the database and search services behind OpenMetadata. Keep certificates in a managed store, track their expiry dates, and confirm that every internal hop validates the certificate chain rather than skipping verification. Plan a renewal and reload procedure before the first certificate expires, and test it in a non-production environment.
How to test that each control holds and fails safely
Each OpenMetadata hardening control needs two tests before go-live: a negative test that must fail and a positive test that must succeed. Run both against the deployed version, record the results with the date and build, and keep them with the change record. A control that has never been seen to block something has not been verified. Test one control at a time so that a failure points to a single cause.
Start with identity. After SSO is enforced, attempt a login with a local basic credential and confirm it is rejected. OpenMetadata does not run SSO and basic authentication together, so a surviving basic login means the configuration is wrong. Next, disable a test user in the identity provider and confirm that the user's browser session and any personal access tokens stop working in OpenMetadata. For bot tokens, call the REST API with a token limited to its intended scope, then attempt a write outside that scope and confirm it returns an authorization error. In OpenMetadata 2.0, MCP is enabled by default, so confirm whether MCP endpoints honor the same bot restrictions in your version.
For connectors, run each ingestion workflow from its actual runtime host and attempt connections to a source outside the allowed path. The attempt should time out or be refused at the network layer, not succeed through a forgotten route. Then check TLS on every hop: browser to the OpenMetadata server, server to the database, server to Elasticsearch or OpenSearch, and connector to each source. Inspect certificate chains, expiry dates and negotiated protocol versions. Compare the results with the minimum protocol version your security policy sets, and confirm the cipher and version settings for each component in its own documentation.
Sensitive assets need tests run from accounts in each role, not only from an administrator account. Sign in as a user without access to a classified table and confirm that sample data and profiling values are hidden or absent in the UI and API responses. Check whether OpenMetadata 2.0 Dynamic Sampling, now the profiler default, stores or displays sample rows for tables you have marked sensitive. If it does, adjust the profiler configuration before ingestion runs. Log the exact responses for each role so auditors can see the expected denial.
A failed control usually appears as authorization errors (HTTP 401 or 403) in the server or proxy logs, TLS handshake errors in the connector logs, or ingestion runs that stop with connection timeouts. Confirm the exact log format for your version before relying on it. If a control blocks ingestion, roll back only that control: restore the previous network rule, token scope or TLS setting from a saved copy, then rerun the failing workflow. Take a configuration backup before each change, and set a stop point so a change that cannot be reverted cleanly is escalated instead of forced.
What drives hardening effort and how to keep it down
This table lists the factors that expand OpenMetadata hardening work and the steps that keep each one contained. Read each row as a lever: the driver explains why effort grows, and the right column shows what to standardize or decide early. The main takeaway is that most effort comes from variety (connectors, bots, environments and groups), so reducing variety before build starts usually matters more than tuning any single control.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of connectors and source systems | Each connector needs its own credential scope, network path, ingestion schedule and test of least privilege. OpenMetadata lists more than 130 connectors, so the choice of which sources to onboard sets the work. | Onboard only sources with a named owner and a use case. Defer low-value connectors and document the network path for each one before enabling it. |
| Number of ingestion bots and secrets | Every bot holds a token and often a source credential. Bots that differ for no reason multiply rotation, storage and review work. | Standardize one bot pattern per source type. Store credentials in your existing secrets manager and map rotation to a single runbook. |
| Identity provider complexity and group modeling | SSO setup depends on how many providers, claim formats and group structures you bring in. Teams without modeled groups must create roles and ownership mappings by hand. | Reuse the identity provider already governing your other internal apps. Model teams and roles in that provider first, then map them to OpenMetadata teams and roles once. |
| Deployment target (Kubernetes or bare metal) | Kubernetes deployments need cluster-level network policy, secret injection and image provenance controls. Bare metal needs OS hardening, service accounts and manual patch tracking for Java 21, the database and search services. | Choose the target that matches your existing platform controls, not a new one. Reuse your cluster baseline or server build standard instead of hardening the application stack from scratch. |
| Number of environments | Each environment repeats SSO configuration, secrets, TLS certificates, network rules and evidence collection. Drift between environments is a common source of rework. | Keep one tested configuration as code and vary only environment values such as hostnames and secret references. Promote changes through the same pipeline. |
| Sensitivity of assets and classifications | Assets tagged as sensitive require tighter policies, reviewed ownership and restricted access to sample data. Each classification scheme adds policy rules to define and test. | Limit the first hardening pass to a short list of sensitive domains. Use a small, agreed classification set and apply least-privilege policies at the domain level where possible. |
| Compliance evidence required | Assessors ask for documented access reviews, configuration baselines, change records and logs. Evidence that must be produced manually adds recurring effort on every review cycle. | Confirm the control set and evidence format with your assessor before build. Generate configuration exports and access lists automatically and store them in your existing evidence repository. |
| Upgrade cadence and breaking changes | OpenMetadata 2.0 introduced breaking changes to credentials, Databricks authentication and custom ingestion images, so each upgrade may reopen security configuration. Frequent patch releases increase how often this happens. | Record which security settings depend on specific versions. Test upgrades in a non-production environment and re-run the hardening checks after each release. |
How hardening differs on Kubernetes and bare metal
On Kubernetes, much of the hardening sits in the cluster: the ingress or load balancer handles TLS, the cluster's secret integration delivers credentials, and network policies control which pods can reach the database and search services. The same OpenMetadata controls apply on AWS EKS, Azure AKS, Google GKE and on-premises clusters, but each platform handles load balancers, certificates and identity differently, so confirm those details against the provider's documentation before design sign-off.
- TLS termination: Usually at an ingress controller or cloud load balancer in front of the OpenMetadata server. Decide whether traffic is re-encrypted to the pod and confirm how connections to the database and search service are encrypted inside the cluster.
- Secret injection: Database passwords, bot tokens and connector credentials should come from a secrets manager and reach pods through the cluster's secret integration, not from plain values in manifests or chart values files.
- Network isolation: Apply network policies so that only the OpenMetadata server and ingestion workloads can reach the database and search pods. Confirm that your cluster's network plugin enforces policies before relying on them.
- Certificates and credentials on upgrade: Rotating the ingress certificate, secrets and database passwords happens through rolling restarts. Test each rotation in a staging cluster, because pods often read secrets only at startup.
- Managed services: If the database or search service is a managed offering, the provider controls patching and some TLS settings, so your review shifts to its configuration, access policies and backup settings.
Confirm that every path into the cluster, including the ingress, ingestion pods and the Kubernetes API, has a documented control and a named owner.
On bare metal, your team owns every layer the cluster would otherwise provide: the operating system, the Java runtime, the database, the search service and the host firewall. OpenMetadata's bare metal documentation lists Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x as prerequisites, so each of those components needs its own patch, credential and certificate process.
- TLS termination: Typically handled by a reverse proxy or load balancer on the network in front of the server, with certificate files managed on the host. Decide whether internal connections to the database and search service also use TLS.
- Secret handling: Keep credentials out of shell history, process arguments and world-readable configuration files. Restrict file permissions to the service account, or load secrets from an external manager at service start.
- Host firewalls: Limit the database and search service ports to the OpenMetadata host or its subnet. Confirm that each service binds to a private interface and not to all addresses.
- Certificates and credentials on upgrade: Replacing certificates or passwords means editing files on each host and restarting services in the right order. Check the release notes for Java, database and search version requirements before each restart.
- Host maintenance: Operating system, JVM and database patching falls to your operations team, so add these to the maintenance calendar with the OpenMetadata upgrade window.
Confirm each host's listening addresses, firewall rules and file permissions in a written runbook before go-live.
OpenMetadata documents Docker for local trials, and that is where it fits in this comparison. A trial environment is useful for testing connectors, the interface and the API, but it is not a hardened deployment, and the controls described for Kubernetes and bare metal do not come with it by default. Treat any trial as disposable and keep real source credentials and production metadata out of it.
- TLS: Local trials typically run without the certificate setup a production deployment needs. Do not place trial endpoints on a shared network.
- Secrets: Sample configuration files often contain placeholder or default values. Replace them before any real connector is added, and never reuse trial values in a production environment.
- Network exposure: Confirm which ports the containers publish to the host and to the network. Limit them to the local machine during evaluation.
- Data retention: Container volumes hold metadata and indexes. Delete them when the trial ends, and record what was loaded.
- Migration path: Moving a trial to production means redoing the design on Kubernetes or bare metal, including secrets, certificates and network isolation, rather than copying the compose configuration forward.
Before any trial touches production data, complete the Kubernetes or bare metal checklist for the environment you will run.
What to monitor, rotate and document after hardening
Hardening an OpenMetadata installation is only as useful as the checks that run after go-live. Start with authentication. Review failed sign-in events at the identity provider and in OpenMetadata server logs, and separate expected noise, such as expired sessions, from patterns that suggest password spraying or misconfigured clients. Bot tokens need their own watch list. Ingestion bots should authenticate only from the runners that schedule them and only during expected windows, so use of a bot token from an unfamiliar address or a person's workstation is a finding to investigate. Confirm with your deployment team which log fields are emitted, where they are stored and how long your retention policy keeps them.
Rotation is where most teams drift from their own standard. Connector credentials for warehouses, BI tools and pipeline services, along with the bot tokens that authenticate ingestion, should follow a written schedule set by your security policy. Treat each rotation as a runbook: create the new credential at the source, update the secret store, change the connector configuration, run a test ingestion, then revoke the old credential. Ask the vendor or your own testing whether regenerating a bot token interrupts scheduled pipelines, and build the window for that into the runbook before the first rotation, not during an incident.
Role assignments change faster than most catalog configurations. When someone moves teams, their OpenMetadata roles, team membership and domain ownership should be reviewed the same day their directory group changes. Focus the review on sensitive assets, where a former team member who still holds edit or policy rights creates the most exposure. Compare the current role list against domain ownership and the glossary owners named for each area, then record what was removed or kept and why. Review cadence belongs in your access policy, and the review itself should be a recurring calendar item with an owner.
Every maintenance release needs a short re-test. OpenMetadata 2.0.0 was released on August 24, 2026, and maintenance releases 2.0.1 to 2.0.5 have followed about every one to two weeks, so the test cycle recurs far more often than a typical annual assessment. After each release, repeat the checks that matter most to your hardening: SSO-only sign-in, token scopes for bots, TLS settings on the server and search endpoints, network paths from ingestion runners to sources, and a sample of connector test runs. Keep the test scripts under version control so the effort per cycle stays predictable. Ask any implementation partner to price these re-tests as a recurring line item, not a one-time cost.
The configuration itself is evidence. Keep a dated baseline of authentication settings, role and policy exports, network rules, TLS configuration, secret locations (not secret values), rotation records, access review sign-offs, log samples and post-release test results. Internal audit and external assessors will ask how a control works and how you know it still works, so store change records next to each export. DeployOpen prepares these controls and evidence as part of hardening and ongoing support, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so confirm early which evidence format and retention period your assessor expects.
What buyers and engineers ask before hardening OpenMetadata
How much effort does OpenMetadata security hardening take?
Effort depends on how many sources, identity providers and sensitive assets are in scope. The main drivers are the deployment target (Kubernetes or bare metal), the number of connectors that need credentials and network paths, how many SSO and bot-token integrations must be configured, and how far least-privilege policies must reach into sensitive assets. TLS configuration, secrets handling and restore testing add work each time they are included. Ask for the effort broken down by workstream in your quote, and confirm your connector count and deployment target before comparing offers. DeployOpen sets effort from the written scope, so a fixed view of the work follows from that document.
Can our own team harden OpenMetadata without outside help?
Yes, a capable platform team can do much of this in-house if it has the skills to run the stack. Hardening touches Java 21 for the server, MySQL 8.0.42 or later or PostgreSQL 15 or later for the database, and Elasticsearch 9.x or OpenSearch 3.x for search, plus identity, network and secrets tooling. OpenMetadata is released under the Apache License 2.0 and its security documentation is public, so the work is learnable. The honest questions are whether you have people who can test SSO recovery, verify how connector credentials are handled, and rebuild ingestion images after upgrades, and who will keep those controls current afterward. An outside partner is a good fit when those skills or the time are missing.
What does hardening OpenMetadata need from our identity, network and data teams?
Hardening needs named people from three groups before work starts. Identity administrators must provide an OIDC or SAML application for OpenMetadata, agree on group-to-role mapping, and confirm how break-glass accounts are protected. The network team must confirm which subnets and ports reach the server, database, search cluster and each source system, and approve firewall or security group changes. Data owners must classify sensitive assets and confirm which teams should see them, because least-privilege policies depend on that decision. Platform engineering should provide change windows, a test environment and access to the secret store. Ask for these inputs to be listed in the written scope so each team knows what it owes and when.
How long does it take to scope an OpenMetadata hardening engagement?
Scoping time follows from the written scope, so no duration can be stated in advance. Scope is set by the deployment target, the number of connectors and sources, the identity providers in use, the sensitive asset classes and any upgrade planned in the same window. DeployOpen engagements are generally fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. To speed scoping, prepare an inventory covering your OpenMetadata version, hosting model, each connector and its credential type, the identity provider, network paths and the owners of sensitive data. Gaps in the inventory delay agreement on scope, so confirm each item internally first. Ask for the scoping steps and decision points to be included in the proposal.
Can we enforce SSO for OpenMetadata without locking out admins?
Yes, if you plan the cutover and the recovery path before switching. OpenMetadata does not support multiple authentication mechanisms at once, such as combining SSO with basic authentication, so a local password login cannot run alongside SSO as a fallback. Admin recovery therefore needs its own documented plan. Confirm with the security documentation for your version how administrator access works in your deployment, then test the full flow with named admin accounts in your identity provider in a non-production environment first. Confirm who can restore access if the identity provider is unavailable, and write those steps down. Also confirm that bot tokens and ingestion credentials still work after the switch, since they do not follow the same login path as people.
Does upgrading to OpenMetadata 2.0 change the security configuration?
Yes, several 2.0 changes touch credentials and configuration, so review them before upgrading. OpenMetadata 2.0.0 was released on August 24, 2026. Its breaking changes include moving embedding credentials into an llmConfiguration block, a new Databricks auth format, and rebuilding custom ingestion images for Python 3.12. Great Expectations must be migrated to 1.3 before the upgrade. The release also enables MCP by default, so review that interface as part of your exposure assessment. Confirm each change against the 2.0 release notes and your own configuration, then reapply and retest hardening settings after the upgrade. Do not assume existing settings carried over unchanged.
Do we need Collate's commercial edition to harden OpenMetadata?
Not necessarily, but confirm it against the features your hardening plan depends on. OpenMetadata is released under the Apache License 2.0 and is maintained by Collate, which also offers commercial enterprise capabilities and premium support. Hardening work that relies only on the open-source build can proceed on that basis. If a planned control depends on a capability you believe sits in the commercial offering, check that with Collate before finalizing the design, because a control built on an unavailable feature will need rework. Ask your implementation partner to map each planned control to the edition that provides it. DeployOpen implements the open-source platform inside your own infrastructure and is not a Collate partner.
Will DeployOpen certify our OpenMetadata deployment for compliance?
No. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. DeployOpen can prepare the systems, controls and evidence that an assessor reviews, such as SSO configuration records, least-privilege policy exports, connector credential inventories, TLS settings and backup restore records. Ask your assessor which evidence formats and control references they expect before work starts, so evidence is collected once rather than repeatedly. Hardening reduces risk but does not by itself make a deployment compliant with any framework. Confirm the scope of your assessment with your auditor before deciding what evidence to prepare.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For OpenMetadata security hardening, the work starts with a written scope that defines which authentication, credential, network and access controls are changed, and it ends with documented controls the client's team can run.
How we scope
- Engagements are fixed-scope, with the hardening areas, deliverables and timeline agreed in writing before work starts.
- The written scope lists the identity provider, connectors, source networks and sensitive assets that are in and out of the hardening work.
- Scope records which OpenMetadata deployment target applies, such as Kubernetes or bare metal, since controls differ by target.
How we build
- We disable basic authentication and configure SSO against the client's provider, since OpenMetadata does not run multiple authentication mechanisms at once.
- We set up bot token handling and connector credentials in the client's secrets store, then verify that ingestion runs without embedded plaintext secrets.
- We configure TLS, restrict network paths from the ingestion layer to each source, and apply least-privilege policies on sensitive tables and domains, then test each control.
How we hand over
- Handover includes written documentation of every configured control, its owner and the steps to verify it after changes.
- The client's team receives a test record showing which hardening checks passed, failed or were accepted as exceptions.
- Runbooks cover rotating bot tokens and connector credentials, and confirm what to review before any OpenMetadata upgrade.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial hardening work is handed over.
- Support can cover re-validating controls after OpenMetadata patch releases, since the 2.0 line ships maintenance updates regularly.
- Clients should confirm in their quote who reviews configuration drift and who approves changes to access policies.
