Mengeraskan Platform DevOps/SRE: Buku Panduan Keselamatan Praktikal untuk Operasi Kubernetes

Senario

Pasukan SRE sebuah syarikat menguruskan beberapa kluster Kubernetes untuk beban kerja pengeluaran. Semasa audit keselamatan dalaman, mereka mendapati kebenaran RBAC terlalu luas—beberapa akaun perkhidmatan mempunyai keistimewaan kluster-admin—dan sesetengah rahsia disimpan sebagai teks biasa dalam Git. Selain itu, tiada NetworkPolicy dikonfigurasikan, membolehkan sebarang pod berkomunikasi dengan pod lain. Pasukan terlalu sibuk dengan operasi harian untuk menangani isu ini sehingga satu insiden hampir berlaku apabila bekas terlepas dari sempadan.

Gejala

Audit keselamatan melaporkan isu berikut:

• Pelbagai akaun perkhidmatan terikat pada peranan cluster-admin, jauh melebihi keperluan sebenar.
• Fail kubeconfig pembangun mengandungi token jangka panjang dan disimpan tanpa penyulitan.
• Sesetengah pemboleh ubah persekitaran Deployment mengandungi kata laluan pangkalan data dalam teks biasa.
• Tiada NetworkPolicy wujud dalam kluster, jadi semua pod boleh berkomunikasi secara bebas.
• Bekas berjalan sebagai root tanpa had sumber.

Gejala ini boleh membawa kepada risiko serius seperti kebocoran data, peningkatan keistimewaan, dan pergerakan lateral.

Diagnosis

Untuk mengenal pasti isu konfigurasi keselamatan dengan tepat, periksa secara sistematik pelbagai aspek kluster Kubernetes. Mengaudit RBAC, penyimpanan rahsia, konteks keselamatan pod, dan dasar rangkaian membantu mencari kelemahan yang berpotensi.

Arahan

Arahan berikut membantu mendiagnosis kedudukan keselamatan kluster (laraskan mengikut persekitaran anda):

# Semak keistimewaan pengguna semasa
kubectl auth whoami

# Senaraikan semua ClusterRoleBinding dan RoleBinding
kubectl get clusterrolebindings -o yaml
kubectl get rolebindings -A -o yaml

# Senaraikan semua akaun perkhidmatan
kubectl get serviceaccounts -A -o json | jq -r '.items[] | .metadata.namespace + "/" + .metadata.name'

# Senaraikan semua Rahsia (berhati-hati dengan penyimpanan teks biasa)
kubectl get secrets -A

# Periksa pemboleh ubah persekitaran Deployment untuk data sulit
kubectl get deployments -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}: {.spec.template.spec.containers[*].env[*].name}{"\n"}{end}'

# Senaraikan NetworkPolicy
kubectl get networkpolicies -A

# Semak sama ada pod berjalan sebagai root
kubectl get pods -A -o jsonpath='{.items[*].spec.containers[*].securityContext.runAsUser}'

Kawalan Risiko

Berdasarkan diagnosis, laksanakan langkah-langkah pengerasan berikut:

1. Kuatkuasakan RBAC Keistimewaan Paling Minimum

Cipta Peranan dan PerananPengikatan yang terperinci yang memberikan hanya kebenaran yang diperlukan. Contohnya, takrifkan peranan yang hanya boleh mengurus Deployment dalam namespace tertentu:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: prod
  name: app-deployer
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

Jangan berikan cluster-admin kepada pengguna bukan pentadbir. Sentiasa audit dan buang ikatan yang berlebihan.

2. Simpan dan Urus Rahsia dengan Selamat

Elakkan rahsia teks biasa dalam Git. Gunakan Kubernetes External Secrets atau Sealed Secrets untuk menyulitkan rahsia semasa rehat. Contohnya, Sealed Secrets membolehkan anda komit manifest yang disulitkan. Selain itu, aktifkan penyulitan etcd:

kubectl edit apiserver --allow-missing-template-driver

Tambah EncryptionConfiguration pada API server:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aesgcm:
      keys:
      - name: key1
        secret: <base64-encoded-32-byte-key>
  - identity: {}

3. Konfigurasikan Dasar Rangkaian

Tolak semua trafik masuk/keluar secara lalai dan benarkan hanya komunikasi yang diperlukan. Contoh berikut membenarkan pod dari namespace frontend mengakses port 80 pod dalam namespace backend:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: backend
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend
    ports:
    - port: 80

4. Kuatkan Konteks Keselamatan Pod

Gunakan dasar restricted Piawaian Keselamatan Pod (PSS) atau Pod Security Admission. Pastikan bekas berjalan sebagai bukan root, dengan sistem fail root baca sahaja, dan buang semua keupayaan:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true
  capabilities:
    drop:
    - ALL

5. Guna Imbasan dan Tandatangan Imej Kontena

Integrasikan alat imbasan imej (contohnya, Trivy) dalam saluran paip CI/CD untuk mengelakkan penggunaan imej yang terdedah. Tandatangan imej dengan cosign untuk meningkatkan kepercayaan rantaian bekalan.

Pemulihan

Pengerasan keselamatan mungkin memberi kesan kepada operasi perniagaan, jadi sentiasa sediakan pelan pemulihan.

• Untuk perubahan RBAC, simpan YAML ClusterRoleBinding asal dan gunakan kubectl apply untuk memulihkan jika kebenaran tidak mencukupi.
• Mengaktifkan NetworkPolicy boleh menyebabkan gangguan perkhidmatan. Gunakan satu per satu dan sahkan. Jika masalah timbul, padam dasar dengan kubectl delete networkpolicy <name>.
• Sebelum menukar penyimpanan rahsia, sandarkan rahsia sedia ada dan uji penyahsulitan.
• Menukar konteks keselamatan pod memerlukan penciptaan semula pod; lakukan penggunaan canary sebelum pelancaran penuh.

Pengesahan

Selepas pengerasan, sahkan keberkesanan kawalan:

1. Pengesahan RBAC: Cuba lakukan tindakan tanpa kebenaran dengan akaun bukan pentadbir; ia sepatutnya ditolak.
2. Pengesahan penyulitan rahsia: Semak bahawa rahsia disimpan sebagai teks sifir dalam etcd.
3. Pengesahan dasar rangkaian: Cuba akses perkhidmatan dari pod yang tidak dibenarkan; ia sepatutnya tamat masa.
4. Pengesahan keselamatan pod: Cuba jalankan pod sebagai root; ia sepatutnya ditolak.
5. Imbasan kelemahan: Jalankan semula Trivy untuk mengesahkan kadar pembaikan.

Bila Perlu Hantar Tiket OpsGlobal

Jika pasukan anda kurang kepakaran keselamatan Kubernetes, atau usaha pengerasan melibatkan banyak kluster lama dengan keperluan masa beroperasi yang ketat, pertimbangkan untuk menyumber luar kepada OpsGlobal. Pasukan sokongan DevOps atas permintaan kami boleh menjalankan audit dan pengerasan menyeluruh dengan pantas, dengan pemantauan 24/7. Semasa menghantar tiket, berikan butiran seperti saiz kluster, laporan audit keselamatan, akses kelayakan (cth., kubeconfig), dan kepentingan perniagaan. OpsGlobal akan membantu anda merancang dan melaksanakan pelan pengerasan sambil memastikan kesinambungan perniagaan.