Conversation
…sions Bind the service account to the Kubernetes built-in "view" ClusterRole for standard namespace-scoped read-only access (pods, deployments, services, etc.) and keep only a supplementary ClusterRole for permissions not in "view": cluster-scoped resources (nodes, namespaces, PVs, storageclasses), metrics, RBAC, CRDs, webhooks, events, and operator CRDs. This also removes dead entries (daemonsets/deployments listed under the core API group where they don't exist) and eliminates duplicate RBAC/autoscaling rule blocks. https://claude.ai/code/session_01TFeEVLmsp8TSf8kYX4iuH1 Signed-off-by: Claude <noreply@anthropic.com>
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
✅ Results of HolmesGPT evalsAutomatically triggered by commit 9043ea9 on branch Results of HolmesGPT evals
Benchmark Comparison DetailsBaseline: latest ci-benchmark experiment on master Status: Success - 73 test/model combinations loaded Benchmark experiment:
No benchmark data available for comparison. Benchmark has no cost, total tokens, cached tokens data. Will appear after the next weekly benchmark run. Comparison indicators:
📖 Legend
🔄 Re-run evals manually
Option 1: Comment on this PR with Or with more options (one per line): Run evals on a different branch (e.g., master) for comparison:
Quick re-run: Use Option 2: Trigger via GitHub Actions UI → "Run workflow" Option 3: Add PR labels to include extra evals (applies to both automatic runs and
Examples: 🏷️ Valid tags
🤖 Valid models
Commands: CLI: |
|
✅ Docker images ready for
Use these tags to pull the images for testing. 📋 Copy commandsgcloud auth configure-docker us-central1-docker.pkg.dev
docker pull us-central1-docker.pkg.dev/robusta-development/temporary-builds/holmes:57596ec6
docker tag us-central1-docker.pkg.dev/robusta-development/temporary-builds/holmes:57596ec6 me-west1-docker.pkg.dev/robusta-development/development/holmes-dev:57596ec6
docker push me-west1-docker.pkg.dev/robusta-development/development/holmes-dev:57596ec6
docker pull us-central1-docker.pkg.dev/robusta-development/temporary-builds/holmes-operator:57596ec6
docker tag us-central1-docker.pkg.dev/robusta-development/temporary-builds/holmes-operator:57596ec6 me-west1-docker.pkg.dev/robusta-development/development/holmes-operator-dev:57596ec6
docker push me-west1-docker.pkg.dev/robusta-development/development/holmes-operator-dev:57596ec6Patch Helm values in one line (choose the chart you use): HolmesGPT chart: helm upgrade --install holmesgpt ./helm/holmes \
--set registry=me-west1-docker.pkg.dev/robusta-development/development \
--set image=holmes-dev:57596ec6 \
--set operator.registry=me-west1-docker.pkg.dev/robusta-development/development \
--set operator.image=holmes-operator-dev:57596ec6Robusta wrapper chart: helm upgrade --install robusta robusta/robusta \
--reuse-values \
--set holmes.registry=me-west1-docker.pkg.dev/robusta-development/development \
--set holmes.image=holmes-dev:57596ec6 \
--set holmes.operator.registry=me-west1-docker.pkg.dev/robusta-development/development \
--set holmes.operator.image=holmes-operator-dev:57596ec6 |
WalkthroughThis change refactors the Kubernetes RBAC configuration to use a two-layer model: binding the built-in Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Tip You can disable sequence diagrams in the walkthrough.Disable the |
✅ Deploy Preview for holmes-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@helm/holmes/templates/holmesgpt-service-account.yaml`:
- Around line 336-349: The ClusterRoleBinding that grants the built-in "view"
role to the Holmes ServiceAccount could be misread as giving CRD access via
aggregation; clarify this by adding a short comment next to the
ClusterRoleBinding in the template (the block that creates the
ClusterRoleBinding for {{ include "holmes.serviceAccountName" . }}) stating that
CRD permissions are NOT granted via the "view" binding but are controlled
explicitly by the chart's custom ClusterRole defined by crdPermissions.* (refer
to the custom ClusterRole resource name) and thus CRD allowlisting is enforced
separately.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 1e8e61e8-c788-441e-af9d-14a5a8e6798a
📒 Files selected for processing (2)
docs/reference/kubernetes-permissions.mdhelm/holmes/templates/holmesgpt-service-account.yaml
| # Bind the built-in "view" ClusterRole for standard read-only access to | ||
| # namespace-scoped resources (pods, deployments, services, configmaps, etc.) | ||
| apiVersion: rbac.authorization.k8s.io/v1 | ||
| kind: ClusterRoleBinding | ||
| metadata: | ||
| name: {{ .Release.Name }}-holmes-view-role-binding | ||
| roleRef: | ||
| apiGroup: rbac.authorization.k8s.io | ||
| kind: ClusterRole | ||
| name: view | ||
| subjects: | ||
| - kind: ServiceAccount | ||
| name: {{ include "holmes.serviceAccountName" . }} | ||
| namespace: {{ .Release.Namespace }} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Search for crdPermissions definition and usage in the chart
rg "crdPermissions" helm/holmes/ -A 3 -B 1 --context 5Repository: HolmesGPT/holmesgpt
Length of output: 7613
🏁 Script executed:
# Look at the complete RBAC configuration for context
cat -n helm/holmes/templates/holmesgpt-service-account.yaml | head -100Repository: HolmesGPT/holmesgpt
Length of output: 2555
🏁 Script executed:
# Search for any other ClusterRole or ClusterRoleBinding definitions in the chart
rg "kind: ClusterRole|kind: ClusterRoleBinding" helm/holmes/templates/ -B 2 -A 5Repository: HolmesGPT/holmesgpt
Length of output: 7254
🏁 Script executed:
# Check if there's any documentation about RBAC strategy in the chart
find helm/holmes -name "README*" -o -name "NOTES*" | xargs cat 2>/dev/nullRepository: HolmesGPT/holmesgpt
Length of output: 45
🌐 Web query:
Kubernetes built-in view ClusterRole RBAC aggregation aggregate-to-view
💡 Result:
Kubernetes has a built-in "view" ClusterRole that uses RBAC aggregation to allow extensions without direct modification. The "view" ClusterRole includes an aggregationRule that selects other ClusterRoles labeled with rbac.authorization.k8s.io/aggregate-to-view: "true". Creating a new ClusterRole with this label automatically adds its rules (typically read-only permissions like get, list, watch) to the aggregated "view" ClusterRole. This enables custom resources or additional permissions to be viewed by anyone bound to the "view" role, such as third-party operators or monitoring tools. Example to extend the view role: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: custom-view-extension labels: rbac.authorization.k8s.io/aggregate-to-view: "true" rules: - apiGroups: ["example.com"] resources: ["widgets"] verbs: ["get", "list", "watch"] The built-in "view" role is designed for read-only access to most namespaced resources and uses this aggregation mechanism, as documented in official Kubernetes RBAC docs. Similar labels exist for "edit" (aggregate-to-edit) and "admin" (aggregate-to-admin).
Citations:
- 1: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
- 2: https://kubernetes.io/docs/reference/kubernetes-api/authorization-resources/cluster-role-v1/
- 3: https://oneuptime.com/blog/post/2026-02-09-clusterroles-aggregation-rules/view
- 4: https://building.theatlantic.com/kubernetes-rbac-update-default-clusterroles-without-editing-them-ef206254e0
🌐 Web query:
Kubernetes RBAC view role what permissions included namespace-scoped
💡 Result:
In Kubernetes RBAC, there is no built-in "view" Role object (namespace-scoped). Instead, there is a built-in "view" ClusterRole that provides read-only access to most objects in a namespace when bound via a namespace-scoped RoleBinding. The "view" ClusterRole grants get, list, and watch permissions on most namespace-scoped resources across various API groups (core "", apps, batch, etc.), including pods, services, deployments, configmaps, etc. It excludes access to roles/rolebindings (to prevent viewing RBAC config) and secrets (to avoid privilege escalation via service account tokens). To view the exact permissions: kubectl get clusterrole view -o yaml When used in a RoleBinding (namespace-scoped), it limits access to that namespace only. Official description from Kubernetes docs: "Allows read-only access to see most objects in a namespace. It does not allow viewing roles or role bindings. This role does not allow viewing Secrets, since reading the contents of Secrets enables access to ServiceAccount credentials in the namespace, which would allow API access as any ServiceAccount in the namespace (a form of privilege escalation)."
Citations:
- 1: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
- 2: https://kubernetes.io/docs/reference/access-authn-authz/rbac
- 3: https://raw.githubusercontent.com/kubernetes/kubernetes/master/plugin/pkg/auth/authorizer/rbac/bootstrappolicy/testdata/cluster-roles.yaml
- 4: https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/auth/authorizer/rbac/bootstrappolicy/testdata/cluster-roles.yaml
- 5: https://oneuptime.com/blog/post/2026-02-09-readonly-clusterroles-exclusions/view
- 6: https://v3.helm.sh/docs/topics/rbac/
🏁 Script executed:
# Check if crdPermissions rules reference namespaced or cluster-scoped resources
cat -n helm/holmes/templates/holmesgpt-service-account.yaml | sed -n '200,350p' | grep -A 10 "crdPermissions"Repository: HolmesGPT/holmesgpt
Length of output: 1968
🏁 Script executed:
# Look at the scope of built-in view role - verify it's namespaced
# Check what verbs are in the view binding rules section
cat -n helm/holmes/templates/holmesgpt-service-account.yaml | sed -n '330,360p'Repository: HolmesGPT/holmesgpt
Length of output: 1312
The view ClusterRole aggregation doesn't apply to CRD permissions here—they remain explicitly gated.
The concern about aggregation is technically valid: view is an aggregated role that admins can extend via rbac.authorization.k8s.io/aggregate-to-view: "true" labels, so Holmes would gain access to any CRDs admins add to it cluster-wide. However, CRD permissions in this chart (crdPermissions.*) are defined in the separate custom ClusterRole, not the view binding. The chart maintains an explicit allowlist for CRDs through per-flag controls, which is independent of what cluster admins do with view aggregation.
The design trade-off is acceptable: using the standard view role for namespace-scoped resources (pods, services, etc.) is conventional and maintainable, while cluster-scoped resources and optional CRDs remain under chart control via the custom role. If deterministic CRD visibility is a requirement regardless of cluster-wide view extensions, this is already satisfied by keeping CRD rules in the explicit custom ClusterRole.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@helm/holmes/templates/holmesgpt-service-account.yaml` around lines 336 - 349,
The ClusterRoleBinding that grants the built-in "view" role to the Holmes
ServiceAccount could be misread as giving CRD access via aggregation; clarify
this by adding a short comment next to the ClusterRoleBinding in the template
(the block that creates the ClusterRoleBinding for {{ include
"holmes.serviceAccountName" . }}) stating that CRD permissions are NOT granted
via the "view" binding but are controlled explicitly by the chart's custom
ClusterRole defined by crdPermissions.* (refer to the custom ClusterRole
resource name) and thus CRD allowlisting is enforced separately.
This branch has not been deployed
2 participants
Bind the service account to the Kubernetes built-in "view" ClusterRole for
standard namespace-scoped read-only access (pods, deployments, services, etc.)
and keep only a supplementary ClusterRole for permissions not in "view":
cluster-scoped resources (nodes, namespaces, PVs, storageclasses), metrics,
RBAC, CRDs, webhooks, events, and operator CRDs.
This also removes dead entries (daemonsets/deployments listed under the core
API group where they don't exist) and eliminates duplicate RBAC/autoscaling
rule blocks.
https://claude.ai/code/session_01TFeEVLmsp8TSf8kYX4iuH1
Signed-off-by: Claude noreply@anthropic.com
Summary by CodeRabbit
Documentation
Refactor