Giters

openkruise / kruise-game

Game Servers Management on Kubernetes

Home Page:https://openkruise.io/kruisegame/introduction

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Improper k8s permission configuration

sparkEchooo opened this issue · comments

commented

Summary

  The ack-kruise-game in ACK gave excessive authority when defining Service Account named "kruise-game-controller-manager". Besides, this Service Account is mounted in a pod named "kruise-game-controller-manager-675bb6974d-4m6d7", witch makes it possible for attackers to raise rights to administrators.
 

Detailed Analysis

  • The clusterrole named "kruise-game-manager-role" defines the "create" verb of "pods, statefulsets, mutatingwebhookconfiguration". And this clusterrole is bound to the Service Account named "kruise-game-controller-manager".

# Attacking Strategy
  If a malicious user controls a specific worker node which has the Pod 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" verb of "pods, statefulsets", attacker can elevate privileges by creating a pod to mount and steal any Service Account he/she want.
  • With the "update" verb of "mutatingconfiguration, validatingconfiguration", attacker can elevate privileges by updating MutatingWebhookConfigurations to listen and modify any resource and event in the cluster.

Mitigation Discussion

  • Developer could use the rolebinding instead of the clusterrolebinding to restrict permissions to namespace.
  • Developer could delete the "create" verb of "pods, statefulsets, mutatingwebhookconfiguration" in clusterrole mentioned above.

# A few questions

  • Is it a real issue in ack-kruise-game?
  • If it's a real issue, can ack-kruise-game mitigate the risks following my suggestions discussed in the "mitigation discussion"?
  • If it's a real issue, does ack-kruise-game plan to fix this issue?
commented

Actually, kruise-game & kruise controller manager indeed need create verb, whose permissions are already restrict. If you use multi-tenant Kubernetes clusters, it is necessary to consider cluster security. I recommend avoiding user YAML being deployed directly in the cluster. It is a better way that checking if those YAMLs use service accounts with high permissions before deployment.

commented

By the way, you can join the DingDing Group 44862615, to communicate with ours (including OKG maintainers, and Game Developers)

commented

Hi @chrisliu1995 ,
Thank you for your reply!

Did Kruise need to create pods in another namespace? If not, maybe we could use rolebinding to further restrict this permission.

Thanks again.

commented

You know, kruise can not decide which namespace the user deploy applications in. If user deploy GameServerSet in x-namespace, kruise & kruise game controller manager have to create asts & pods in x-namespace. In fact, it is cluster-scope action.

commented

Well, Thank you for your patient explanation!

commented

I apologize for bothering you again, but I just wanted to confirm once more if kruise-game necessarily requires the update permission for the mutatingwebhookconfiguration resource. It seems that once the mutatingwebhookconfiguration resource is set up during the application installation, it typically does not need to be updated.
:)