lakeFS adds versioned repository semantics to object storage and exposes a web UI, API, and S3-compatible gateway. Access keys can authenticate users and automation across those interfaces. An exposed lakeFS deployment therefore needs an inventory that connects repository permissions to the object storage credentials underneath.
A count-only ZoomEye query on 2026-11-02 returned 302 assets for app="lakeFS". The query used sub_type=all, page 1, and page size 1. The count identifies matching product assets. It does not show that a repository is readable or that an access key is exposed.
The ZoomEye query is a candidate inventory, not proof of vulnerability. Confirm ownership through DNS, certificate, and deployment records.
Treat credentials as repository identities
lakeFS documentation describes access key pairs used for the web UI, API server, and S3 gateway. In lakeFS Community, the built-in authentication database is present and the initial setup creates an administrator. Enterprise deployments can add OIDC, SAML, external authentication, AWS IAM role authentication, and short-lived tokens.
Inventory users, access keys, groups, and policies by environment. A key used by a data pipeline should have a policy limited to the repositories and actions that pipeline needs. Remove unused keys and rotate keys after a pipeline owner changes. Store secrets in the orchestration platform's secret manager, not in notebook cells or repository configuration.
Review the credential creation path. The API exposes user credential management, and RBAC controls who can create or delete credentials. A user who can create credentials for another user can create a durable path into that identity. Restrict those actions and alert on credential creation outside the approved workflow.
Separate object storage from repository policy
lakeFS repositories sit on top of an object store. The lakeFS service needs storage credentials, and clients need lakeFS credentials. Do not give clients the underlying object store keys when the lakeFS gateway can enforce repository policy. A direct bucket key can bypass lakeFS actions, branches, and audit records.
Review the storage namespace and physical address rules. RBAC documentation discusses permissions that limit where a staging or physical address can point. A broad write path can let an authorized user reference an object outside the intended repository or overwrite a sensitive prefix. Use the narrowest policy that supports the pipeline and test it with a repository task.
For Iceberg or other catalog integrations, check the separate catalog permissions. The lakeFS documentation notes that repository or object permissions alone may not be sufficient for Iceberg RBAC. A user who can read repository objects may still need catalog-specific table permissions. Test the actual catalog operation rather than inferring access from the repository role.
Inventory the public service
For each observed host, record the hostname, certificate, IP address, product evidence, first-seen time, and organization. Determine whether the endpoint is a production lakeFS service, a demo, or a similar page. Check TLS and authentication through authorized observation.
Inspect alternate hostnames and endpoints. A service may expose the web interface on one hostname and the S3 gateway on another. The API server and gateway should share the intended identity and policy, or the separation should be documented. Do not assume a protected UI means the gateway is private.
Log authentication, credential creation, policy changes, repository creation, and data access. Keep logs outside the lakeFS host. Alert on new administrators, new access keys, policy changes that broaden repository access, and requests from unexpected networks.
Test revocation and least privilege
Create a disposable repository and a key limited to a read action. Confirm that the key cannot write or list an unrelated repository. Revoke the key and verify that the API and gateway both reject it. Remove a user from a group and check the effective policy after the next request.
Test a direct object-store credential outside the gateway in a lab and document why it has a different authority. If production clients hold such keys, inventory and restrict them. lakeFS can provide useful repository controls, but those controls do not reach a client that bypasses the lakeFS endpoint.
The 302 ZoomEye matches are a useful inventory lead. The important question for each owned deployment is which lakeFS identity can reach which repository, which storage identity backs the service, and whether any client can bypass the repository layer.