RBAC Permissions

Edge and Edge Proxy run with separate ServiceAccounts and ClusterRoles. Edge reads a wide range of cluster resources to build the causal graph. Edge Proxy reads only Secrets to resolve backend credentials for on-prem data-source connections.

Edge Permissions

Edge runs with a ClusterRole that grants read-only access to standard Kubernetes resources across five API groups.

rules:
  - apiGroups: [""]
    resources:
      - pods
      - services
      - configmaps
      - secrets
      - persistentvolumeclaims
      - persistentvolumes
      - nodes
      - namespaces
      - resourcequotas
      - limitranges
    verbs: ["get", "list", "watch"]

  - apiGroups: ["apps"]
    resources:
      - deployments
      - statefulsets
      - daemonsets
      - replicasets
    verbs: ["get", "list", "watch"]

  - apiGroups: ["networking.k8s.io"]
    resources:
      - ingresses
      - networkpolicies
    verbs: ["get", "list", "watch"]

  - apiGroups: ["batch"]
    resources:
      - jobs
    verbs: ["get", "list", "watch"]

  - apiGroups: ["policy"]
    resources:
      - poddisruptionbudgets
    verbs: ["get", "list", "watch"]

Why These Permissions?

API Group	Resource	Why
`""` (core)	`pods`	Map IPs to workloads and track container status.
`""` (core)	`services`	Identify service endpoints and DNS names.
`""` (core)	`configmaps`	Detect configuration dependencies between workloads.
`""` (core)	`secrets`	Track secret references used by pods and volumes.
`""` (core)	`persistentvolumeclaims`	Map storage claims to workloads.
`""` (core)	`persistentvolumes`	Understand backing storage topology.
`""` (core)	`nodes`	Map pods to nodes and track node conditions.
`""` (core)	`namespaces`	Scope resources and detect namespace boundaries.
`""` (core)	`resourcequotas`	Surface quota limits that may affect scheduling.
`""` (core)	`limitranges`	Surface default limits applied to containers.
`apps`	`deployments`	Understand ownership hierarchy and rollout status.
`apps`	`statefulsets`	Track stateful workload ownership and ordering.
`apps`	`daemonsets`	Identify node-level workloads.
`apps`	`replicasets`	Link pods to their owning deployment (Pod → ReplicaSet → Deployment).
`networking.k8s.io`	`ingresses`	Map external entry points to backend services.
`networking.k8s.io`	`networkpolicies`	Detect network segmentation between workloads.
`batch`	`jobs`	Track batch workloads and their completion status.
`policy`	`poddisruptionbudgets`	Surface availability constraints on workloads.

Helm Chart Resources

When rbac.create is true (the default), the chart creates the following resources for Edge:

Resource	Name	Condition
ServiceAccount	`<release>-edge`	`serviceAccount.create=true` (default)
ClusterRole	`<release>-edge`	`rbac.create=true` (default)
ClusterRoleBinding	`<release>-edge`	`rbac.create=true` (default)

Edge Proxy Permissions

When you deploy on-prem connections, Edge Proxy needs read access to Kubernetes Secrets to load credentials for your data sources at runtime.

API Group	Resource	Verbs	Why
`""` (core)	`secrets`	`get`, `list`, `watch`	Read credentials stored in Kubernetes Secrets.

Helm Chart Resources

Resource	Name	Condition
ServiceAccount	`<release>-edge-proxy`	`onPremConnections` non-empty
ClusterRole	`<release>-edge-proxy`	`onPremConnections` non-empty and `rbac.create=true`
ClusterRoleBinding	`<release>-edge-proxy`	`onPremConnections` non-empty and `rbac.create=true`

The ClusterRole definition:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: <release>-edge-proxy
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch"]

RBAC Comparison

