oneuptime: Kubernetes AI access test, agent reset and fix approval ignored label and owner scopes on cluster permissions

Summary

A Kubernetes cluster's Test connection (POST /kubernetes-cluster/ai-access/test) runs kubectl version and kubectl auth can-i --list on the cluster through its Kubernetes AI agent or the Runner bound to it, and records the cluster's last verified time. It is meant for people who may edit that cluster, but it only checked whether the caller held a permission to edit clusters anywhere in the project. A permission limited to some labels or to owned clusters, and a block on one of the cluster's labels, were not applied to the cluster being tested, so a member whose edit permission covers only other clusters (for example only clusters labelled Staging) could run the test on any cluster they could view.

The same project-wide check decided related actions. Reset agent on a cluster or on an infrastructure resource (Docker and Podman hosts, Docker Swarm, Proxmox, VMware and Ceph clusters, database servers, hosts) asked for the AI admin permissions and a read of the record, but not for an edit of it. Approving an AI-proposed plan with kubectl commands asked for permission to start runbooks, but not for an edit of each cluster the plan changes. And the AI conversation on an incident or alert offered read-only kubectl and infrastructure commands on every linked cluster and resource with AI investigation on, whoever asked, including people who may not view that cluster or resource.

Impact

An authenticated project member whose permission to edit Kubernetes clusters is limited to other labels or to owned clusters, or blocked for a label the cluster carries, could:

• run the access test on the cluster: learn its Kubernetes version and the RBAC permissions held by its AI agent or Runner credential, use the agent's time, and update the cluster's last verified time;
• if they also hold the AI admin permissions (Project Owner, Project Admin or Edit Auto Remediation Rule), reset the cluster's or a resource's AI agent, which disconnects it until it registers again a few minutes later;
• if they may start runbooks, approve a pending AI-composed kubectl plan for the cluster, so that changes the cluster's own AI settings allow run on a cluster they may not edit.

A responder who could see an incident or alert, but not a cluster or resource linked to it, could have OneUptime AI run read-only kubectl or infrastructure commands on that cluster or resource. Members whose permissions cover every cluster in the project were not affected, and nothing outside the member's own project was reachable.

Patches

Each of these actions now decides the caller's access for that very cluster or resource, as an update of it through the API is decided: labels, owners, blocks, custom roles and read-only credentials included. Test connection, Reset agent and approving a kubectl plan take permission to edit that cluster or resource (Reset agent still also takes the AI admin permissions). The incident's AI conversation offers commands only on the linked clusters and resources the person asking may view.

Fixed in OneUptime 14.0.69. Upgrade to 14.0.69 or later.

Affected versions: >= 14.0.2, <= 14.0.68.

Fix: #4960, merged as 264e1ba13149.

Workarounds

A member with no permission to edit Kubernetes clusters could not run the access test. Until you upgrade, give members whose cluster access is meant to be limited by labels or ownership no permission to edit clusters, keep the AI admin permissions and the permission to start runbooks to people who may edit every cluster, and turn AI investigation off on clusters and resources that some readers of their incidents may not view.