Keamanan Pod - Amazon EKS
Kemampuan LinuxSolusi Keamanan PodRekomendasiAlat dan sumber daya

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Keamanan Pod

Spesifikasi pod mencakup berbagai atribut berbeda yang dapat memperkuat atau melemahkan postur keamanan Anda secara keseluruhan. Sebagai praktisi Kubernetes, perhatian utama Anda adalah mencegah proses yang berjalan dalam wadah agar tidak lolos dari batas isolasi runtime container dan mendapatkan akses ke host yang mendasarinya.

Kemampuan Linux

Proses yang berjalan dalam wadah berjalan di bawah konteks pengguna root [Linux] secara default. Meskipun tindakan root dalam wadah sebagian dibatasi oleh serangkaian kemampuan Linux yang ditetapkan runtime kontainer ke wadah, hak istimewa default ini dapat memungkinkan penyerang untuk meningkatkan hak istimewa mereka dan/atau mendapatkan akses ke informasi sensitif yang terikat ke host, termasuk Rahasia dan. ConfigMaps Di bawah ini adalah daftar kemampuan default yang ditetapkan ke kontainer. Untuk informasi tambahan tentang setiap kemampuan, lihat http://man7. org/linux/man-pages/man7/capabilities.7.html.

CAP_AUDIT_WRITE, CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_FSETID, CAP_KILL, CAP_MKNOD, CAP_NET_BIND_SERVICE, CAP_NET_RAW, CAP_SETGID, CAP_SETUID, CAP_SETFCAP, CAP_SETPCAP, CAP_SYS_CHROOT

EC2 dan pod Fargate diberi kemampuan yang disebutkan di atas secara default. Selain itu, kemampuan Linux hanya dapat dihapus dari pod Fargate.

Pod yang dijalankan sebagai hak istimewa, mewarisi semua kemampuan Linux yang terkait dengan root pada host. Ini harus dihindari jika memungkinkan.

Otorisasi Node

Semua node pekerja Kubernetes menggunakan mode otorisasi yang disebut Node Authorization. Otorisasi Node mengotorisasi semua permintaan API yang berasal dari kubelet dan memungkinkan node untuk melakukan tindakan berikut:

Baca operasi:

  • layanan

  • titik akhir

  • simpul

  • polong

  • secret, configmaps, klaim volume persisten, dan volume persisten yang terkait dengan pod yang terikat pada node kubelet

Tulis operasi:

  • node dan status node (aktifkan plugin NodeRestriction penerimaan untuk membatasi kubelet untuk memodifikasi simpulnya sendiri)

  • pod dan status pod (aktifkan plugin NodeRestriction penerimaan untuk membatasi kubelet untuk memodifikasi pod yang terikat pada dirinya sendiri)

  • peristiwa

Operasi terkait Author:

  • Akses baca/tulis ke API CertificateSigningRequest (CSR) untuk bootstrap TLS

  • kemampuan untuk membuat TokenReview dan SubjectAccessReview untuk pemeriksaan yang didelegasikan authentication/authorization

EKS menggunakan node restriction admission controller yang hanya memungkinkan node untuk memodifikasi set terbatas atribut node dan objek pod yang terikat ke node. Namun demikian, penyerang yang berhasil mendapatkan akses ke host masih dapat mengumpulkan informasi sensitif tentang lingkungan dari Kubernetes API yang memungkinkan mereka untuk bergerak secara lateral di dalam cluster.

Solusi Keamanan Pod

Kebijakan Keamanan Pod (PSP)

Di masa lalu, sumber daya Pod Security Policy (PSP) digunakan untuk menentukan serangkaian persyaratan yang harus dipenuhi oleh Pod sebelum dapat dibuat. Pada Kubernetes versi 1.21, PSP sudah tidak digunakan lagi. Mereka dijadwalkan untuk dihapus di Kubernetes versi 1.25.

penting

PSPs tidak digunakan lagi di Kubernetes versi 1.21. Anda akan memiliki hingga versi 1.25 atau kira-kira 2 tahun untuk transisi ke alternatif. Dokumen ini menjelaskan motivasi untuk penghentian ini.

