Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) is a method of regulating access to resources based on the roles of individual users. In Kubernetes, RBAC is used to control who can access the Kubernetes API and what permissions they have.

How Kubernetes Uses RBAC

Kubernetes RBAC works through four main resources:

1. Roles/ClusterRoles: Define permissions for a set of resources
2. RoleBindings/ClusterRoleBindings: Bind roles to users, groups, or service accounts
3. ServiceAccounts: Represent the identity of a workload in the cluster
4. Resources: The Kubernetes objects that can be accessed (pods, services, etc.)

Operator RBAC Configuration

When you generate installation files for your operator, KubeOps automatically creates the necessary RBAC configurations for the operator's service account. These configurations define what resources and operations your operator is allowed to perform.

Local Development

During local development, you typically use an admin account that has full cluster access. Therefore, RBAC restrictions don't apply, and you don't need to worry about permissions. However, it's still good practice to define the required RBAC rules for production use.

RBAC Verbs

KubeOps provides a set of RBAC verbs that can be used to define permissions:

Verb	Description
None	No permissions on the resource
All	All possible permissions
Get	Retrieve the resource from the API
List	List resources on the API
Watch	Watch for events on resources
Create	Create new instances of the resource
Update	Update existing resources
Patch	Patch resources
Delete	Delete resources on the API
AllExplicit	All possible permissions (defined explicitly)

RBAC Attributes

KubeOps provides two main attributes for defining RBAC rules:

EntityRbacAttribute

Use this attribute to define RBAC rules for specific entity types. It's typically used on controllers to specify what operations they need to perform on their managed entities.

[EntityRbac(typeof(V1DemoEntity), Verbs = RbacVerb.All)]
public class DemoController : IEntityController<V1DemoEntity>
{
    // Controller implementation
}

GenericRbacAttribute

Use this attribute to define RBAC rules for any Kubernetes resource. It's useful when your operator needs to interact with built-in Kubernetes resources.

[GenericRbac(
    Groups = new[] { "apps" },
    Resources = new[] { "deployments" },
    Verbs = RbacVerb.Get | RbacVerb.List | RbacVerb.Watch
)]
public class DemoController : IEntityController<V1DemoEntity>
{
    // Controller implementation
}

Default RBAC Rules

KubeOps automatically adds default RBAC rules for:

1. Lease Resources: Required for leader election

   [GenericRbac(
       Groups = new[] { "coordination.k8s.io" },
       Resources = new[] { "leases" },
       Verbs = RbacVerb.Get | RbacVerb.List | RbacVerb.Watch |
               RbacVerb.Create | RbacVerb.Update | RbacVerb.Patch
   )]

2. Events: Required for creating Kubernetes events

   [GenericRbac(
       Groups = new[] { "" },
       Resources = new[] { "events" },
       Verbs = RbacVerb.Create | RbacVerb.Patch | RbacVerb.Update
   )]

Best Practices

1. Principle of Least Privilege:

   • Only grant the permissions your operator actually needs
   • Use specific verbs instead of All when possible
   • Review and update RBAC rules when adding new features

2. Entity-Specific Rules:

   • Use EntityRbacAttribute for your custom resources
   • Define rules at the controller level
   • Consider the operations each controller needs to perform

3. Generic Rules:

   • Use GenericRbacAttribute for built-in resources
   • Be specific about which resources and operations are needed
   • Document why each rule is necessary

4. Testing:

   • Test your operator with minimal RBAC permissions
   • Verify that all required operations work
   • Check that unnecessary operations are properly restricted

Common Pitfalls

1. Missing Permissions:

   • Operator fails to perform required operations
   • Watch operations don't work
   • Leader election fails

2. Excessive Permissions:

   • Operator has more access than needed
   • Security risks from broad permissions
   • Hard to audit and maintain

3. Incorrect Resource Definitions:

   • Wrong API groups
   • Incorrect resource names
   • Missing subresources