You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 83e864c
Browse filesBrowse the repository at this point in the historyBrowse files
Rename the Cloud AI group to radar:ai:reader before 1.16.0 (#1973)
## Why
The group Radar Cloud's person-less AI runs read as was `radar:ai`. A
write-capable AI identity will need its own opt-in group one day; with
`radar:ai` as the reader, that second group (e.g. `radar:ai:operator`)
would sit awkwardly beside it. Naming the reader `radar:ai:reader` puts
the read-only contract in the name and leaves a clean sibling for later.
`radar:ai` hasn't been released (latest tag v1.15.0), so this is a
straight rename with no compatibility code. It has to land before
v1.16.0 is tagged.
## What
- The chart binds `radar:ai:reader` (was `radar:ai`) in
`cloud-rbac-ai.yaml` and the cluster-read and integration-read add-ons.
Binding names and `cloud.aiRbac` are unchanged.
- Chart README, `values.yaml` comments and `docs/authentication.md` name
the group, state that it is permanently read-only, and say a future
write-capable AI gets its own opt-in group.
- The identity filter's comment mentions the AI username
`radar:ai:<org>`; a test checks `radar:ai:reader` is accepted in Cloud
mode.
- Chart unit tests, `scripts/test-chart.sh` and the integration-read Go
test expect the new group.
`radar:system` is unchanged.
## Tests
- `scripts/test-chart.sh` and `helm unittest`; the 2 `service_test.yaml`
failures also fail on `main` locally, while CI's Helm chart job passes.
- `go build ./...`, the `internal/k8s`, `internal/helm` and
`internal/mcp` suites, and `pkg/auth` (separate module).
- Rendered with `cloud.enabled=true`: every AI binding names
`radar:ai:reader`.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> This changes the Kubernetes group name for automatic Diagnose RBAC;
clusters upgrading need the chart (and Cloud hub) aligned or automatic
Diagnose loses effective permissions until bindings are updated.
>
> **Overview**
> Renames the Radar Cloud **automatic Diagnose** Kubernetes RBAC group
from `radar:ai` to **`radar:ai:reader`**, and documents that those runs
impersonate username **`radar:ai:<org>`** with that group only. Chart
default bindings (`cloud.aiRbac`, role names) are unchanged; only the
**Group** subject in the AI read, cluster-read, and integration-read
templates is updated, including the integration-read template’s special
case for the `ai` tier.
>
> Docs (`README`, `values.yaml`, `authentication.md`) now state the
reader group stays **read-only** and that a future write-capable AI
would use a separate group (e.g. `radar:ai:operator`). **`pkg/auth`**
adds a Cloud-mode test that **`radar:ai:<org>`** with
**`radar:ai:reader`** is allowed; Helm unit tests,
`scripts/test-chart.sh`, and the integration-read Go test expect the new
group name.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
5f2587d. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
Copy file name to clipboardExpand all lines: docs/authentication.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -233,7 +233,7 @@ Under cloud-mode (`RADAR_CLOUD_MODE=true`, set automatically by the chart when `
233
233
- Ships three default ClusterRoleBindings mapping Cloud's `radar:owner` / `radar:member` / `radar:viewer` groups to the standard K8s `admin` / `edit` / `view` ClusterRoles. Configurable via `cloud.defaultRbac.*` in `values.yaml`.
234
234
- Adds a **cluster-read add-on** (`cloud.defaultRbac.clusterScopedRead.{viewer,member,owner}`, each default on) granting `get/list/watch` on infrastructure the built-in `view`/`edit`/`admin` roles exclude — Nodes, PersistentVolumes, StorageClasses, IngressClasses, PriorityClasses, RuntimeClasses, ClusterTrustBundles, CRDs, and admission webhook configurations — plus list-only Upgrade impact evidence for CSIDrivers, CSIStorageCapacities, legacy PodSecurityPolicies, and API flow-control configuration. When the matching collection is enabled, it also grants APIServices, PrometheusRules, Karpenter kinds, and node metrics. It does not grant Secrets, RBAC objects, API-server metrics, or kubelet proxy access. It's an independent axis per tier: set a tier `false` to make it namespaced-only (e.g. `clusterScopedRead.viewer: false`). Owner node cordon/drain is a separate cluster-scoped *write*, off by default (`cloud.defaultRbac.nodeOps`).
235
235
- Creates the default read grant for `radar:system`, Radar Cloud's alerts worker and timeline puller: a chart-owned role aggregated to match `view`, the cluster-read and integration-read add-ons, and cluster-wide Secret read. Helm release alerts and Secret changes in the timeline need Secret read; Helm stores releases as Secrets. No writes. Controlled by `cloud.systemRbac` (default `true`).
236
-
- Creates the default read grant for automatic (alert-triggered) Diagnose runs, which read as `radar:ai` only: a chart-owned role aggregated to match `view` plus the cluster-read and integration-read add-ons. No Kubernetes Secret permission or writes with the standard `view` role (the aggregated role also inherits anything your cluster adds to `view`); pod logs and ConfigMaps are readable and may contain sensitive data. Keep `radar:ai` permanently read-only; a future write-capable feature needs its own group. Controlled by `cloud.aiRbac` (default `true`). Manual Diagnose turns read as the person who started them, with that person's identity and groups forwarded by Radar Cloud; `radar:ai` is not involved. MCP clients also read with the user's own permissions.
236
+
- Creates the default read grant for automatic (alert-triggered) Diagnose runs, which use username `radar:ai:<org>` and group `radar:ai:reader` only: a chart-owned role aggregated to match `view` plus the cluster-read and integration-read add-ons. No Kubernetes Secret permission or writes with the standard `view` role (the aggregated role also inherits anything your cluster adds to `view`); pod logs and ConfigMaps are readable and may contain sensitive data. Keep `radar:ai:reader` permanently read-only; a future write-capable AI identity needs a separate opt-in group (e.g. `radar:ai:operator`). Controlled by `cloud.aiRbac` (default `true`). Manual Diagnose turns read as the person who started them, with that person's identity and groups forwarded by Radar Cloud; `radar:ai:reader` is not involved. MCP clients also read with the user's own permissions.
237
237
- Treats `cloud.aiRbac` and `cloud.systemRbac` as controls for the chart's default grants, independent of `cloud.defaultRbac`. False or absent (including a plain `--reuse-values` upgrade from an older chart) creates no default grant and leaves customer-created bindings untouched. These are not feature switches; Radar Cloud controls whether Diagnose runs. Without any grant, the background group has no cluster access; automatic Diagnose has no viewer fallback.
238
238
- Requires cluster-admin-equivalent authority or `escalate` on ClusterRoles to create or update the AI/system aggregated roles, in addition to normal chart installation permissions. Restricted installers can set `cloud.aiRbac=false` and `cloud.systemRbac=false` and supply their own read-only group bindings.
239
239
- Uses the Cloud role (`radar:owner` / `radar:member` / `radar:viewer`) only to gate Radar's own configuration (settings, integrations, audit settings, registered OCI chart sources, self-upgrade), which runs as Radar's ServiceAccount. A Cloud request with no role group (such as the Hub's `radar:system` background identity) is refused there. Operations that run as the impersonated user — Helm reads and writes, in-cluster probe pods — are decided by Kubernetes RBAC alone.
0 commit comments