Memperkukuhkan Kluster Kubernetes untuk Pasukan SRE: Panduan Keselamatan Praktikal

Senario

Kluster Kubernetes sebuah syarikat terjejas akibat RBAC yang terlalu permisif dan ketiadaan Dasar Keselamatan Pod. Penyerang menggunakan ServiceAccount berkeistimewaan tinggi untuk menggunakan pod jahat yang mendapat akses root pada nod.

Gejala

• Pod yang tidak diketahui muncul dalam kluster tanpa asal yang jelas.
• kubectl get pods menunjukkan kontena luar biasa (contohnya, crypto-miners).
• Log audit menunjukkan peristiwa create pod yang berlebihan daripada pengguna yang tidak dijangka.
• Penggunaan CPU/memori nod meningkat secara tidak dijangka.

Diagnosis

1. Senaraikan semua ikatan RBAC: bash kubectl get rolebindings,clusterrolebindings -A -o wide Kenal pasti ikatan yang memberikan cluster-admin kepada subjek yang mencurigakan.
2. Periksa log audit (jika didayakan): bash kubectl logs -n kube-system apiserver | grep -i “user=<suspicious>”
3. Periksa Dasar Keselamatan Pod sedia ada (atau Kemasukan Keselamatan Pod): bash kubectl get psp # jika menggunakan PSP yang usang
4. Semak NetworkPolicy: bash kubectl get networkpolicies -A Biasanya tiada dasar ditakrifkan, membenarkan lalu lintas tanpa had.

Arahan & Pemulihan

Langkah 1: RBAC dengan Keistimewaan Minimum

• Buang ikatan berbahaya: bash kubectl delete clusterrolebinding <nama-ikatan>
• Cipta peranan yang lebih terperinci: bash kubectl create role pod-reader --verb=get,list,watch --resource=pods kubectl create rolebinding dev-pod-reader --role=pod-reader --user=dev-user

Langkah 2: Menguatkuasakan Piawaian Keselamatan Pod

• Label namespace untuk menguatkuasakan profil restricted (K8s v1.23+): bash kubectl label --overwrite ns <namespace> pod-security.kubernetes.io/enforce=restricted

Langkah 3: Dasar Rangkaian

• Cipta dasar laluan masuk lalai menolak: ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-ingress spec: podSelector: {} policyTypes:
  • Ingress ```

Langkah 4: Pengurusan Rahsia

• Hentikan penyimpanan rahsia dalam ConfigMap. Gunakan stor rahsia luaran (contohnya HashiCorp Vault) atau Sealed Secrets.

Kawalan Risiko

• Uji semua perubahan pada kluster bukan pengeluaran terlebih dahulu atau menggunakan klon.
• Gunakan --dry-run=client semasa menggunakan perubahan RBAC.
• Simpan fail YAML sandaran untuk setiap sumber yang diubah suai.

Undur

• Jika dasar baru mengganggu aplikasi: bash kubectl apply -f backup-rbac.yaml kubectl label ns <namespace> pod-security.kubernetes.io/enforce- # buang label

Pengesahan

• Uji kebenaran pengguna: bash kubectl auth can-i create pods --as=dev-user # Seharusnya mengembalikan 'no'
• Cuba jalankan pod berkeistimewaan (seharusnya ditolak): bash kubectl run test-pod --image=nginx --privileged
• Semak log audit untuk mengesahkan tiada aktiviti tanpa kebenaran.

Bila Perlu Menghantar Tiket OpsGlobal

• Kluster sedang diserang secara aktif dan memerlukan forensik serta pemulihan segera.
• Pasukan anda kurang kepakaran dalam pengukuhan keselamatan dan memerlukan bimbingan pakar.
• Kawalan keselamatan lanjutan (contohnya keselamatan runtime, penanda aras CIS) diperlukan.
• Anda mengesyaki ancaman dalaman atau kegigihan jahat jangka panjang.

Pakar SRE OpsGlobal boleh membantu memulihkan dengan cepat, menggunakan alat keselamatan, dan menyediakan pemantauan berterusan.