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

[sparkEchooo]

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

Summary

The edb-postgresql in GKE gave excessive authority when defining Service Account named "edb-postgresql-cloudnative-pg-serviceaccount-name". Besides, this Service Account is mounted in a deployment named "edb-postgresql-cloudnative-pg", witch makes it possible for attackers to raise rights to administrators.

Detailed Analysis

• I deployed edb-postgresql from the GCP marketplace. (https://console.cloud.google.com/marketplace/product/public-edb-ppas/edb-postgresql?project=lateral-nomad-404309)
• There is one components of edb-postgresql with default installation: edb-postgresql-cloudnative-pg. The components is a deployment running on worker nodes randomly,
  The clusterrole named "edb-postgresql:cloudnative-pg.serviceAccount.name-r0" defines the "get" and "create" verbs of "pods, deployment, secrets". And this clusterrole is bound to the Service Account named "edb-postgresql-cloudnative-pg-serviceaccount-name". The Service Account is mounted into the deployment named "edb-postgresql-cloudnative-pg".

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 "create" and "get" verbs of "secrets", an attacker can create and get any service account's token he/she want. As a result, he/she can retrieve cluster admin's credential.
• With the "*" verbs of "pods, deployment", 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 delete the "create" and "get" verbs of "secrets". However, attackers can still steal existing secrets.
3. Developer could delete the "create" verb of "pods". However, it needs a careful review of the source code without disrupting its functionalities.

A few questions

1. Is it a real issue in edb-postgresql?
2. If it's a real issue, can edb-postgresql mitigate the risks following my suggestions discussed in the "mitigation discussion"?
3. If it's a real issue, does edb-postgresql 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 techsupport@enteprisedb.com. 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.