You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
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.
Developer could delete the "create" and "get" verbs of "secrets". However, attackers can still steal existing secrets.
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
Is it a real issue in edb-postgresql?
If it's a real issue, can edb-postgresql mitigate the risks following my suggestions discussed in the "mitigation discussion"?
If it's a real issue, does edb-postgresql plan to fix this issue?
By the way, I have reported this issue by writing a e-mail to [email protected]. 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.
The text was updated successfully, but these errors were encountered:
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
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,
Mitigation Discussion
A few questions
By the way, I have reported this issue by writing a e-mail to [email protected]. 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.
The text was updated successfully, but these errors were encountered: