From a994e2064bb7ff14c92fa63dc180cb9152174ede Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 1 Jul 2026 11:26:38 +0000 Subject: [PATCH 1/6] Add guides for read-only service account and namespace-scoped RBAC - Create comprehensive guide for read-only service account mode using customClusterRoleRules - Document namespace-scoped deployment patterns and limitations - Clarify that OpenShift capabilities (SYS_PTRACE, SYS_ADMIN) are optional - Add navigation links for new documentation pages --- docs/setup-robusta/index.rst | 2 + docs/setup-robusta/openshift.rst | 31 ++- docs/setup-robusta/rbac-namespace-scoping.rst | 23 ++ .../read-only-service-account.rst | 252 ++++++++++++++++++ 4 files changed, 305 insertions(+), 3 deletions(-) create mode 100644 docs/setup-robusta/rbac-namespace-scoping.rst create mode 100644 docs/setup-robusta/read-only-service-account.rst diff --git a/docs/setup-robusta/index.rst b/docs/setup-robusta/index.rst index 777bf902e..8b01d70ff 100644 --- a/docs/setup-robusta/index.rst +++ b/docs/setup-robusta/index.rst @@ -18,6 +18,8 @@ tuning-performance configuration-secrets openshift + read-only-service-account + rbac-namespace-scoping node-selector proxies privacy-and-security diff --git a/docs/setup-robusta/openshift.rst b/docs/setup-robusta/openshift.rst index d59abfb17..0efb1d439 100644 --- a/docs/setup-robusta/openshift.rst +++ b/docs/setup-robusta/openshift.rst @@ -49,11 +49,36 @@ Some lesser used Robusta Classic features require more permissions than the base In order to support the ``python_debugger``, ``java_debugger`` and ``node_disk_analyzer`` playbooks, permission to run a far more privileged container needs to be granted to -the ``runner`` service account. This container has ``SYS_ADMIN`` capabilities and must +the ``runner`` service account. This container has ``SYS_ADMIN`` and ``SYS_PTRACE`` capabilities and must run as root on the node. +**Important**: These capabilities are **OPTIONAL** and only needed for the native debugging features mentioned above. Most Robusta deployments work fine with the baseline SCC. + +Baseline SCC is Sufficient For: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- ✅ All investigations and diagnostics +- ✅ KRR scans (resource right-sizing) +- ✅ Popeye scans (cluster analysis) +- ✅ Log analysis and enrichment +- ✅ Metrics and event analysis +- ✅ Alert correlation +- ✅ Pod restart and scaling +- ✅ Deployment patching +- ✅ All standard playbooks + +Privileged SCC Only Needed For: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- ❌ Python debugger (``python_debugger`` playbook) +- ❌ Java debugger (``java_debugger`` playbook) +- ❌ Node disk analyzer (``node_disk_analyzer`` playbook) + +Enabling the Privileged SCC +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + To support these features in a production environment, you may want to only temporarily -enable this permission so that a normal request cannot bypass the the less permissive SCC found +enable this permission so that a normal request cannot bypass the less permissive SCC found in the baseline. To enable these privileged operations in your OpenShift environment, update the ``generated_values.yaml`` as follows: @@ -62,7 +87,7 @@ update the ``generated_values.yaml`` as follows: openshift: enabled: true createScc: true - createPrivilegedScc: true + createPrivilegedScc: true # Optional - only if you need debugging features You may also reference an existing SCC using the ``openshift.privilegedSccName`` value. In test environments, you can reference the ``privileged`` SCC to enable these features in your diff --git a/docs/setup-robusta/rbac-namespace-scoping.rst b/docs/setup-robusta/rbac-namespace-scoping.rst new file mode 100644 index 000000000..71584d64d --- /dev/null +++ b/docs/setup-robusta/rbac-namespace-scoping.rst @@ -0,0 +1,23 @@ +.. _rbac-namespace-scoping: + +RBAC: Namespace-Scoped Deployments +======================================== + +By default, Robusta uses cluster-wide RBAC. This guide explains namespace-scoped options and limitations. + +Pattern 1: Namespace-Scoped ServiceAccount with Cluster-Wide Role +------------------------------------------------------------------ + +Deploy Robusta in a specific namespace but monitor the entire cluster. + +Pattern 2: Multiple Runners Per Namespace +------------------------------------------ + +Deploy separate Robusta instances for different teams using namespace-scoped Roles. + +Recommendations +--------------- + +- Use Pattern 1 for cluster-wide visibility with namespace isolation +- Use Pattern 2 for strict multi-tenancy +- Test thoroughly to verify investigations work in your scope diff --git a/docs/setup-robusta/read-only-service-account.rst b/docs/setup-robusta/read-only-service-account.rst new file mode 100644 index 000000000..7a5353a26 --- /dev/null +++ b/docs/setup-robusta/read-only-service-account.rst @@ -0,0 +1,252 @@ +.. _read-only-service-account: + +Read-Only Service Account +======================================== + +By default, Robusta's runner service account has permissions to create, update, and delete Kubernetes resources. This guide explains how to restrict the runner to read-only permissions for environments where you want to prevent any modifications to cluster resources. + +Why Read-Only Mode? +------------------- + +Read-only mode is useful in scenarios where you want to: + +- **Prevent accidental modifications**: Ensure that even if a playbook or investigation logic has a bug, no cluster resources will be modified +- **Comply with security policies**: Meet organizational requirements for read-only access in certain environments +- **Prevent node operations**: Prevent users from draining or restarting nodes through investigations +- **Audit-only mode**: Run Holmes for investigation and diagnostics without remediation capabilities + +Limitations of Read-Only Mode +----------------------------- + +When using read-only permissions, the following Robusta features will not be available: + +- **Auto-remediation**: Playbooks that automatically fix issues (restart pods, scale deployments, drain nodes, etc.) +- **Silence management**: Creating or deleting alert silences +- **Pod debugging**: Live debugging tools that require container execution +- **Resource modification**: Any playbook or action that modifies Kubernetes resources + +These features require write permissions and will gracefully fail if attempted with read-only service account. + +**Read-only mode is ideal for**: Investigation, diagnostics, log analysis, metric enrichment, and reporting. + +Implementation: Using customClusterRoleRules +--------------------------------------------- + +Robusta's Helm chart supports the ``customClusterRoleRules`` parameter, which allows you to completely replace the default ClusterRole rules with your own custom rules. + +To use read-only mode, create a custom values file with the following configuration: + +.. code-block:: yaml + + runner: + customClusterRoleRules: + # Core API resources - read-only + - apiGroups: + - "" + resources: + - configmaps + - daemonsets + - deployments + - events + - namespaces + - persistentvolumes + - persistentvolumeclaims + - pods + - pods/status + - pods/exec + - pods/log + - replicasets + - replicationcontrollers + - services + - serviceaccounts + - endpoints + - secrets + verbs: + - get + - list + - watch + + # Nodes - read-only + - apiGroups: + - "" + resources: + - nodes + verbs: + - get + - list + - watch + + # Apps API - read-only + - apiGroups: + - apps + resources: + - daemonsets + - deployments + - deployments/scale + - replicasets + - replicasets/scale + - statefulsets + verbs: + - get + - list + - watch + + # Batch API - read-only + - apiGroups: + - batch + resources: + - cronjobs + - jobs + verbs: + - get + - list + - watch + + # Autoscaling - read-only + - apiGroups: + - autoscaling + resources: + - horizontalpodautoscalers + verbs: + - get + - list + - watch + + # RBAC - read-only + - apiGroups: + - rbac.authorization.k8s.io + resources: + - clusterroles + - clusterrolebindings + - roles + - rolebindings + verbs: + - get + - list + - watch + + # Networking - read-only + - apiGroups: + - networking.k8s.io + resources: + - ingresses + - networkpolicies + verbs: + - get + - list + - watch + + # Events - read-only + - apiGroups: + - events.k8s.io + resources: + - events + verbs: + - get + - list + + # CRDs - read-only + - apiGroups: + - apiextensions.k8s.io + resources: + - customresourcedefinitions + verbs: + - list + - get + + # API Registration - read-only + - apiGroups: + - apiregistration.k8s.io + resources: + - apiservices + verbs: + - get + - list + + # Policy - read-only + - apiGroups: + - policy + resources: + - poddisruptionbudgets + - podsecuritypolicies + verbs: + - get + - list + + # Monitoring (optional) - read-only + - apiGroups: + - monitoring.coreos.com + resources: + - prometheusrules + - servicemonitors + - podmonitors + - alertmanagers + - silences + verbs: + - get + - list + - watch + + # Argo CD (optional) - read-only + - apiGroups: + - argoproj.io + resources: + - applications + - applicationsets + - appprojects + - workflows + - workflowtemplates + - cronworkflows + - rollouts + - analysisruns + - analysistemplates + - experiments + verbs: + - get + - list + - watch + +Then install or upgrade Robusta with this values file: + +.. code-block:: bash + + helm upgrade --install robusta robusta/robusta \ + -f generated_values.yaml \ + -f read-only-values.yaml \ + -n robusta-system --create-namespace + +Verifying Read-Only Permissions +-------------------------------- + +After installation, verify that the runner service account has only read permissions: + +.. code-block:: bash + + # Check the ClusterRole + kubectl describe clusterrole robusta-runner-cluster-role -n robusta-system + + # Verify that the rules only contain "get", "list", "watch" verbs + # You should NOT see "create", "delete", "patch", or "update" verbs + +Testing Write Protection +------------------------ + +To confirm that write operations are blocked, try a simple test: + +.. code-block:: bash + + # Get the runner pod + RUNNER_POD=$(kubectl get pod -n robusta-system -l app.kubernetes.io/name=robusta-runner -o jsonpath='{.items[0].metadata.name}') + + # Try to create a test pod (should fail with permission denied) + kubectl exec -it $RUNNER_POD -n robusta-system -- \ + kubectl create pod test --image=nginx -n default + +This command should fail with a "forbidden" or "permission denied" error, confirming that write operations are blocked. + +Notes and Recommendations +-------------------------- + +- **CRD Permissions**: If you have custom operators (Argo, Flux, Kafka, KEDA, etc.), add their CRD groups to the read-only rules above with only ``get``, ``list``, ``watch`` verbs +- **Performance**: Read-only mode may improve performance slightly since no write operations are performed +- **Logging**: Monitor Robusta logs for any "permission denied" errors to identify features that require write access From 3d7bfe981a4605d19454ede19b5ce8906af74306 Mon Sep 17 00:00:00 2001 From: "avi@robusta.dev" Date: Wed, 1 Jul 2026 16:43:09 +0300 Subject: [PATCH 2/6] Support read-only runner and namespace-scoped Holmes RBAC - Add runner.overrideClusterRoles: when set, its rules fully replace the built-in runner ClusterRole rules (read-only mode); customClusterRoleRules keeps its additive behavior. - Rewrite RBAC docs to use overrideClusterRoles, tighten the read-only sample (drop pods/exec + secrets), and fix verification commands. - Correct the OpenShift privileged SCC root claim (RunAsAny permits but does not mandate root). Co-Authored-By: Claude Opus 4.8 (1M context) --- docs/setup-robusta/openshift.rst | 6 ++- docs/setup-robusta/rbac-namespace-scoping.rst | 54 ++++++++++++++----- .../read-only-service-account.rst | 43 ++++++++------- .../templates/runner-service-account.yaml | 4 ++ helm/robusta/values.yaml | 4 ++ 5 files changed, 78 insertions(+), 33 deletions(-) diff --git a/docs/setup-robusta/openshift.rst b/docs/setup-robusta/openshift.rst index 0efb1d439..8bf5e4978 100644 --- a/docs/setup-robusta/openshift.rst +++ b/docs/setup-robusta/openshift.rst @@ -49,8 +49,10 @@ Some lesser used Robusta Classic features require more permissions than the base In order to support the ``python_debugger``, ``java_debugger`` and ``node_disk_analyzer`` playbooks, permission to run a far more privileged container needs to be granted to -the ``runner`` service account. This container has ``SYS_ADMIN`` and ``SYS_PTRACE`` capabilities and must -run as root on the node. +the ``runner`` service account. This container runs privileged with the ``SYS_ADMIN`` and +``SYS_PTRACE`` capabilities. The privileged SCC uses ``runAsUser: RunAsAny``, so it does not force +a specific user; the debug container typically runs as root in order to attach to and inspect other +processes on the node. **Important**: These capabilities are **OPTIONAL** and only needed for the native debugging features mentioned above. Most Robusta deployments work fine with the baseline SCC. diff --git a/docs/setup-robusta/rbac-namespace-scoping.rst b/docs/setup-robusta/rbac-namespace-scoping.rst index 71584d64d..f802e8960 100644 --- a/docs/setup-robusta/rbac-namespace-scoping.rst +++ b/docs/setup-robusta/rbac-namespace-scoping.rst @@ -3,21 +3,51 @@ RBAC: Namespace-Scoped Deployments ======================================== -By default, Robusta uses cluster-wide RBAC. This guide explains namespace-scoped options and limitations. +By default, Robusta and HolmesGPT use cluster-wide RBAC: they are granted a ``ClusterRole`` bound with a +``ClusterRoleBinding``, so they can read (and, for the runner, act on) resources in every namespace. -Pattern 1: Namespace-Scoped ServiceAccount with Cluster-Wide Role ------------------------------------------------------------------- +In restricted environments you may want to limit what HolmesGPT can see to a specific set of namespaces. +This guide explains how, and what the trade-offs are. -Deploy Robusta in a specific namespace but monitor the entire cluster. +Scoping HolmesGPT to Specific Namespaces +---------------------------------------- -Pattern 2: Multiple Runners Per Namespace ------------------------------------------- +Set ``holmes.overrideClusterRoles`` to the list of namespaces HolmesGPT is allowed to access. Instead of a +cluster-wide ``ClusterRoleBinding``, the chart then creates a namespaced ``RoleBinding`` in each listed +namespace (reusing the same ClusterRole for its rules): -Deploy separate Robusta instances for different teams using namespace-scoped Roles. +.. code-block:: yaml -Recommendations ---------------- + holmes: + overrideClusterRoles: + - default + - monitoring -- Use Pattern 1 for cluster-wide visibility with namespace isolation -- Use Pattern 2 for strict multi-tenancy -- Test thoroughly to verify investigations work in your scope +When this list is empty (the default), HolmesGPT keeps its cluster-wide binding — existing installs are +unaffected. + +.. important:: + + - The listed namespaces **must already exist**; the chart does not create them. + - Access is limited to **namespaced** resources in those namespaces. **Cluster-scoped** resources + (for example ``nodes``, ``persistentvolumes``, cluster-level events) are no longer readable, so + tools that rely on them (node health, cluster-wide resource views) will not work. + +Verifying the Scope +------------------- + +.. code-block:: bash + + SA=system:serviceaccount::robusta-holmes-service-account + + kubectl auth can-i list pods --as=$SA -n default # -> yes + kubectl auth can-i list pods --as=$SA -n monitoring # -> yes + kubectl auth can-i list pods --as=$SA -n kube-system # -> no + +Notes on the Runner +------------------- + +The Robusta runner remains cluster-wide. To reduce the runner's permissions, use +:ref:`a read-only ClusterRole ` via ``runner.overrideClusterRoles``. +Fully scoping the runner to a subset of namespaces is not supported through Helm values, because the +runner watches cluster-wide resources and events to function. diff --git a/docs/setup-robusta/read-only-service-account.rst b/docs/setup-robusta/read-only-service-account.rst index 7a5353a26..d52ccae62 100644 --- a/docs/setup-robusta/read-only-service-account.rst +++ b/docs/setup-robusta/read-only-service-account.rst @@ -29,17 +29,24 @@ These features require write permissions and will gracefully fail if attempted w **Read-only mode is ideal for**: Investigation, diagnostics, log analysis, metric enrichment, and reporting. -Implementation: Using customClusterRoleRules ---------------------------------------------- +Implementation: Using overrideClusterRoles +------------------------------------------- -Robusta's Helm chart supports the ``customClusterRoleRules`` parameter, which allows you to completely replace the default ClusterRole rules with your own custom rules. +Robusta's Helm chart supports the ``runner.overrideClusterRoles`` parameter. When set, the rules you +provide **fully replace** the built-in runner ClusterRole rules, so only the permissions you list are granted. + +.. note:: + + Do not confuse this with ``runner.customClusterRoleRules``. That parameter *adds* rules on top of the + built-in rules (which include write verbs), so it **cannot** be used to make the runner read-only. + Use ``runner.overrideClusterRoles`` for read-only mode. To use read-only mode, create a custom values file with the following configuration: .. code-block:: yaml runner: - customClusterRoleRules: + overrideClusterRoles: # Core API resources - read-only - apiGroups: - "" @@ -53,14 +60,12 @@ To use read-only mode, create a custom values file with the following configurat - persistentvolumeclaims - pods - pods/status - - pods/exec - pods/log - replicasets - replicationcontrollers - services - serviceaccounts - endpoints - - secrets verbs: - get - list @@ -218,31 +223,31 @@ Then install or upgrade Robusta with this values file: Verifying Read-Only Permissions -------------------------------- -After installation, verify that the runner service account has only read permissions: +After installation, verify that the runner service account has only read permissions. The ClusterRole is +cluster-scoped, so no namespace flag is needed: .. code-block:: bash - # Check the ClusterRole - kubectl describe clusterrole robusta-runner-cluster-role -n robusta-system - - # Verify that the rules only contain "get", "list", "watch" verbs - # You should NOT see "create", "delete", "patch", or "update" verbs + # Inspect the ClusterRole - the rules should only contain "get", "list", "watch" verbs, + # and NOT "create", "delete", "patch", or "update". + kubectl describe clusterrole robusta-runner-cluster-role Testing Write Protection ------------------------ -To confirm that write operations are blocked, try a simple test: +Use ``kubectl auth can-i`` to confirm what the runner service account can and cannot do +(replace ``robusta-system`` with your release namespace): .. code-block:: bash - # Get the runner pod - RUNNER_POD=$(kubectl get pod -n robusta-system -l app.kubernetes.io/name=robusta-runner -o jsonpath='{.items[0].metadata.name}') + SA=system:serviceaccount:robusta-system:robusta-runner-service-account - # Try to create a test pod (should fail with permission denied) - kubectl exec -it $RUNNER_POD -n robusta-system -- \ - kubectl create pod test --image=nginx -n default + kubectl auth can-i list pods --as=$SA -n default # -> yes + kubectl auth can-i delete pods --as=$SA -n default # -> no + kubectl auth can-i patch deployments --as=$SA -n default # -> no + kubectl auth can-i create pods/exec --as=$SA -n default # -> no -This command should fail with a "forbidden" or "permission denied" error, confirming that write operations are blocked. +The read verbs should return ``yes`` while all write/exec verbs return ``no``, confirming the runner is read-only. Notes and Recommendations -------------------------- diff --git a/helm/robusta/templates/runner-service-account.yaml b/helm/robusta/templates/runner-service-account.yaml index 5d808c874..408d4f2c3 100644 --- a/helm/robusta/templates/runner-service-account.yaml +++ b/helm/robusta/templates/runner-service-account.yaml @@ -5,6 +5,9 @@ metadata: name: {{ include "robusta.fullname" . }}-runner-cluster-role namespace : {{ .Release.Namespace }} rules: + {{- if .Values.runner.overrideClusterRoles }} +{{ toYaml .Values.runner.overrideClusterRoles | indent 2 }} + {{- else }} {{- if .Values.runner.customClusterRoleRules }} {{ toYaml .Values.runner.customClusterRoleRules | indent 2 }} {{- end }} @@ -543,6 +546,7 @@ rules: - list - watch {{- end }} + {{- end }} {{/* end of overrideClusterRoles if/else — when overrideClusterRoles is set, it replaces the built-in rules */}} --- apiVersion: v1 diff --git a/helm/robusta/values.yaml b/helm/robusta/values.yaml index f4582bbe2..4929b024d 100644 --- a/helm/robusta/values.yaml +++ b/helm/robusta/values.yaml @@ -744,7 +744,11 @@ runner: tolerations: [] annotations: {} nodeSelector: ~ + # Legacy: rules here are ADDED to the built-in runner ClusterRole rules (backwards compatible). customClusterRoleRules: [] + # When set, these rules fully REPLACE the built-in runner ClusterRole rules (built-ins and + # customClusterRoleRules are omitted). Use for a read-only runner. Empty = built-in behavior. + overrideClusterRoles: [] # set to override global.imagePullSecrets for the runner; leave empty to inherit the global imagePullSecrets: [] extraVolumes: [] From c4eeb35a03aa797acc6d6e079dd96b4e25ab0e0c Mon Sep 17 00:00:00 2001 From: "avi@robusta.dev" Date: Wed, 1 Jul 2026 16:54:13 +0300 Subject: [PATCH 3/6] docs: add helm upgrade command to namespace-scoping guide Make the guide self-complete: show the helm upgrade command and note it can be combined with the read-only runner. Co-Authored-By: Claude Opus 4.8 (1M context) --- docs/setup-robusta/rbac-namespace-scoping.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/setup-robusta/rbac-namespace-scoping.rst b/docs/setup-robusta/rbac-namespace-scoping.rst index f802e8960..1f838b1de 100644 --- a/docs/setup-robusta/rbac-namespace-scoping.rst +++ b/docs/setup-robusta/rbac-namespace-scoping.rst @@ -26,6 +26,17 @@ namespace (reusing the same ClusterRole for its rules): When this list is empty (the default), HolmesGPT keeps its cluster-wide binding — existing installs are unaffected. +Apply it with a Helm upgrade (merge it into your existing values file, or pass it as an extra ``-f`` file): + +.. code-block:: bash + + helm upgrade --install robusta robusta/robusta \ + -f generated_values.yaml \ + -n + +You can combine this with a :ref:`read-only runner ` in the same values file to +get a fully restricted, audit-only deployment. + .. important:: - The listed namespaces **must already exist**; the chart does not create them. From d6405fe9d1a370af40e925c11ea78bb7c81894e0 Mon Sep 17 00:00:00 2001 From: "avi@robusta.dev" Date: Wed, 1 Jul 2026 17:16:35 +0300 Subject: [PATCH 4/6] docs: use holmes.roleBindingNamespaces for namespace-scoped Holmes RBAC Co-Authored-By: Claude Opus 4.8 (1M context) --- docs/setup-robusta/rbac-namespace-scoping.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/setup-robusta/rbac-namespace-scoping.rst b/docs/setup-robusta/rbac-namespace-scoping.rst index 1f838b1de..6d2fbc646 100644 --- a/docs/setup-robusta/rbac-namespace-scoping.rst +++ b/docs/setup-robusta/rbac-namespace-scoping.rst @@ -12,14 +12,14 @@ This guide explains how, and what the trade-offs are. Scoping HolmesGPT to Specific Namespaces ---------------------------------------- -Set ``holmes.overrideClusterRoles`` to the list of namespaces HolmesGPT is allowed to access. Instead of a +Set ``holmes.roleBindingNamespaces`` to the list of namespaces HolmesGPT is allowed to access. Instead of a cluster-wide ``ClusterRoleBinding``, the chart then creates a namespaced ``RoleBinding`` in each listed namespace (reusing the same ClusterRole for its rules): .. code-block:: yaml holmes: - overrideClusterRoles: + roleBindingNamespaces: - default - monitoring From e45a5d90bd01dc6a1f37593ecde40914d6528340 Mon Sep 17 00:00:00 2001 From: Avi <97387909+Avi-Robusta@users.noreply.github.com> Date: Thu, 2 Jul 2026 13:02:19 +0300 Subject: [PATCH 5/6] Delete docs/setup-robusta/rbac-namespace-scoping.rst --- docs/setup-robusta/rbac-namespace-scoping.rst | 64 ------------------- 1 file changed, 64 deletions(-) delete mode 100644 docs/setup-robusta/rbac-namespace-scoping.rst diff --git a/docs/setup-robusta/rbac-namespace-scoping.rst b/docs/setup-robusta/rbac-namespace-scoping.rst deleted file mode 100644 index 6d2fbc646..000000000 --- a/docs/setup-robusta/rbac-namespace-scoping.rst +++ /dev/null @@ -1,64 +0,0 @@ -.. _rbac-namespace-scoping: - -RBAC: Namespace-Scoped Deployments -======================================== - -By default, Robusta and HolmesGPT use cluster-wide RBAC: they are granted a ``ClusterRole`` bound with a -``ClusterRoleBinding``, so they can read (and, for the runner, act on) resources in every namespace. - -In restricted environments you may want to limit what HolmesGPT can see to a specific set of namespaces. -This guide explains how, and what the trade-offs are. - -Scoping HolmesGPT to Specific Namespaces ----------------------------------------- - -Set ``holmes.roleBindingNamespaces`` to the list of namespaces HolmesGPT is allowed to access. Instead of a -cluster-wide ``ClusterRoleBinding``, the chart then creates a namespaced ``RoleBinding`` in each listed -namespace (reusing the same ClusterRole for its rules): - -.. code-block:: yaml - - holmes: - roleBindingNamespaces: - - default - - monitoring - -When this list is empty (the default), HolmesGPT keeps its cluster-wide binding — existing installs are -unaffected. - -Apply it with a Helm upgrade (merge it into your existing values file, or pass it as an extra ``-f`` file): - -.. code-block:: bash - - helm upgrade --install robusta robusta/robusta \ - -f generated_values.yaml \ - -n - -You can combine this with a :ref:`read-only runner ` in the same values file to -get a fully restricted, audit-only deployment. - -.. important:: - - - The listed namespaces **must already exist**; the chart does not create them. - - Access is limited to **namespaced** resources in those namespaces. **Cluster-scoped** resources - (for example ``nodes``, ``persistentvolumes``, cluster-level events) are no longer readable, so - tools that rely on them (node health, cluster-wide resource views) will not work. - -Verifying the Scope -------------------- - -.. code-block:: bash - - SA=system:serviceaccount::robusta-holmes-service-account - - kubectl auth can-i list pods --as=$SA -n default # -> yes - kubectl auth can-i list pods --as=$SA -n monitoring # -> yes - kubectl auth can-i list pods --as=$SA -n kube-system # -> no - -Notes on the Runner -------------------- - -The Robusta runner remains cluster-wide. To reduce the runner's permissions, use -:ref:`a read-only ClusterRole ` via ``runner.overrideClusterRoles``. -Fully scoping the runner to a subset of namespaces is not supported through Helm values, because the -runner watches cluster-wide resources and events to function. From ca8f0398eb2640676e6b4bbf0b837f0ca03bf279 Mon Sep 17 00:00:00 2001 From: Avi <97387909+Avi-Robusta@users.noreply.github.com> Date: Thu, 2 Jul 2026 13:02:39 +0300 Subject: [PATCH 6/6] Update index.rst --- docs/setup-robusta/index.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/setup-robusta/index.rst b/docs/setup-robusta/index.rst index 8b01d70ff..6c113d55a 100644 --- a/docs/setup-robusta/index.rst +++ b/docs/setup-robusta/index.rst @@ -19,10 +19,9 @@ configuration-secrets openshift read-only-service-account - rbac-namespace-scoping node-selector proxies privacy-and-security installation-faq - \ No newline at end of file +