Sensu Go inventory starts with namespaces and role bindings
Sensu Go is an event monitoring and observability platform. It receives events from agents, evaluates checks and filters, and sends notifications through handlers. The web UI, API, and sensuctl all interact with the same resource model. Users can create namespaces, checks, handlers, assets, and role bindings. A public Sensu deployment can expose both the monitoring console and the API that changes how events are processed.
A count-only ZoomEye probe on 15 November 2026 used sub_type=all, page 1, and page size 1. app="Sensu Go" returned 0. title="Sensu" returned 1,148. http.body="Sensu Go" returned 46. The full product body marker is small and likely closer to the product than the broad title count, but neither is a confirmed deployment count. A title can be a marketing page or an unrelated project, and a body match can be a documentation page.
The Sensu control-access documentation says the web UI, API, and sensuctl require username and password authentication, with optional LDAP, Active Directory, or OIDC providers. Authorization is implemented with RBAC. Roles define permissions on resource types. Role bindings assign roles to users or groups within a namespace. Cluster roles and cluster role bindings extend permissions across namespaces.
The namespace is therefore an important inventory dimension. A user who can read checks in one namespace may not be able to read handlers in another. A role binding that looks harmless in isolation can grant broad access when it is attached to a group with many members. Inventory the users, groups, roles, bindings, and namespaces together. Review cluster-wide bindings more frequently than namespace bindings.
API keys have their own lifecycle. Sensu documents bearer API keys for authentication, with the note that API keys are not supported for external authentication providers such as LDAP and OIDC. A persistent UUID key can outlive the user session that created it. Record the owner, creation date, last use, and the resources it can reach. Revoke keys that belong to retired automation or people who have changed roles.
The web UI obtains access and refresh tokens through the /auth API. A public UI should use TLS and a strong session policy. The API should not be reachable from a broader network than the UI unless an automation use case requires it. If the API is public, require authentication on every route and test that an unauthenticated request cannot list namespaces, checks, or events.
Handlers can carry credentials for email, chat, incident-management systems, or other notification services. A user who can edit a handler may be able to change where events go or insert a secret into the handler configuration. The RBAC review should include handler resources and secret access. The same applies to assets, which may contain executable artifacts or download URLs used by agents.
The query evidence should stay separate from the policy conclusion. The 46 body matches are a useful exact marker for owned-domain checks, while the 1,148 title matches need contextual verification. For each owned host, confirm the Sensu API and UI, the authentication provider, and the namespace mapping. Do not use an unauthenticated API route to enumerate resources on a host that you do not own.
The final decision should answer who can see an event, who can change a handler, and which API identity can act across namespaces. Sensu's RBAC model provides the building blocks. The operator has to keep the bindings, API keys, and namespace scope aligned as the team and automation change.
Top comments (0)