OpenMetadata catalogs on the internet: 1,246 instances and the lineage they expose
OpenMetadata is a data catalog. It ingests metadata from warehouses, databases, dashboards and pipelines, then presents a searchable view of where data lives, who owns it, and how it moves. It is a map of the data estate, and a map is useful to more than the people who drew it.
Context and method
The query app="OpenMetadata" was run with sub_type=all and a page size of one, returning 1,246 fingerprinted instances. The figure counts recognised deployments. It does not describe their configuration, their connected data sources or their authentication state.
What a catalog contains
A catalog is a metadata store, and metadata describes structure: table and column names, ownership assignments, tags applied for classification, and the joins between systems. Lineage answers the question that is hardest to reconstruct from outside, which is which downstream system consumes which upstream field.
Taken together, the catalog describes the shape of the platform even when it contains no rows of business data. Column names alone often disclose what a system processes, and ownership fields name the people and teams responsible for each asset.
How exposure happens
Data tooling is usually deployed by the team that operates it, often ahead of the security review that would apply to a customer-facing service. The catalog is reached by every data-using team, which encourages broad network access, and a reverse proxy that publishes the application publishes all of it.
Migration is the other common source. A catalog is populated from the previous inventory, and the temporary instance stood up during the transition tends to persist longer than the transition did.
Reviewing the deployment
Establish whether authentication is enforced by the application or delegated to a front-end proxy, and whether the API is protected by the same rules as the interface. The catalog API is often the more valuable target because it returns structured metadata without the page rendering overhead.
Check which connectors are configured and what credentials they hold. A catalog that reaches warehouses and dashboards necessarily stores their connection details. Those credentials should be scoped for read-only metadata access, not for the underlying data.
Practical guidance
Keep the catalog on the internal network and require identity-aware access for remote users. Where an API integration needs to reach it, issue a scoped token rather than reusing an operator account. Review the connector credentials on the same cadence as the rest of the service accounts in the estate, and remove connectors for systems that have been decommissioned.
References
- OpenMetadata documentation.
- OpenMetadata documentation, deployment and connectors.
Top comments (0)