這次在 lab 命名空間建立 pod-reader ServiceAccount，並配置只允許取得、列出與監看 Pod 的 Role。接著透過 RoleBinding 將角色授予這個帳號。將三種物件放在同一份檔案，能讓身分、規則與關聯一起被檢視，較容易理解授權來源。

把設定存成 rbac-demo.yaml 並套用，再利用授權查詢指令模擬這個身分。第一個查詢測試是否可以列出 Pod，預期得到 yes；第二個測試是否能刪除 Pod，在乾淨的練習環境中應得到 no，因為我們沒有授予刪除動作。

這種查詢不會真的刪除資源，適合用來檢查權限設計。模擬其他身分本身需要相應權限，本機 Minikube 的管理情境通常可以執行；若在公司環境被拒絕，應由具備權限的管理者驗證，不能把拒絕誤認為角色內容一定錯誤。

如果刪除測試意外得到允許，應檢查是否存在其他授權，而不是只修改眼前這個 Role。最後也要注意，讀取 Pod 不等於能讀取容器日誌，日誌使用不同子資源。精確列出需求，才能建立清楚、容易維護的最小權限。

rbac-demo.yaml：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader
  namespace: lab
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: lab
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader
  namespace: lab
subjects:
  - kind: ServiceAccount
    name: pod-reader
    namespace: lab
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-reader

kubectl apply -f rbac-demo.yaml
kubectl auth can-i list pods --as=system:serviceaccount:lab:pod-reader -n lab
kubectl auth can-i delete pods --as=system:serviceaccount:lab:pod-reader -n lab