[Feature Request] Make falcon-kac ClusterRole configurable via values.yaml

[ednoah]

Summary

The falcon-kac chart installs a ClusterRole with broad, hard-coded read access across the cluster (pods, workloads, configmaps, secrets, nodes, namespaces, etc.). We would like the ability to override or restrict the ClusterRole rules from the values file, without forking the chart.

Motivation

Our security policy requires least-privilege RBAC for all third-party workloads on production clusters. We are deploying KAC in visibility-only mode (admissionControl.enabled: false) — we use it solely to report which container images are running in the cluster to the Falcon UI. We do not need admission-time enforcement, ConfigMap visibility, or secret enumeration.

Today our options for restricting the ClusterRole are:

1. Accept the default ClusterRole as-is — grants significantly more access than KAC needs for our visibility-only use case.
2. Fork the chart — breaks clean upstream tracking and adds maintenance overhead.
3. Apply a custom ClusterRole post-install and re-bind the ServiceAccount — creates drift between Helm state and actual cluster state, and risks being overwritten on helm upgrade.

None of these are acceptable long-term for a regulated environment.

Proposed solution

Expose the ClusterRole rules through values. Either a full override or an additive/subtractive model would work — for example:

rbac:
  clusterRole:
    # If non-empty, replaces the chart's default rules entirely.
    rules: []

    # Or, subtractive:
    excludeResources: []   # e.g. ["secrets", "configmaps"]
    excludeVerbs: []

Alternatively, support rbac.create: false together with serviceAccount.clusterRoleName: <existing-name> so operators can bind KAC's ServiceAccount to an org-managed ClusterRole.

Ideally the chart would also tie the rendered rules to the enabled feature flags — e.g., if clusterVisibility.resourceConfigMap.enabled: false, omit the configmaps rules; if admissionControl.enabled: false, omit any admission-only permissions.

Use case

In visibility-only mode we only need:

• get, list, watch on pods, nodes, namespaces, and workload kinds (deployments, replicasets, statefulsets, daemonsets, jobs, cronjobs)

We do not need:

• secrets access of any kind
• configmaps access (we disable clusterVisibility.resourceConfigMap)
• any write verbs
• admission-webhook-specific permissions

Environment

• Chart version: <fill in>
• KAC image version: <fill in>
• Kubernetes: EKS <version>
• Mode: visibility-only (admissionControl.enabled: false)
• Falcon cloud: EU-1

Workaround in use

Currently applying a custom ClusterRole out-of-band and accepting the drift. Would prefer a first-class chart option.

Related

• Kubernetes RBAC best practices: principle of least privilege for third-party workloads.
• Tying RBAC scope to feature flags would also reduce the attack surface for users who disable features (e.g. ConfigMap visibility).