API Group	Resource	Edge	Edge Proxy
`""` (core)	`pods`	`get`, `list`, `watch`	—
`""` (core)	`services`	`get`, `list`, `watch`	—
`""` (core)	`configmaps`	`get`, `list`, `watch`	—
`""` (core)	`secrets`	`get`, `list`, `watch`	`get`, `list`, `watch`
`""` (core)	`persistentvolumeclaims`	`get`, `list`, `watch`	—
`""` (core)	`persistentvolumes`	`get`, `list`, `watch`	—
`""` (core)	`nodes`	`get`, `list`, `watch`	—
`""` (core)	`namespaces`	`get`, `list`, `watch`	—
`""` (core)	`resourcequotas`	`get`, `list`, `watch`	—
`""` (core)	`limitranges`	`get`, `list`, `watch`	—
`apps`	`deployments`	`get`, `list`, `watch`	—
`apps`	`statefulsets`	`get`, `list`, `watch`	—
`apps`	`daemonsets`	`get`, `list`, `watch`	—
`apps`	`replicasets`	`get`, `list`, `watch`	—
`networking.k8s.io`	`ingresses`	`get`, `list`, `watch`	—
`networking.k8s.io`	`networkpolicies`	`get`, `list`, `watch`	—
`batch`	`jobs`	`get`, `list`, `watch`	—
`policy`	`poddisruptionbudgets`	`get`, `list`, `watch`	—

Edge reads a wide range of resources to build the causal graph. Edge Proxy reads only Secrets to resolve backend credentials. Both components run with separate ServiceAccounts.

Extending the Edge ClusterRole

The rbac.extraRules value lets you append additional rules to the Edge ClusterRole. This only applies to Edge — the Edge Proxy ClusterRole is not affected.

rbac:
  extraRules:
    - apiGroups: ["autoscaling"]
      resources: ["horizontalpodautoscalers"]
      verbs: ["get", "list", "watch"]

Least Privilege

The agent is Read-Only. It never modifies your Kubernetes resources. It only reads the state to build the observability graph.

Use an Existing ServiceAccount

Edge

To skip automatic ServiceAccount creation and use your own:

serviceAccount:
  create: false
  name: "your-existing-sa"

If you also want to manage the ClusterRole yourself, disable RBAC creation as well:

rbac:
  create: false

serviceAccount:
  create: false
  name: "your-existing-sa"

Ensure your ServiceAccount has the permissions listed in Edge Permissions.

Edge Proxy

There is no separate create toggle for the Edge Proxy ServiceAccount. The chart always creates it when onPremConnections is non-empty. To bring your own RBAC while keeping the chart-created ServiceAccount, set rbac.create: false and create your own ClusterRole and ClusterRoleBinding targeting the <release>-edge-proxy ServiceAccount:

rbac:
  create: false

rbac.create is a shared toggle — setting it to false disables ClusterRole creation for both Edge and Edge Proxy. If you only need custom RBAC for one component, create both ClusterRoles manually.

Restrict Secret Access with Namespace Scoping

The default Helm chart creates a ClusterRole (cluster-wide secret access). To restrict Edge Proxy to secrets in a specific namespace, create a namespaced Role and RoleBinding manually:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: <release>-edge-proxy
  namespace: nofire-system
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: <release>-edge-proxy
  namespace: nofire-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: <release>-edge-proxy
subjects:
- kind: ServiceAccount
  name: <release>-edge-proxy
  namespace: nofire-system

Then disable the chart’s ClusterRole:

rbac:
  create: false

All connector secrets must be in the same namespace as the Role. If your secrets are spread across namespaces, use the default ClusterRole or create multiple Roles.

Get Started

Skills

Platform Features

Setup & Integrations

Security

Edge Permissions

Why These Permissions?

Helm Chart Resources

Edge Proxy Permissions

Helm Chart Resources

RBAC Comparison

Extending the Edge ClusterRole

Least Privilege

Use an Existing ServiceAccount

Edge

Edge Proxy

Restrict Secret Access with Namespace Scoping

​Edge Permissions

​Why These Permissions?

​Helm Chart Resources

​Edge Proxy Permissions

​Helm Chart Resources

​RBAC Comparison

​Extending the Edge ClusterRole

​Least Privilege

​Use an Existing ServiceAccount

​Edge

​Edge Proxy

​Restrict Secret Access with Namespace Scoping

Edge Permissions

Why These Permissions?

Helm Chart Resources

Edge Proxy Permissions

Helm Chart Resources

RBAC Comparison

Extending the Edge ClusterRole

Least Privilege

Use an Existing ServiceAccount

Edge

Edge Proxy

Restrict Secret Access with Namespace Scoping