Pengerasan Keselamatan DevOps untuk Platform Ops/SRE: Panduan Praktikal

Senario: Risiko Tersembunyi dalam Saluran CI/CD Anda

Pasukan SRE anda menguruskan kluster Kubernetes yang menjadi hos Jenkins, Argo CD, dan Prometheus. Semasa audit keselamatan suku tahunan, anda mendapati beberapa pod masih menggunakan ServiceAccount lalai yang mempunyai kebenaran cluster-admin. NetworkPolicy tidak wujud, dan rahsia dimasukkan sebagai pemboleh ubah persekitaran biasa. Dalam beberapa minggu, satu aplikasi yang dieksploitasi boleh memberi penyerang akses terus kepada kredensial awan dan membenarkan pergerakan lateral di seluruh kluster.

Simptom: Apa Yang Perlu Diberi Perhatian

• Permintaan API luar biasa daripada IP yang tidak dijangka muncul dalam log audit.
• Sesetengah ServiceAccount berulang kali cuba mengakses sumber yang tidak dibenarkan, menyebabkan entri RBAC ditolak.
• Pengimbas keselamatan melaporkan kelemahan kritikal atau tinggi, terutamanya CVE yang melibatkan peningkatan keistimewaan.
• Audit pematuhan (contohnya PCI-DSS, SOC2) menandakan kekurangan kawalan keselamatan.

Diagnosis: Mencari Kelemahan

Gunakan kubectl untuk melakukan pemeriksaan sistematik.

# Senaraikan semua ikatan peranan dan ikatan peranan kluster
kubectl get rolebindings,clusterrolebindings -o wide

# Semak kebenaran berkesan untuk ServiceAccount tertentu
kubectl auth can-i --list --as=system:serviceaccount:development:jenkins

# Senaraikan ServiceAccount dalam namespace
kubectl get serviceaccounts -n development

# Cari pod yang berjalan dalam mod privilege
kubectl get pods -n development -o json | jq '.items[] | select(.spec.containers[]?.securityContext?.privileged == true) | .metadata.name'

# Sahkan sama ada NetworkPolicy wujud
kubectl get networkpolicies -n development

Jika output menunjukkan ikatan lalai atau senarai kosong, terdapat banyak ruang untuk pengerasan.

Langkah Pengerasan: Dari Teori ke Arahan

1. RBAC dengan Keistimewaan Paling Rendah

Cipta ServiceAccount khusus untuk setiap aplikasi, dan berikan hanya sumber dan kata kerja yang diperlukan.

kubectl create serviceaccount jenkins -n development
kubectl create role jenkins-role --verb=get,list,watch --resource=pods,deployments -n development
kubectl create rolebinding jenkins-rolebinding --serviceaccount=development:jenkins --role=jenkins-role -n development

2. Kuatkuasakan Piawaian Keselamatan Pod (PSS)

Label namespace untuk menguatkuasakan mod restricted.

kubectl label namespace development pod-security.kubernetes.io/enforce=restricted

3. NetworkPolicy Tolak Semua

Cipta dasar yang menolak semua ingress dan egress, kemudian tambahkan peraturan perbolehkan yang spesifik.

# deny-all.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: development
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

kubectl apply -f deny-all.yaml

Kemudian takrifkan trafik yang dibenarkan berdasarkan kebergantungan aplikasi.

4. Gunakan Pemacu CSI Secrets Store

Pasangkan rahsia sebagai volum dan bukannya melalui pemboleh ubah persekitaran. Rujuk dokumentasi Secrets Store CSI untuk integrasi.

5. Aktifkan Log Audit

Tambahkan --audit-log-path dan --audit-policy-file pada konfigurasi API server, dan hantar log ke platform SIEM untuk pemantauan berterusan.

6. Gunakan OPA Gatekeeper

Gunakan Gatekeeper untuk menguatkuasakan dasar seperti menyekat imej dengan tag :latest atau menghalang mount Docker socket.

Kawalan Risiko: Pertahanan Berlapis

• Buat snapshot etcd sebelum membuat perubahan: etcdctl snapshot save snapshot.db
• Gunakan aliran kerja GitOps. Semua perubahan kluster melalui Git, dengan Argo CD atau Flux mengendalikan penyegerakan.
• Perkenalkan proses pengurusan perubahan di mana tindakan kritikal memerlukan semakan dua orang.
• Imbas dan tandatangan imej untuk memastikan integriti rantaian bekalan.

Strategi Pengembalian: Jaring Keselamatan

• Jika anda menggunakan perubahan terus dengan kubectl, simpan manifest YAML sebelumnya dan gunakan kubectl rollout undo atau guna semula versi lama.
• Dalam persediaan GitOps, hanya git revert komit sebelumnya dan biarkan pengawal menyegerakkan kluster kembali.
• Untuk pemulihan kecemasan, pulihkan snapshot etcd untuk mengembalikan keseluruhan keadaan kluster.

Pengesahan: Buktikan Ia Berfungsi

• Jalankan kube-bench run untuk menyemak piawaian CIS.
• Gunakan kubeaudit all untuk mengesan konfigurasi salah.
• Simulasikan serangan: cuba padam pod dalam namespace lain menggunakan ServiceAccount jenkins; permintaan harus ditolak.
• Uji NetworkPolicy: cuba akses perkhidmatan dari luar kluster; ia harus disekat.
• Semak log audit untuk memastikan tiada anomali baharu muncul selepas perubahan.

Bila Perlu Menghubungi OpsGlobal

Anda perlu mempertimbangkan untuk membuka tiket OpsGlobal apabila:

• Pasukan anda kekurangan masa atau kepakaran untuk melakukan pengerasan menyeluruh.
• Anda perlu memenuhi pensijilan pematuhan tertentu (contohnya PCI-DSS, HIPAA) dengan cepat.
• Anda mengesyaki pelanggaran keselamatan dan memerlukan tindak balas kecemasan serta forensik digital.
• Anda mahukan audit pihak ketiga yang bebas untuk mengesahkan postur keselamatan anda.

Pakar DevOps/SRE jarak jauh OpsGlobal boleh melaksanakan langkah-langkah di atas dengan pantas dan meningkatkan postur keselamatan anda tanpa mengganggu operasi perniagaan.

Nota Keselamatan: Sentiasa uji arahan dalam persekitaran pementasan dahulu. Sandaran adalah penting; jangan sekali-kali mengubah suai RBAC atau NetworkPolicy tanpa titik pemulihan.