Migrasi ke solusi keamanan pod baru

Karena PSPs telah dihapus pada Kubernetes v1.25, administrator dan operator klaster harus mengganti kontrol keamanan tersebut. Dua solusi dapat memenuhi kebutuhan ini:

Baik solusi PAC dan PSS dapat hidup berdampingan dengan PSP; mereka dapat digunakan dalam cluster sebelum PSP dihapus. Ini memudahkan adopsi saat bermigrasi dari PSP. Silakan lihat dokumen ini saat mempertimbangkan migrasi dari PSP ke PSS.

Kyverno, salah satu solusi PAC yang diuraikan di bawah ini, memiliki panduan khusus yang diuraikan dalam posting blog saat bermigrasi dari PSPs ke solusinya termasuk kebijakan analog, perbandingan fitur, dan prosedur migrasi. Informasi dan panduan tambahan tentang migrasi ke Kyverno sehubungan dengan Pod Security Admission (PSA) telah dipublikasikan di blog AWS di sini.

Policy-as-code (PAC)

Policy-as-code Solusi (PAC) menyediakan pagar pembatas untuk memandu pengguna klaster, dan mencegah perilaku yang tidak diinginkan, melalui kontrol yang ditentukan dan otomatis. PAC menggunakan Kubernetes Dynamic Admission Controllers untuk mencegat alur permintaan server API Kubernetes, melalui panggilan webhook, dan mengubah dan memvalidasi payload permintaan, berdasarkan kebijakan yang ditulis dan disimpan sebagai kode. Mutasi dan validasi terjadi sebelum permintaan server API menghasilkan perubahan pada cluster. Solusi PAC menggunakan kebijakan untuk mencocokkan dan bertindak berdasarkan muatan permintaan server API, berdasarkan taksonomi dan nilai.

Ada beberapa solusi PAC open source yang tersedia untuk Kubernetes. Solusi ini bukan bagian dari proyek Kubernetes; mereka bersumber dari ekosistem Kubernetes. Beberapa solusi PAC tercantum di bawah ini.

Untuk informasi lebih lanjut tentang solusi PAC dan cara membantu Anda memilih solusi yang tepat untuk kebutuhan Anda, lihat tautan di bawah ini.

Standar Keamanan Pod (PSS) dan Penerimaan Keamanan Pod (PSA)

Menanggapi penghentian PSP dan kebutuhan berkelanjutan untuk mengontrol keamanan pod out-of-the-box, dengan solusi Kubernetes bawaan, Kubernetes Auth Special Interest Group membuat Pod Security Standards (PSS) dan Pod Security Admission (PSA). Upaya PSA mencakup proyek webhook pengontrol penerimaan yang mengimplementasikan kontrol yang didefinisikan dalam PSS. Pendekatan pengontrol penerimaan ini menyerupai yang digunakan dalam solusi PAC.

