Generate kube config based on plugin RBAC

[josefkarasek]

Description

Changes proposed in this pull request:

• Add kubeConfig string to executor context
• Generate kube config per plugin invocation based on plugin RBAC

Testing

Use executors:

• helm
• kubectl

Sources:

• kubernetes
• cm-watcher

sources:
  'cm':
    displayName: "Events based on plugin"
    botkube/cm-watcher:
      enabled: true
      config:
        configMap:
          name: cm-watcher-trigger
          namespace: botkube
          event: ADDED
      context: *defaultExecutorContext

Self-host plugins

make gen-plugins-index
PLUGIN_SERVER_HOST=http://host.k3d.internal go run test/helpers/plugin_server.go
plugins:
  repositories:
    botkube:
      url: http://host.k3d.internal:3000/botkube.yaml

Install botkube with helm or make sure SA and CluterRole(s) and bindings exist.
ClusterRole botkube-plugins-default will be used for generating kube config for plugins.

# executor kubectl
kubectl get pod -n botkube
# source kubernets
kubectl run nginx --image=nginx
# source cm-watcher
kubectl create cm cm-watcher-trigger -n botkube
# executor helm
helm list
helm install --namespace botkube --repo https://charts.bitnami.com/bitnami psql postgresql

During testing add create/update/delete verbs to ClusterRole botkube-plugins-default.

Related issue(s)

#934

[github-advanced-security]

You have successfully added a new Trivy configuration .github/workflows/vulnerability-scan.yml:scan-repo. As part of the setup process, we have scanned this repository and found 1 existing alert. Please check the repository Security tab to see all alerts.

[josefkarasek]

This might break existing functionality. We might as well remove kube config from config

[pkosiec]

🤔 I think it would be great to keep the existing functionality of passing external kubeconfig. This functionality is great to connect to an external cluster. So Botkube can reside e.g. on cluster A, but it can listen for events + execute commands from cluster B.

Options I see:

1. have kubeconfig as it were before, which overrides kubeconfig for all (sources, executors) and we ignore context.rbac 🤔 That would need to load the file from path, right?
2. load external kubeconfig as a base for generated kubeconfigs (with modifying impersonate-related properties)
3. add context.kubeconfig.path property which takes custom kubeconfig as a path and injects it in a given plugin.

I'd prefer third option I think 🤔 Let's chat about this in our team.

[mszostok]

2 cents from my side: I like that option however, even Argo Workflow which is quite popular project, it doesn't support external/multi-cluster (they have issue opened for more that 2years now). If someone wants to have such functionality, they can always use https://github.com/virtual-kubelet/virtual-kubelet#providers. Of course, it brings additional maintenance cost, but it's also a more powerful and “safer” option.

Maybe at the end it just brings not necessary complexity to the Botkube itself? Probably it's a question to @brampling whether we should leave that functionality or not.

---

However, if we will decide to leave that functionality, it would be good to name it like context.remote.kubeconfig? so it is easier to distinguish current cluster RBAC usage vs external one.

[huseyinbabal]

@josefkarasek could you please share an rbac config for channel based configuration? I am doing e2e test, I only managed to handle static one

[pkosiec]

Good work! Just a few comments/open questions.

[pkosiec]

When exactly the channel name based group mapping will be supported? I know that it'll block the #945 task.