Pengukuhan Keselamatan DevOps untuk Platform Ops/SRE: Penerokaan Mendalam Kubernetes Praktikal

Senario

Pasukan Ops menguruskan kluster Kubernetes berbilang penyewa. Log audit terkini menunjukkan permintaan RBAC yang dinafikan dan Pod istimewa yang tidak dijangka muncul dalam ruang nama pengeluaran. Pembangun mengadu tentang kawalan akses yang tidak konsisten.

Gejala

• Pengguna bukan pentadbir cuba menyenaraikan sumber pada peringkat kluster (cth. Node, PV) dan dinafikan.
• Bekas istimewa muncul dalam ruang nama yang sepatutnya tidak wujud.
• Polisi rangkaian tidak mengasingkan trafik merentas ruang nama dengan berkesan.

Diagnosis

1. Semakan RBAC

# Senaraikan semua ClusterRoleBinding dan RoleBinding
kubectl get clusterrolebinding -o wide
kubectl get rolebinding -A -o wide
# Periksa kebenaran berkesan untuk pengguna atau ServiceAccount tertentu
export USER="john.doe@example.com"  # ganti dengan pengguna sebenar
kubectl auth can-i --list --as=$USER --all-namespaces | grep -v "no"

2. Audit Polisi Rangkaian

# Senaraikan semua polisi rangkaian
kubectl get networkpolicy --all-namespaces
# Periksa sama ada polisi lalai-menolak wujud (jika tiada, semua trafik dibenarkan)
NAMESPACE="production"
kubectl describe networkpolicy -n $NAMESPACE

3. Semakan Konteks Keselamatan Pod

# Cari Pod dengan bekas istimewa atau allowPrivilegeEscalation
kubectl get pods --all-namespaces -o jsonpath="{range .items[*]}{.metadata.namespace}{' '}{.metadata.name}{' '}{.spec.containers[*].securityContext.privileged}{'\\n'}{end}" | grep true
# Periksa tetapan PodSecurityAdmission
kubectl get pods -n $NAMESPACE -o yaml | grep -A5 "pod-security.kubernetes.io/enforce"

Kawalan Risiko & Perintah Pengukuhan

1. Ketatkan RBAC

# Cipta Role dan RoleBinding dengan hak minimum (contoh: akses baca sahaja untuk Pod dalam ruang nama)
kubectl create role pod-reader --verb=get,list,watch --resource=pods -n $NAMESPACE
kubectl create rolebinding $USER-pod-reader --role=pod-reader --user=$USER -n $NAMESPACE
# Padam ClusterRoleBinding yang terlalu permisif
kubectl delete clusterrolebinding overpermissive-binding

2. Guna Polisi Rangkaian

# Tolak semua trafik masuk dan keluar secara lalai, kemudian izinkan komunikasi perlu
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: $NAMESPACE
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

kubectl apply -f default-deny-all.yaml
# Tambah polisi izinkan, cth., Pod hadapan boleh berkomunikasi dengan Pod belakang

3. Guna Piawaian Keselamatan Pod

# Dayakan Pod Security Admission pada tahap restricted di ruang nama
kubectl label ns $NAMESPACE pod-security.kubernetes.io/enforce=restricted
kubectl label ns $NAMESPACE pod-security.kubernetes.io/warn=restricted

Sandaran Selamat & Undur

Sebelum menggunakan perubahan, sandarkan sumber semasa:

kubectl get clusterrolebinding -o yaml > clusterrolebinding-backup.yaml
kubectl get rolebinding -A -o yaml > rolebinding-backup.yaml
kubectl get networkpolicy -A -o yaml > networkpolicy-backup.yaml

Untuk mengundur:

kubectl apply -f clusterrolebinding-backup.yaml
kubectl apply -f rolebinding-backup.yaml
kubectl apply -f networkpolicy-backup.yaml
kubectl label ns $NAMESPACE pod-security.kubernetes.io/enforce-  # buang label

Pengesahan

Ulang perintah diagnosis untuk mengesahkan sekatan:

kubectl auth can-i list pods --as=$USER -n $NAMESPACE  # sepatutnya kembali yes
kubectl auth can-i list nodes --as=$USER  # sepatutnya kembali no
kubectl get pods -n $NAMESPACE -o yaml | grep privileged  # tiada output

Bila Hantar Tiket OpsGlobal

• Pasukan anda tidak dapat mentafsir penafian log audit yang kompleks.
• Anda memerlukan polisi keselamatan yang konsisten merentas berbilang kluster.
• Anda berdepan keperluan pematuhan peraturan (cth. PCI-DSS) tanpa kepakaran dalaman.
• Pengukuhan memecahkan aplikasi secara tidak dijangka dan anda memerlukan debug pakar.

Jurutera SRE OpsGlobal boleh mendiagnosis dari jauh dan melaksanakan konfigurasi keselamatan bertaraf bank, memastikan kluster anda memenuhi amalan terbaik industri.