Handle passing Kubeconfig to plugins (Executor and Sources)

[pkosiec]

Acceptance Criteria

Handle Kubeconfig passing for executors:

• Generate and pass Kubeconfig as a part of Context for each execution of a Kubernetes-related executor.
• Modify plugin manager to run plugins in a restricted environment.
  • It doesn't influence the way how we run source and executor plugins. Each plugin will be ran in a single subprocess, in a single restricted subdirectory.
• Ensure already existing plugins support it.
  • ConfigMap Source
  • Helm plugin
  • Extract Kubectl executor feature as a plugin #841 + Extract Kubernetes source feature as a plugin #840, if they are already done
• Add necessary tests
  • use mocked file system (?) (https://github.com/spf13/afero)
  • testing "scheduler" that spawns plugins.
• Make sure that plugins works by default in the backward compatible way.
• Take into account the default k8s Namespace when creating a dedicated kubeconfig
• Make sure that rbac property is optional
  • If the rbac context is not provided (as a result, rbac.user|group.type is empty), Botkube won't create a temporary Kubeconfig for a given plugin.

Relates to #841 and #840. Depending which tasks will be done earlier, ensure a proper Kubeconfig is passed.

Resources:

• See the RBAC proposal
• POC implementation
• solve the issue described in the investigation doc

Related issues & reason

• Role-Based Access Control #712
• Plugin Isolation #1021 since, it is not doable to introduce isolation for now.

Notes

Strategy for RBAC isolation:

1. Dynamically create subdirectories for a given execution
   • Plugins MUST respect a given kubeconfig path
2. Just start multiple process for all unique RBAC binding:
   • if kubectl is bind to 2 different channels and group strategy is used, we simply start 2 kubectl processes.
   • please check the cost of starting those processes (CPU/Memory)

[huseyinbabal]

Modify plugin manager to run plugins in a restricted environment.

So I tried to use chroot for command execution, but it is not doable since,

• This needs root permissions that means we need to remove less privileged user in Docker file and use root user
• Once we do that, helm or other vuln tools will probably start to complain about that.
  I proposed to ignore this feature for now since we have only official plugins and do not accept custom ones, wdyt? @mszostok @pkosiec @josefkarasek ?

Kubect Krew Plugin manager has same situation, and whenever I install kubectl plugin, it warns me like "the tool I download that they haven't assessed it, and the risk is your own". Maybe we should use same strategy, instead of escalating Docker's privilege.