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.
- To read it, use a
- If the resource is non-namespaced, use a
ClusterRole
and restrictdelete
,get
,update
, andpatch
throughresourceNames
.Create
,list
, andwatch
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.