A potential risk of airflow makes a worker node get the token of any Service Account

[sparkEchooo]

Summary

  The Airflow Operator in GKE gave excessive authority when defining Service Account named "airflow". Besides, this Service Account is mounted into deployments named "airflow-1-web" and "airflow-1-scheduler", witch makes it possible for attackers to raise rights to administrators in k8s.
 

Detailed Analysis

• I deployed Airflow in the marketplace of Google's GKE cluster by default.
• The Role named "airflow" defines the "create" verb of "pods". And this Role is bound to the Service Account named "airflow". The Service Account is mounted into two deployments named "airflow-1-web" and "airflow-1-scheduler". 

Attacking Strategy

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

• With the "create" verb of "pods", attacker can elevate privileges by creating a pod to mount and steal any Service Account he/she want OR mounting the "/etc/kubernetes/pki/*" of master node.

Mitigation Discussion

• Developer could delete the "create" verb of StatefulSets and Pods.

A few questions

• Is it a real issue in Airflow?
• If it's a real issue, can Airflow mitigate the risks following my suggestions discussed in the "Mitigation Discussion"?
• If it's a real issue, does Airflow plan to fix this issue?

Reporter List

• Xingyu Liu(ll.travor@outlook.com, me)

• Nanzi Yang(952508578nanziyang@gmail.com/nzyang@stu.xidian.edu.cn)

• Xunqi Liu(xunqiliu@stu.xidian.edu.cn)

• Xin Guo(guox@stu.xidian.edu.cn)

• Wenbo Shen(shenwenbo@zju.edu.cn)

• Jinku Li(jkli@xidian.edu.cn)