Mengeraskan Kluster Kubernetes untuk Operasi SRE: Panduan Praktikal

Senario

Sebuah syarikat permulaan yang berkembang pesat menjalankan beban kerja pengeluarannya pada kluster Kubernetes dengan tetapan RBAC lalai dan dasar rangkaian yang longgar. Pasukan keselamatan mengesan panggilan API luar biasa dari IP luaran dalam log audit, menunjukkan kemungkinan akses tanpa kebenaran.

Gejala

• Log audit menunjukkan kubectl get secrets daripada pengguna yang tidak dijangka.
• Pod boleh mencapai sumber dalam ruang nama lain.
• Akaun perkhidmatan mempunyai hak istimewa berlebihan, contohnya akaun perkhidmatan lalai default terikat dengan cluster-admin.

Diagnosis

1. Semak ikatan RBAC: kubectl get clusterrolebindings -o wide dan kubectl get rolebindings --all-namespaces -o wide.
2. Uji kebenaran: kubectl auth can-i --list --as=system:serviceaccount:default:default.
3. Periksa dasar rangkaian: kubectl get networkpolicies --all-namespaces.
4. Periksa Dasar Keselamatan Pod: kubectl get psp.

Arahan Mengeraskan

# Buang ikatan cluster-admin berbahaya
kubectl delete clusterrolebinding default-admin

# Buat akaun perkhidmatan minimal
kubectl create serviceaccount my-app -n production
kubectl create role my-app-role --verb=get,list,watch --resource=pods,services -n production
kubectl create rolebinding my-app-binding --role=my-app-role --serviceaccount=production:my-app -n production

# Guna dasar rangkaian tolak lalai
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
EOF

# Dayakan log audit (jika belum)
audit-policy.yaml:
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse

Kawalan Risiko

• Sandarkan RBAC sedia ada sebelum perubahan: kubectl get clusterrolebindings -o yaml > clusterrolebindings-backup.yaml
• Uji dasar rangkaian dalam kelompok bukan pengeluaran dahulu.
• Ketatkan kebenaran secara berperingkat untuk mengelakkan gangguan perkhidmatan.

Pelan Pengembalian

Jika pengerasan menyebabkan permintaan sah gagal:

kubectl apply -f clusterrolebindings-backup.yaml
kubectl delete networkpolicy default-deny

Guna semula dasar longgar dan catat perkhidmatan terjejas.

Pengesahan

• Jalankan semula arahan diagnosis; tindakan sensitif harus ditolak.
• kubectl auth can-i list secrets --as=system:serviceaccount:default:default harus mengembalikan no.
• Semak log audit untuk panggilan tanpa kebenaran yang ditolak.

Bila Perlu Hantar Tiket

• Pasukan dalaman kurang kepakaran amalan terbaik RBAC untuk mereka bentuk model hak minimum.
• Kluster telah dikompromi, memerlukan analisis forensik dan tindak balas insiden.
• Perlu kawalan keselamatan lanjutan (contohnya OPA/Gatekeeper, imbasan kube-bench) tetapi kurang pengalaman.
• Hubungi OpsGlobal di support@opsglobal.com untuk sokongan SRE jauh 24/7.