Cluster-wide RBACs for CNFs

Implementing minimal RBAC is a recommended best practice in Kubernetes and systems that use role-based permissions. It ensures that users, processes, and services are granted only the permissions necessary to perform their tasks. This approach, known as the principle of least privilege, strengthens security, minimizes risks, and improves maintainability.

By adopting minimum RBAC, we ensure that the Kubernetes cluster remains secure, compliant, and manageable, while reducing risks from both internal and external threats. However, there are a few CNF components listed in this section, that still require cluster-wide access or privilages under certain circumstances as detailed in the justification column.

CNE Controller (f5ingress)

Resource Privilege Justification
customresourcedefinitions (CRDs) Read only The CNE controller needs to identify which F5 CRDs are installed in the cluster. The controller uses this list to run watchers only for the relevant CRDs (F5 and Gateway API) deployed on the cluster.
This check helps avoid unnecessary error logging and ensures that only the required watchers are executed. To achieve this, the controller performs a list operation on the CRDs. Alternatively, it could query the Kubernetes API server for each CRD individually to verify its installation.
However, this approach is resource-intensive due to the large number of CRDs (over 100, some with multiple aliases).
customresourcedefinitions
f5-big-ips-policies.k8s.f5net.com
f5-big-pe-policies.k8s.f5net.com
Read/Write The CRD updater container in the CNE controller pod requires privileges to dynamically update CRDs with categories and applications.
This privilege is added to the cluster role only if the downloader pod is enabled and the Helm parameter controller.crdupdater.enabled is set to true (default is false).
When included in the cluster role, the privilege is further restricted by ResourceNames, explicitly limiting permissions to two specific F5 CRDs.
validatingwebhookconfigurations get, update Cluster-wide privilege is required to update the CA bundle for the webhook, as the resource itself is cluster-scoped.

CWC

Resource Privilege Justification
nodes Read only
(get, list)
Cluster-wide access is required to fetch node details, and add those details in the telemetry report.
customresourcedefinition Read only
(get, list)
The CWC needs to retrieve the list of installed F5 CRDs, to include details in the telemetry report, which provides cluster-wide information such as the number of instances of each CRD across namespaces.
This data is also used by the qkview API to fetch CRD details.
namespace Read only
(get, list)
Cluster-wide access is required to fetch details from all namespaces required by qkview.

In environments where the F5 components are deployed across multiple namespaces, set the parameter multiNSDeployment value to True in values.yaml file. If all the F5 components are installed in a single namespace and there are no watch namespaces, then multiNSDeployment value can be set to False.

Following table lists the Resources that require cluster-wide access when multiNSDeployment value is set to True.

Resource Privilege Justification
pods Read Only
(get, list)
Multiple CNE Controllers and Watch namespaces are dynamically added at runtime. Additionally, qkview operations need to collect data from Pods running across multiple namespaces.
services Read Only
(get, list)
Multiple CNE Controllers and Watch namespaces are dynamically added at runtime. Additionally, qkview operations need to collect data from Pods running across multiple namespaces.
deployments/daemon set Read Only
(get, list)
Multiple CNE Controllers and Watch namespaces are dynamically added at runtime. CWC requires this information to identify various TMM deployments and retrieve details about TMM instances and CPU usage details required for telemetry.

CSRC

Resource Privilege Justification
nodes Read only
(list)
The CSRC requires the list of nodes in the cluster to determine their CIDR values.
ippools Read only
(list)
The CSRC requires information from all IPPools resources to retrieve their respective CIDRs.

Cert

The f5-cert-manager RBACs are based on the OSS cert-manager, and adhere to the principle of least privilege. For users who prefer using their own cert-manager, F5 components are compatible with that setup as well.

Feedback

Provide feedback to improve this document by emailing cnfdocs@f5.com.