Role-Based Access Control

[brampling]

A Botkube user needs to be able to run executors with the appropriate roles and permissions as they normally have working in the Kubernetes cluster. Currently executors are run using the botkube-clusterrole ClusterRole assigned to the botkube-sa service account. This means all Botkube users in a given communication channel have the same permissions which may be too broad or narrow in scope. Implementing access control moves the Botkube security perimeter from the communication channel scope to the communication user scope.

AC

• Any given user of Botkube in a communication tool (e.g. a Slack user) has a permission/role mapping to their permissions/roles in the appropriate Kubernetes cluster where Botkube is installed
• Executor commands run by a given user are run with that user's K8s permissions
• Cluster admins can configure user mappings from a high level and at the individual user level
• Users can see their user/role mapping as appropriate

Stretch goals:

• A user with existing access to a K8s cluster that is configured with Botkube RBAC can configure their own account mapping through an authorization process

Design

Read it here: https://github.com/kubeshop/botkube/blob/main/docs/proposal/2022-12-23-rbac.md

Tasks

• RBAC Design #873
• Update Botkube configuration with RBAC-related properties #933
• Handle passing Kubeconfig to plugins (Executor and Sources) #934
• Update documentation with RBAC changes #935
• Add e2e tests coverage for plugins RBAC #945

Related:

• Extract Kubernetes source feature as a plugin #840
• Extract Kubectl executor feature as a plugin #841

[pkosiec]

@brampling could you please update this issue with requirements, so we can estimate it? It still has empty description. Thanks

[pkosiec]

@lpetkov FYI