FAQ (PSP) penghapusan kebijakan keamanan Pod - Amazon EKS

Bantu tingkatkan halaman ini

Ingin berkontribusi pada panduan pengguna ini? Gulir ke bagian bawah halaman ini dan pilih Edit halaman ini GitHub. Kontribusi Anda akan membantu membuat panduan pengguna kami lebih baik untuk semua orang.

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

FAQ (PSP) penghapusan kebijakan keamanan Pod

PodSecurityPolicytidak digunakan lagi di Kubernetes1.21, dan telah dihapus di. Kubernetes 1.25 Jika Anda menggunakan PodSecurityPolicy klaster Anda, maka Anda harus bermigrasi ke Standar Keamanan Kubernetes Pod bawaan (PSS) atau ke policy-as-code solusi sebelum memutakhirkan klaster Anda ke versi 1.25 untuk menghindari gangguan pada beban kerja Anda. Pilih pertanyaan yang sering diajukan untuk mempelajari lebih lanjut.

PodSecurityPolicyadalah pengontrol penerimaan bawaan yang memungkinkan administrator cluster untuk mengontrol aspek spesifikasi yang sensitif terhadap keamanan. Pod Jika Pod memenuhi persyaratan nyaPSP, Pod diterima ke cluster seperti biasa. Jika a Pod tidak memenuhi PSP persyaratan, Pod ditolak dan tidak dapat dijalankan.

Ini adalah perubahan hulu dalam Kubernetes proyek, dan bukan perubahan yang dibuat di Amazon EKS. PSPtidak digunakan lagi Kubernetes 1.21 dan dihapus di. Kubernetes 1.25 KubernetesKomunitas mengidentifikasi masalah kegunaan yang serius denganPSP. Ini termasuk secara tidak sengaja memberikan izin yang lebih luas daripada yang dimaksudkan dan kesulitan dalam memeriksa yang PSPs berlaku dalam situasi tertentu. Masalah ini tidak dapat diatasi tanpa membuat perubahan yang melanggar. Ini adalah alasan utama mengapa Kubernetes masyarakat memutuskan untuk menghapus PSP.

Untuk memeriksa apakah Anda menggunakan PSPs di cluster Anda, Anda dapat menjalankan perintah berikut:

kubectl get psp

Untuk melihat Pods bahwa PSPs di cluster Anda berdampak, jalankan perintah berikut. Perintah ini menampilkan Pod nama, namespace, dan: PSPs

kubectl get pod -A -o jsonpath='{range.items[?(@.metadata.annotations.kubernetes\.io/psp)]}{.metadata.name}{"\t"}{.metadata.namespace}{"\t"}{.metadata.annotations.kubernetes\.io/psp}{"\n"}'

Sebelum memutakhirkan klaster ke1.25, Anda harus memigrasikan PSPs ke salah satu alternatif berikut:

  • Kubernetes PSS.

  • olicy-as-code Solusi P dari Kubernetes lingkungan.

Menanggapi PSP penghentian dan kebutuhan berkelanjutan untuk mengontrol Pod keamanan sejak awal, Kubernetes komunitas membuat solusi bawaan dengan (PSS) dan Pod Security Admission (PSA). Webhook PSA mengimplementasikan kontrol yang didefinisikan dalam file. PSS

Anda dapat meninjau praktik terbaik untuk bermigrasi PSPs ke built-in PSS dalam Panduan Praktik Terbaik EKS. Kami juga merekomendasikan untuk meninjau blog kami tentang Menerapkan Standar Keamanan Pod di Amazon EKS. Referensi tambahan termasuk Migrasi dari PodSecurityPolicy ke Built-in PodSecurity Admission Controller dan Mapping PodSecurityPolicies to Pod Security Standards.

olicy-as-code Solusi P menyediakan pagar pembatas untuk memandu pengguna klaster dan mencegah perilaku yang tidak diinginkan melalui kontrol otomatis yang ditentukan. olicy-as-code Solusi P biasanya menggunakan Kubernetes Dynamic Admission Controllers untuk mencegat alur permintaan server Kubernetes API menggunakan panggilan webhook. olicy-as-code Solusi P mengubah dan memvalidasi muatan permintaan berdasarkan kebijakan yang ditulis dan disimpan sebagai kode.

Ada beberapa policy-as-code solusi open source yang tersedia untukKubernetes. Untuk meninjau praktik terbaik migrasi PSPs ke policy-as-code solusi, lihat olicy-as-code bagian P pada GitHub halaman Keamanan Pod.

Cluster Amazon EKS dengan Kubernetes versi 1.13 atau lebih tinggi memiliki default PSP yang diberi eks.privileged nama. Kebijakan ini dibuat dalam 1.24 dan klaster sebelumnya. Ini tidak digunakan dalam 1.25 dan selanjutnya cluster. Amazon EKS secara otomatis memigrasikan ini PSP ke penegakan hukum PSS berbasis. Tidak ada tindakan yang diperlukan di pihak Anda.

Tidak. Selain itueks.privileged, yang PSP dibuat oleh Amazon EKS, tidak ada perubahan yang dilakukan ke yang lain PSPs di cluster Anda saat Anda meningkatkan ke1.25.

Tidak. Amazon EKS tidak akan mencegah pembaruan klaster ke versi 1.25 jika Anda PSP belum bermigrasi.

Saat klaster yang berisi a PSP ditingkatkan ke Kubernetes versi1.25, server API tidak mengenali PSP sumber daya di dalamnya1.25. Hal ini dapat mengakibatkan Pods mendapatkan cakupan keamanan yang salah. Untuk daftar lengkap implikasi, lihat Memigrasi dari PodSecurityPolicy ke Pengontrol Penerimaan Bawaan. PodSecurity

Kami tidak mengharapkan dampak spesifik apa pun pada beban kerja Windows. PodSecurityContext memiliki bidang yang disebut windowsOptions dalam PodSpec v1 API untuk WindowsPods. Ini menggunakan PSS dalam Kubernetes1.25. Untuk informasi selengkapnya dan praktik terbaik tentang penerapan beban kerja Windows, lihat Panduan dan Kubernetes dokumentasi Praktik Terbaik EKS. PSS