Operator Role-based Access Control

This section describes how to configure and use Carbon Black Container Operator Role-based Access Control (RBAC).

RBAC Definition and Design

Following the principle of least-privilege, any permission given to the Operator should have good reason and be scoped as tightly as possible.

In practice, this means:

• If the resource is namespaced and part of the agent, use a Role to give permissions in the agent's namespace only.
• If the resource is namespaced and not part of the agent:
  • To read it, use a ClusterRole unless you are sure what the namespace will be.
  • To modify it, examine whether this s absolutely necessary.
• If the resource is non-namespaced, use a ClusterRole and restrict delete, get, update, and patch through resourceNames. Create, list, and watch either do not support this restriction or require extra care.

Changing the Operator Access Levels

Operator access level permissions are generated by controller-gen and controlled by using +kubebuilder directives. See controller definitions (external link). Any change to those directives requires running make manifests to update the respective role.yaml file. You must also propagate changes to the helm charts.

Changing the Agent Component Access Levels

Agent component access levels, service accounts, and role bindings are manually maintained in dataplane_roles.yaml and the helm equivalent. You must apply changes in both locations.

The roles should follow the least-privilege principle. Agent components often need more permissions than the Operator to work as expected.