A potential risk in Bitpoke which can be levereaged to make cluster-level privilege escalation

[sparkEchooo]

I found a potential risk in Bitpoke that can be leveraged to get the cluster's admin token, resulting in cluster-level privilege escalation.
Here is the details:

Summary

The Bitpoke App in GKE gave excessive authority when defining Service Account named "bitpoke-app-controller". Besides, this Service Account is mounted in a deployment named "bitpoke-app-controller", witch makes it possible for attackers to raise rights to administrators.

Detailed Analysis

• I deployed Bitpoke from the GCP marketplace. (https://console.cloud.google.com/marketplace/product/press-labs-public/bitpoke-app?project=lateral-nomad-404309)
• There is one components of Bitpoke with default installation: bitpoke-app-controller. The components is a deployment running on worker nodes randomly,
  The clusterrole named "bitpoke-app-controller" defines the "*" verb of "pods, daemonsets, clusterroles, clusterrolebindings". And this clusterrole is bound to the Service Account named "bitpoke-app-controller". The Service Account is mounted into the deployment named "bitpoke-app-controller".

Attacking Strategy

If a malicious user controls a specific worker node which has the deployment mentioned above , or steals the Service Account token mentioned above. He/She can raise permissions to administrator level and control the whole cluster.
For example,

• With the "*" verbs of "clusterroles and clusterrolebindings", attacker can elevate privileges by creating a clusterrolebinding resource and binding cluster-admin to their own Service Account. As a result, he/she can retrieve cluster admin's credential.
• With the "*" verbs of "pods, jobs, deployments, statefulsets, replicationcontrollers", attacker can elevate privileges by creating a pod to mount and steal any Service Account he/she want. As a result, he/she can retrieve cluster admin's credential.

Mitigation Discussion

1. Developer could use the rolebinding instead of the clusterrolebinding to restrict permissions to namespace. However, it needs a careful review of the source code without disrupting its functionalities.
2. Developer could use specific permissions (such as "get,list,watch") instead of using "*". However, it still needs a careful review of the source code.

A few questions

1. Is it a real issue in bitpoke?
2. If it's a real issue, can bitpoke mitigate the risks following my suggestions discussed in the "mitigation discussion"?
3. If it's a real issue, does bitpoke plan to fix this issue?
4. Similar to the issue I reported and confirmed by the kubewarden (https://nvd.nist.gov/vuln/detail/CVE-2023-22645), can you give us a CVE Number or public thanks for awarding our efforts.

By the way, I have reported this issue by writing a e-mail to hello@bitpoke.io. However, it has been many weeks and I got no responese yet. So I tried to submit this report on github, but bitpoke didn't have a security policy, so I had to create a new issue to submit this report.
Looking forward to your reply.