Improper k8s permission configuration

[sparkEchooo]

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?

[chrisliu1995]

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.

[chrisliu1995]

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

[sparkEchooo]

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.

[chrisliu1995]

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.

[sparkEchooo]

Well, Thank you for your patient explanation!

[sparkEchooo]

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. :)