KubeVela provides an application delivery platform with a VelaUX console, local users, SSO options, API accounts, and Kubernetes-backed authorization. A discovered console can expose application definitions, environments, and the identities used to deploy them.
The ZoomEye count-only measurement at 2026-11-11T17:49:01Z returned zero matches for app="KubeVela". A title query at 17:49:03Z returned 159 matches for title="KubeVela". Both used sub_type=all, page 1, and page size 1. The title set is a candidate inventory and does not show whether a console is publicly accessible or which authentication path it uses.
KubeVela's user documentation says VelaUX creates a built-in administrator with full access and recommends using it only for initial configuration before switching to another user or SSO. Local users and API accounts can generate tokens with limited permissions. The platform also integrates authentication and authorization with Kubernetes RBAC and supports definition permission validation.
Separate bootstrap from operations
Record the bootstrap account, current platform roles, SSO provider, and local-user state. Change the initial administrator password through a controlled process and disable unused local accounts after SSO is working. A local account that bypasses the identity provider may remain useful for recovery, but it needs stronger custody and a clear review.
Review API accounts and tokens as machine identities. A token used to create an Application should not also be able to define system-level components, traits, or policies outside its project. Check whether the token's project identity and Kubernetes subject align. The VelaUX documentation describes projects using the identity of the project and the user, which lets operators constrain access through Kubernetes RBAC.
Inventory application authority
List projects, applications, environments, delivery targets, target clusters, and the identities used to dispatch resources. For each, record whether authentication is enabled and whether the controller uses its own privileges or an application authentication mode. Review X-Definition permissions when definition validation is enabled. A user should not be able to choose a restricted component merely because the definition exists in the cluster.
Test a low-privilege account against an application in another project, an API token with a narrow role, and a local account that should be disabled. Do not make a destructive deployment change. Verify that the expected 403 response occurs at the API and that the UI does not silently substitute a more powerful controller identity.
Monitoring and response
Alert on the initial admin account continuing to log in after bootstrap, new local users, API token creation, project role changes, SSO configuration changes, and definition permission changes. Correlate VelaUX activity with Kubernetes audit events for Applications and delivered workloads.
If a console is suspected, preserve the user, token, project, and application records before disabling access. Rotate API tokens and local credentials, review deployments made during the window, and validate the RBAC bindings for the project and target clusters. Remove stale local accounts after the recovery path is tested.
The 159 title matches are candidates for a console and identity review. The meaningful finding is not the count itself. It is whether a reachable console still uses a bootstrap administrator, a broad local account, or an API token that can deploy beyond its project.