Skip to content

Latest commit

 

History

History
22 lines (16 loc) · 1.8 KB

rbac.md

File metadata and controls

22 lines (16 loc) · 1.8 KB
Raw

How to configure and use the VMWare Carbon Black Cloud Container Operator's Role-based access control (RBAC)

Design for the operator and agent RBAC definition

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,
    • and you need to read it - use a ClusterRole unless you are 100% sure what the namespace will be
    • and you need to modify it - do you really need to?
  • If the resource is non-namespaced, use a ClusterRole and try to restrict delete,get,update,patch via resourceNames (create, list, watch either don't support this restriction or require extra care)

Changing the operator's access levels

These permissions are generated by controller-gen and controlled via +kubebuilder directives. See the controller definitions. Any change to those directives requires running make manifests to update the respective role.yaml file. Changes should also be propagated to the helm charts as well.

Changing the agent components access levels

These are maintained manually in dataplane_roles.yaml and the helm equivalent. Same goes for the service accounts and role bindings. Changes should be applied in both places.

The roles should follow the least-privilege principle, same as the operator. Note that the agent components often need more permissions than the operator to work as expected.