Menurut dokumentasi Kubernetes, PSS “mendefinisikan tiga kebijakan berbeda untuk mencakup spektrum keamanan secara luas. Kebijakan ini bersifat kumulatif dan berkisar dari yang sangat permisif hingga sangat membatasi. `”

Kebijakan ini didefinisikan sebagai:

  • Hak istimewa: Kebijakan tidak terbatas (tidak aman), memberikan tingkat izin seluas mungkin. Kebijakan ini memungkinkan eskalasi hak istimewa yang diketahui. Ini adalah tidak adanya kebijakan. Ini bagus untuk aplikasi seperti agen logging, driver penyimpanan CNIs, dan aplikasi luas sistem lainnya yang membutuhkan akses istimewa.

  • Baseline: Kebijakan pembatasan minimal yang mencegah eskalasi hak istimewa yang diketahui. Mengizinkan konfigurasi Pod default (minimal ditentukan). Kebijakan dasar melarang penggunaan HostNetwork, HostPid, HostPic, HostPath, HostPort, ketidakmampuan untuk menambahkan kemampuan Linux, bersama dengan beberapa batasan lainnya.

  • Dibatasi: Kebijakan yang sangat dibatasi, mengikuti praktik terbaik pengerasan Pod saat ini. Kebijakan ini mewarisi dari baseline dan menambahkan pembatasan lebih lanjut seperti ketidakmampuan untuk berjalan sebagai root atau root-group. Kebijakan yang dibatasi dapat memengaruhi kemampuan aplikasi untuk berfungsi. Mereka terutama ditargetkan untuk menjalankan aplikasi keamanan kritis.

Kebijakan ini mendefinisikan profil untuk eksekusi pod, disusun menjadi tiga tingkat akses istimewa vs terbatas.

Untuk mengimplementasikan kontrol yang ditentukan oleh PSS, PSA beroperasi dalam tiga mode:

  • menegakkan: Pelanggaran kebijakan akan menyebabkan pod ditolak.

  • Audit: Pelanggaran kebijakan akan memicu penambahan anotasi audit pada peristiwa yang dicatat dalam log audit, tetapi sebaliknya diizinkan.

  • peringatan: Pelanggaran kebijakan akan memicu peringatan yang dihadapi pengguna, tetapi sebaliknya diizinkan.

Mode-mode ini dan level profil (pembatasan) dikonfigurasi pada level Namespace Kubernetes, menggunakan label, seperti yang terlihat pada contoh di bawah ini.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/enforce: restricted

Ketika digunakan secara independen, mode operasional ini memiliki respons berbeda yang menghasilkan pengalaman pengguna yang berbeda. Mode enforce akan mencegah pod dibuat jika masing-masing PodSpecs melanggar level pembatasan yang dikonfigurasi. Namun, dalam mode ini, objek Kubernetes non-pod yang membuat pod, seperti Deployments, tidak akan dicegah untuk diterapkan ke cluster, bahkan jika PodSpec di dalamnya melanggar PSS yang diterapkan. Dalam hal ini Deployment akan diterapkan, sedangkan pod akan dicegah untuk diterapkan.

Ini adalah pengalaman pengguna yang sulit, karena tidak ada indikasi langsung bahwa objek Deployment yang berhasil diterapkan memungkiri pembuatan pod yang gagal. PodSpecs yang menyinggung tidak akan membuat pod. Memeriksa sumber daya Deployment dengan kubectl get deploy <DEPLOYMENT_NAME> -oyaml akan mengekspos pesan dari .status.conditions elemen pod yang gagal, seperti yang terlihat di bawah ini.

...
status:
  conditions:
    - lastTransitionTime: "2022-01-20T01:02:08Z"
      lastUpdateTime: "2022-01-20T01:02:08Z"
      message: 'pods "test-688f68dc87-tw587" is forbidden: violates PodSecurity "restricted:latest":
        allowPrivilegeEscalation != false (container "test" must set securityContext.allowPrivilegeEscalation=false),
        unrestricted capabilities (container "test" must set securityContext.capabilities.drop=["ALL"]),
        runAsNonRoot != true (pod or container "test" must set securityContext.runAsNonRoot=true),
        seccompProfile (pod or container "test" must set securityContext.seccompProfile.type
        to "RuntimeDefault" or "Localhost")'
      reason: FailedCreate
      status: "True"
      type: ReplicaFailure
...

Baik dalam mode audit maupun warning, pembatasan pod tidak mencegah agar Pod tidak dibuat dan dimulai. Namun, dalam mode ini, anotasi audit pada server API, peristiwa log audit dan peringatan kepada klien server API, seperti kubectl, dipicu, masing-masing, ketika pod, serta objek yang membuat pod, berisi PodSpecs dengan pelanggaran. Pesan kubectl peringatan terlihat di bawah ini.

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "test" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "test" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "test" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "test" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
deployment.apps/test created

Mode audit dan peringatan PSA berguna saat memperkenalkan PSS tanpa berdampak negatif pada operasi klaster.

Mode operasional PSA tidak saling eksklusif, dan dapat digunakan secara kumulatif. Seperti yang terlihat di bawah ini, beberapa mode dapat dikonfigurasi dalam satu namespace.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted

Dalam contoh di atas, peringatan yang mudah digunakan dan anotasi audit diberikan saat menerapkan Deployment, sedangkan pemberlakuan pelanggaran juga disediakan di tingkat pod. Bahkan beberapa label PSA dapat menggunakan tingkat profil yang berbeda, seperti yang terlihat di bawah ini.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/warn: restricted

Dalam contoh di atas, PSA dikonfigurasi untuk memungkinkan pembuatan semua pod yang memenuhi tingkat profil dasar, dan kemudian memperingatkan pada pod (dan objek yang membuat pod) yang melanggar level profil terbatas. Ini adalah pendekatan yang berguna untuk menentukan kemungkinan dampak ketika mengubah dari baseline ke profil terbatas.

Pod yang ada

Jika namespace dengan pod yang ada dimodifikasi untuk menggunakan profil PSS yang lebih ketat, mode audit dan warning akan menghasilkan pesan yang sesuai; namun, mode enforce tidak akan menghapus pod. Pesan peringatan terlihat di bawah ini.

Warning: existing pods in namespace "policy-test" violate the new PodSecurity enforce level "restricted:latest"
Warning: test-688f68dc87-htm8x: allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile
namespace/policy-test configured

Pengecualian

PSA menggunakan Pengecualian untuk mengecualikan penegakan pelanggaran terhadap pod yang seharusnya diterapkan. Pengecualian ini tercantum di bawah ini.

  • Nama pengguna: permintaan dari pengguna dengan nama pengguna yang dikecualikan yang diautentikasi (atau ditiru) diabaikan.

  • RuntimeClassNames: Pod dan sumber daya beban kerja yang menentukan nama kelas runtime yang dikecualikan akan diabaikan.

  • Namespaces: Pod dan sumber daya beban kerja dalam namespace yang dikecualikan diabaikan.

Pengecualian ini diterapkan secara statis dalam konfigurasi pengontrol penerimaan PSA sebagai bagian dari konfigurasi server API.

Dalam implementasi Validating Webhook, pengecualian dapat dikonfigurasi dalam ConfigMapresource Kubernetes yang akan dipasang sebagai volume ke dalam container. pod-security-webhook

apiVersion: v1
kind: ConfigMap
metadata:
  name: pod-security-webhook
  namespace: pod-security-webhook
data:
  podsecurityconfiguration.yaml: |
    apiVersion: pod-security.admission.config.k8s.io/v1
    kind: PodSecurityConfiguration
    defaults:
      enforce: "restricted"
      enforce-version: "latest"
      audit: "restricted"
      audit-version: "latest"
      warn: "restricted"
      warn-version: "latest"
    exemptions:
      # Array of authenticated usernames to exempt.
      usernames: []
      # Array of runtime class names to exempt.
      runtimeClasses: []
      # Array of namespaces to exempt.
      namespaces: ["kube-system","policy-test1"]

Seperti yang terlihat pada ConfigMap YAMAL di atas, level PSS default di seluruh cluster telah diatur untuk dibatasi untuk semua mode PSA, mengaudit, menegakkan, dan memperingatkan. Ini memengaruhi semua ruang nama, kecuali yang dikecualikan:. namespaces: ["kube-system","policy-test1"] Selain itu, dalam ValidatingWebhookConfigurationsumber daya, terlihat di bawah, pod-security-webhooknamespace juga dikecualikan dari PSS yang dikonfigurasi.

...
webhooks:
  # Audit annotations will be prefixed with this name
  - name: "pod-security-webhook.kubernetes.io"
    # Fail-closed admission webhooks can present operational challenges.
    # You may want to consider using a failure policy of Ignore, but should
    # consider the security tradeoffs.
    failurePolicy: Fail
    namespaceSelector:
      # Exempt the webhook itself to avoid a circular dependency.
      matchExpressions:
        - key: kubernetes.io/metadata.name
          operator: NotIn
          values: ["pod-security-webhook"]
...
penting

Penerimaan Pod Security lulus menjadi stabil di Kubernetes v1.25. Jika Anda ingin menggunakan fitur Pod Security Admission sebelum diaktifkan secara default, Anda perlu menginstal pengontrol penerimaan dinamis (mutating webhook). Petunjuk untuk menginstal dan mengkonfigurasi webhook dapat ditemukan di sini.

Memilih antara policy-as-code dan Standar Keamanan Pod

Pod Security Standards (PSS) dikembangkan untuk menggantikan Pod Security Policy (PSP), dengan menyediakan solusi yang sudah ada di dalam Kubernetes dan tidak memerlukan solusi dari ekosistem Kubernetes. Karena itu, solusi policy-as-code (PAC) jauh lebih fleksibel.

Daftar Pro dan Kontra berikut ini dirancang untuk membantu Anda membuat keputusan yang lebih tepat tentang solusi keamanan pod Anda.

Policy-as-code (dibandingkan dengan Standar Keamanan Pod)

Kelebihan:

Kontra:

  • Tidak dibangun di Kubernetes

  • Lebih kompleks untuk dipelajari, dikonfigurasi, dan didukung

  • Penulisan kebijakan mungkin memerlukan yang baru skills/languages/capabilities

Penerimaan Keamanan Pod (dibandingkan dengan policy-as-code)

Kelebihan:

  • Dibangun di Kubernetes

  • Lebih sederhana untuk dikonfigurasi

  • Tidak ada bahasa baru untuk digunakan atau kebijakan untuk penulis

  • Jika tingkat penerimaan default cluster dikonfigurasi ke privileged, label namespace dapat digunakan untuk memilih namespace ke dalam profil keamanan pod.

Kontra:

  • Tidak sefleksibel atau granular policy-as-code

  • Hanya 3 tingkat pembatasan

  • Terutama berfokus pada pod

Ringkasan

Jika saat ini Anda tidak memiliki solusi keamanan pod, di luar PSP, dan postur keamanan pod yang Anda butuhkan sesuai dengan model yang ditentukan dalam Standar Keamanan Pod (PSS), maka jalur yang lebih mudah mungkin adalah mengadopsi PSS, sebagai pengganti solusi. policy-as-code Namun, jika postur keamanan pod Anda tidak sesuai dengan model PSS, atau Anda membayangkan menambahkan kontrol tambahan, di luar yang ditentukan oleh PSS, maka policy-as-code solusi akan tampak lebih cocok.

Rekomendasi

Gunakan beberapa mode Pod Security Admission (PSA) untuk pengalaman pengguna yang lebih baik

Seperti disebutkan sebelumnya, mode penegakan PSA mencegah Pod dengan pelanggaran PSS diterapkan, tetapi tidak menghentikan pengontrol tingkat yang lebih tinggi, seperti Deployment. Faktanya, Deployment akan berhasil diterapkan tanpa indikasi bahwa pod gagal diterapkan. Meskipun Anda dapat menggunakan kubectl untuk memeriksa objek Deployment, dan menemukan pesan pod yang gagal dari PSA, pengalaman pengguna bisa lebih baik. Untuk membuat pengalaman pengguna lebih baik, beberapa mode PSA (audit, menegakkan, memperingatkan) harus digunakan.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted

Dalam contoh di atas, dengan mode enforce yang ditentukan, ketika manifes Deployment dengan pelanggaran PSS di PodSpec masing-masing mencoba diterapkan ke server API Kubernetes, Deployment akan berhasil diterapkan, tetapi pod tidak akan berhasil. Dan, karena mode audit dan peringatan juga diaktifkan, klien server API akan menerima pesan peringatan dan peristiwa log audit server API akan dianotasi dengan pesan juga.

Batasi kontainer yang dapat berjalan sebagai hak istimewa

Seperti disebutkan, kontainer yang berjalan sebagai hak istimewa mewarisi semua kemampuan Linux yang ditugaskan untuk melakukan root pada host. Jarang kontainer membutuhkan jenis hak istimewa ini untuk berfungsi dengan baik. Ada beberapa metode yang dapat digunakan untuk membatasi izin dan kemampuan kontainer.

penting

Fargate adalah tipe peluncuran yang memungkinkan Anda menjalankan container “tanpa server” di mana kontainer pod dijalankan pada infrastruktur yang dikelola AWS. Dengan Fargate, Anda tidak dapat menjalankan kontainer istimewa atau mengonfigurasi pod Anda untuk menggunakan HostNetwork atau HostPort.

Jangan menjalankan proses dalam wadah sebagai root

Semua kontainer berjalan sebagai root secara default. Ini bisa menjadi masalah jika penyerang dapat mengeksploitasi kerentanan dalam aplikasi dan mendapatkan akses shell ke wadah yang sedang berjalan. Anda dapat mengurangi risiko ini dengan berbagai cara. Pertama, dengan menghapus shell dari gambar kontainer. Kedua, menambahkan direktif USER ke Dockerfile Anda atau menjalankan container di pod sebagai pengguna non-root. Kubernetes PodSpec menyertakan sekumpulan bidang, di bawahnyaspec.securityContext, yang memungkinkan Anda menentukan and/or grup pengguna untuk menjalankan aplikasi Anda. Bidang ini adalah runAsUser dan runAsGroup masing-masing.

Untuk menegakkan penggunaanspec.securityContext, dan elemen-elemen yang terkait, dalam Kubernetes PodSpec, policy-as-code atau Standar Keamanan Pod dapat ditambahkan ke klaster. Solusi ini memungkinkan Anda untuk menulis dan/atau menggunakan kebijakan atau profil yang dapat memvalidasi muatan permintaan server API Kubernetes masuk, sebelum disimpan ke etcd. Selain itu, policy-as-code solusi dapat mengubah permintaan masuk, dan dalam beberapa kasus, menghasilkan permintaan baru.

Jangan pernah menjalankan Docker di Docker atau memasang soket di wadah

Meskipun ini memungkinkan Anda untuk membuat build/run gambar dalam wadah Docker, pada dasarnya Anda melepaskan kendali penuh node ke proses yang berjalan di wadah. Jika Anda perlu membuat image kontainer di Kubernetes, gunakan Kaniko, buildah, atau layanan build seperti. CodeBuild

catatan

Cluster Kubernetes yang digunakan untuk pemrosesan CICD, seperti membangun image kontainer, harus diisolasi dari cluster yang menjalankan beban kerja yang lebih umum.

Batasi penggunaan hostPath atau jika hostPath diperlukan batasi awalan mana yang dapat digunakan dan konfigurasikan volume sebagai hanya-baca

hostPathadalah volume yang memasang direktori dari host langsung ke wadah. Jarang pod membutuhkan jenis akses ini, tetapi jika mereka melakukannya, Anda harus menyadari risikonya. Secara default pod yang berjalan sebagai root akan memiliki akses tulis ke sistem file yang diekspos oleh HostPath. Ini dapat memungkinkan penyerang untuk memodifikasi pengaturan kubelet, membuat tautan simbolis ke direktori atau file yang tidak langsung diekspos oleh HostPath, misalnya /etc/shadow, menginstal kunci ssh, membaca rahasia yang dipasang ke host, dan hal-hal berbahaya lainnya. Untuk mengurangi risiko dari HostPath, konfigurasikan spec.containers.volumeMounts asreadOnly, misalnya:

volumeMounts:
- name: hostPath-volume
    readOnly: true
    mountPath: /host-path

Anda juga harus menggunakan policy-as-code solusi untuk membatasi direktori yang dapat digunakan oleh hostPath volume, atau mencegah hostPath penggunaan sama sekali. Anda dapat menggunakan Pod Security Standards Baseline atau kebijakan Restricted untuk mencegah penggunaan. hostPath

Untuk informasi lebih lanjut tentang bahaya eskalasi istimewa, baca blog Seth Art Bad Pods: Kubernetes Pod Privilege Escalation.

Tetapkan permintaan dan batasan untuk setiap kontainer untuk menghindari pertentangan sumber daya dan serangan DoS

Pod tanpa permintaan atau batasan secara teoritis dapat menggunakan semua sumber daya yang tersedia di host. Karena pod tambahan dijadwalkan ke sebuah node, node mungkin mengalami CPU atau tekanan memori yang dapat menyebabkan Kubelet menghentikan atau mengusir pod dari node. Meskipun Anda tidak dapat mencegah hal ini terjadi bersama-sama, menetapkan permintaan dan batasan akan membantu meminimalkan pertentangan sumber daya dan mengurangi risiko dari aplikasi yang ditulis dengan buruk yang mengkonsumsi sumber daya dalam jumlah berlebihan.

podSpecIni memungkinkan Anda untuk menentukan permintaan dan batas untuk CPU dan memori. CPU dianggap sebagai sumber daya yang dapat dikompresi karena dapat kelebihan langganan. Memori tidak dapat dimampatkan, yaitu tidak dapat dibagi di antara beberapa wadah.

Saat Anda menentukan permintaan untuk CPU atau memori, pada dasarnya Anda menentukan jumlah memori yang dijamin akan didapat oleh kontainer. Kubernetes mengumpulkan permintaan dari semua kontainer dalam sebuah pod untuk menentukan node mana yang akan menjadwalkan pod tersebut. Jika sebuah wadah melebihi jumlah memori yang diminta, mungkin akan dihentikan jika ada tekanan memori pada node.

Batas adalah jumlah maksimum CPU dan sumber daya memori yang diizinkan untuk dikonsumsi oleh wadah dan secara langsung sesuai dengan memory.limit_in_bytes nilai cgroup yang dibuat untuk wadah. Sebuah wadah yang melebihi batas memori akan OOM dimatikan. Jika sebuah kontainer melebihi batas CPU-nya, itu akan dibatasi.

catatan

Saat menggunakan kontainer, sangat resources.limits disarankan agar penggunaan sumber daya kontainer (alias Resource Footprints) digerakkan oleh data dan akurat, berdasarkan pengujian beban. Tanpa jejak sumber daya yang akurat dan tepercaya, wadah resources.limits dapat dilapisi. Misalnya, resources.limits.memory dapat diberi empuk 20-30% lebih tinggi dari maksimum yang dapat diamati, untuk memperhitungkan potensi ketidakakuratan batas sumber daya memori.

Kubernetes menggunakan tiga kelas Quality of Service (QoS) untuk memprioritaskan beban kerja yang berjalan pada sebuah node. Ini termasuk:

  • terjamin

  • bisa meledak

  • upaya terbaik

Jika batas dan permintaan tidak disetel, pod dikonfigurasi sebagai upaya terbaik (prioritas terendah). Pod dengan upaya terbaik adalah yang pertama terbunuh ketika memori tidak mencukupi. Jika limit ditetapkan pada semua kontainer di dalam pod, atau jika permintaan dan limit disetel ke nilai yang sama dan tidak sama dengan 0, pod dikonfigurasi sebagai jaminan (prioritas tertinggi). Pod yang dijamin tidak akan dimatikan kecuali melebihi batas memori yang dikonfigurasi. Jika batas dan permintaan dikonfigurasi dengan nilai yang berbeda dan tidak sama dengan 0, atau satu kontainer dalam pod menetapkan batas dan yang lainnya tidak atau memiliki batas yang ditetapkan untuk sumber daya yang berbeda, pod dikonfigurasi sebagai burstable (prioritas menengah). Pod ini memiliki beberapa jaminan sumber daya, tetapi dapat dimatikan setelah melebihi memori yang diminta.

penting

Permintaan tidak memengaruhi memory_limit_in_bytes nilai cgroup container; batas cgroup diatur ke jumlah memori yang tersedia di host. Namun demikian, pengaturan nilai permintaan terlalu rendah dapat menyebabkan pod ditargetkan untuk dihentikan oleh kubelet jika node mengalami tekanan memori.

Kelas Prioritas Ketentuan Kondisi Bunuh

Terjamin

tertinggi

batas = permintaan! = 0

Hanya melebihi batas memori

Terbakar

medium

batas! = permintaan! = 0

Dapat dimatikan jika melebihi memori permintaan

Upaya Terbaik

terendah

batas & permintaan Tidak Ditetapkan

Pertama terbunuh ketika memori tidak mencukupi

Untuk informasi tambahan tentang resource QoS, silakan lihat dokumentasi Kubernetes.

Anda dapat memaksa penggunaan permintaan dan batasan dengan menetapkan kuota sumber daya pada namespace atau dengan membuat rentang batas. Kuota sumber daya memungkinkan Anda menentukan jumlah total sumber daya, misalnya CPU dan RAM, yang dialokasikan ke namespace. Saat diterapkan ke namespace, ini memaksa Anda untuk menentukan permintaan dan batasan untuk semua kontainer yang digunakan ke namespace tersebut. Sebaliknya, rentang batas memberi Anda kontrol yang lebih terperinci dari alokasi sumber daya. Dengan rentang batas, Anda dapat min/max menggunakan CPU dan sumber daya memori per pod atau per kontainer dalam namespace. Anda juga dapat menggunakannya untuk mengatur nilai permintaan/batas default jika tidak ada yang disediakan.

Policy-as-code solusi dapat digunakan menerapkan permintaan dan batasan. atau bahkan untuk membuat kuota sumber daya dan rentang batas saat ruang nama dibuat.

Jangan biarkan eskalasi istimewa

Eskalasi istimewa memungkinkan proses untuk mengubah konteks keamanan di mana ia berjalan. Sudo adalah contoh yang baik dari ini seperti binari dengan bit SUID atau SGID. Eskalasi istimewa pada dasarnya adalah cara bagi pengguna untuk mengeksekusi file dengan izin pengguna atau grup lain. Anda dapat mencegah penampung menggunakan eskalasi istimewa dengan menerapkan kebijakan policy-as-code mutasi yang disetel allowPrivilegeEscalation ke false atau dengan securityContext.allowPrivilegeEscalation menyetel di. podSpec Policy-as-code kebijakan juga dapat digunakan untuk mencegah permintaan server API berhasil jika pengaturan yang salah terdeteksi. Standar Keamanan Pod juga dapat digunakan untuk mencegah Pod menggunakan eskalasi hak istimewa.

Nonaktifkan ServiceAccount token mount

Untuk pod yang tidak perlu mengakses Kubernetes API, Anda dapat menonaktifkan pemasangan ServiceAccount token secara otomatis pada spesifikasi pod, atau untuk semua pod yang menggunakan tertentu. ServiceAccount

apiVersion: v1
kind: Pod
metadata:
  name: pod-no-automount
spec:
  automountServiceAccountToken: false
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-no-automount
automountServiceAccountToken: false

Nonaktifkan penemuan layanan

Untuk pod yang tidak perlu mencari atau memanggil layanan in-cluster, Anda dapat mengurangi jumlah informasi yang diberikan ke pod. Anda dapat mengatur kebijakan DNS Pod agar tidak menggunakan CoreDNS, dan tidak mengekspos layanan di namespace pod sebagai variabel lingkungan. Lihat dokumen Kubernetes tentang variabel lingkungan untuk informasi selengkapnya tentang tautan layanan. Nilai default untuk kebijakan DNS pod adalah "ClusterFirst" yang menggunakan DNS in-cluster, sedangkan nilai non-default “Default” menggunakan resolusi DNS node yang mendasarinya. Lihat dokumen Kubernetes tentang kebijakan DNS Pod untuk informasi selengkapnya.

apiVersion: v1
kind: Pod
metadata:
  name: pod-no-service-info
spec:
    dnsPolicy: Default # "Default" is not the true default value
    enableServiceLinks: false

Konfigurasikan gambar Anda dengan sistem file root read-only

Mengkonfigurasi gambar Anda dengan sistem file root read-only mencegah penyerang menimpa biner pada sistem file yang digunakan aplikasi Anda. Jika aplikasi Anda harus menulis ke sistem file, pertimbangkan untuk menulis ke direktori sementara atau melampirkan dan memasang volume. Anda dapat menerapkan ini dengan menyetel pod SecurityContext sebagai berikut:

...
securityContext:
  readOnlyRootFilesystem: true
...

Policy-as-code dan Standar Keamanan Pod dapat digunakan untuk menegakkan perilaku ini.

Sesuai kontainer Windows di Kubernetes securityContext.readOnlyRootFilesystem tidak dapat diatur true untuk wadah yang berjalan di Windows karena akses tulis diperlukan untuk registri dan proses sistem untuk berjalan di dalam wadah.

Alat dan sumber daya