Kuboard separates platform roles from Kubernetes RBAC

Kuboard is a multi-cluster Kubernetes management platform. It can store cluster connections, users, roles, access keys, and OIDC configuration. The product therefore sits in a high-value position: a compromise can expose both the platform's own administration plane and the Kubernetes credentials behind it. A public Kuboard page is worth reviewing before an attacker uses it as a map.

Measured population

At 2026-11-11 23:49 UTC, count-only ZoomEye queries used sub_type=all, page 1, and page size 1. app="Kuboard" returned 5,514 matches. title="Kuboard" returned 1,114, and http.body="Kuboard" returned 6,947.

The application count is a useful product signal, but it does not establish exposure or authentication state. Kuboard can be installed on a private network, behind an identity-aware proxy, or on a public address. A title match may be a login page, documentation, a status page, or an unrelated mention.

Two authorization planes

Kuboard's current documentation describes platform, cluster, and namespace scopes. It also says the Kuboard scope and the Kubernetes RBAC scope are independent and can be combined. A user may be able to see a cluster object in the Kuboard UI while the cluster API still enforces a separate permission. The reverse can also be true.

This is a common source of false confidence. An administrator may grant a Kuboard role and assume the user's Kubernetes permissions are correct, or grant cluster RBAC and assume the user cannot reach the object through Kuboard. Review both layers. Check the built-in roles, custom roles, group bindings, and the cluster credentials used by the platform.

Kuboard can import a cluster through kubeconfig or an API server address and token. Those credentials are highly sensitive. The platform should not store a cluster-admin kubeconfig when a narrower service identity would work. Limit which platform administrators can add or edit clusters, and record every change to a cluster connection.

Access keys, MFA, and OIDC

Kuboard documents local login, MFA, OIDC, and access keys. Review whether local accounts are still needed after SSO is enabled. Enforce MFA for platform administrators and define a recovery process that does not bypass the audit trail. Rotate access keys and remove keys that belong to departed users or automation with no owner.

If OIDC is configured, validate issuer, client ID, redirect URI, group claims, and the mapping from groups to Kuboard roles. Test a user who belongs to no group and a user who belongs to an administrator group. Confirm that a group claim cannot be influenced by the user in a way that grants a higher role.

Incident review

If a Kuboard deployment is exposed unexpectedly, preserve logs before changing it. Check successful and failed logins, access-key use, cluster imports, role changes, and MCP or API requests. Review the platform cache and the underlying Kubernetes audit log. A recent cluster connection or a new access key is more important than a generic login failure count.

Use the ZoomEye count to find unauthorized public pages, then verify ownership and authentication. Do not attempt to log in to unknown assets. The operational goal is to ensure that every confirmed Kuboard instance has a known owner, a protected ingress, and a reviewed path from platform identity to Kubernetes authority.

References

• Kuboard, Roles and permissions
• Kuboard, Authorization scopes
• Kuboard, Importing a Kubernetes cluster
• ZoomEye query: app="Kuboard"