Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.foggyhq.com/llms.txt

Use this file to discover all available pages before exploring further.

Scope of this page: Kubernetes RBAC only. Permissions for external connectors (Grafana, Slack, GitHub, Linear, Sentry) are controlled by the API tokens you generate on those services. You choose the scope on each token; Foggy only has what you grant.

Overview

Foggy runs as a pod with a Kubernetes ServiceAccount and uses Kubernetes-native RBAC to query your cluster read-only. All permissions are declared as ClusterRole resources in the Helm chart, auditable before helm install. Every API call is recorded in your cluster’s audit log if enabled.

What Foggy reads from Kubernetes

Resource categoryPurpose
Pods and pod logsIdentify crashing, OOMKilled, or unhealthy workloads; read logs for errors and warnings
EventsSurface cluster events (scheduling failures, image pull errors, restarts)
Deployments, ReplicaSets, StatefulSets, DaemonSetsUnderstand workload topology, rollout status, replica counts
Services, EndpointsMap network routing between workloads
ConfigMapsRead non-sensitive configuration (Secrets explicitly excluded, see below)
NodesInspect node capacity, conditions, taints
NamespacesEnumerate namespaces for scoping queries
All verbs are limited to get, list, and watch. No creation, modification, or deletion.

What Foggy does NOT access

Foggy’s default ClusterRole explicitly excludes:
  • Secrets. API keys, database passwords, TLS certs. Foggy cannot read them.
  • pods/exec. No shell into any running pod.
  • pods/portforward. No direct network access to pods.
  • create, update, patch, delete on any resource. Foggy cannot modify, create, or delete anything in your cluster.
  • Custom Resources from operators (Argo, Istio, cert-manager, etc.). Not in the default scope.
Adding any of these for a new feature requires an explicit values.yaml opt-in alongside a version bump. We never silently expand the scope.

Default ClusterRole

The exact ClusterRole the Helm chart creates:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: foggy-readonly
rules:
  - apiGroups: [""]
    resources: [pods, events, services, endpoints, configmaps, nodes, namespaces]
    verbs: [get, list, watch]
  - apiGroups: [""]
    resources: [pods/log]
    verbs: [get, list]
  - apiGroups: [apps]
    resources: [deployments, replicasets, statefulsets, daemonsets]
    verbs: [get, list, watch]
Preview every resource the chart will create, including the full ClusterRole:
helm template foggy foggy/foggy | less
For a focused RBAC-only review, use --show-only:
helm template foggy foggy/foggy \
  --show-only templates/clusterrole.yaml \
  --show-only templates/clusterrolebinding.yaml \
  --show-only templates/serviceaccount.yaml

Customization

Narrow Foggy’s Kubernetes access via values.yaml.

Namespace-scoped installation

Restrict Foggy to specific namespaces:
rbac:
  scope: namespace
  namespaces:
    - python-services
    - core-platform
Foggy generates a Role and RoleBinding per namespace instead of a cluster-wide ClusterRole.

Disable the Kubernetes connector entirely

To connect only to external tools (Grafana, Slack) without Kubernetes access:
rbac:
  disabled: true
No ServiceAccount, ClusterRole, or RoleBinding is created. Foggy installs and runs; it cannot query Kubernetes.

Bring your own ClusterRole

If your security policy requires a custom role:
rbac:
  customClusterRoleName: my-company-foggy-role
Foggy only creates the RoleBinding and expects the ClusterRole to exist.

Kubernetes remediation actions (future)

Today, Foggy is strictly read-only in Kubernetes. Write actions (pod restart, deployment rollback, similar remediations) are deferred to a future opt-in feature with a separate RBAC bundle. Kubernetes writes will always require an explicit values.yaml opt-in, never silent expansion. This is distinct from external connector writes (Slack messages, GitHub PRs, Linear tickets), which are already supported today and governed by the API token scopes you grant on those services.