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
PodSecurityPolicy
tidak digunakan lagi di Kubernetes1.21
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.
PodSecurityPolicy
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
Anda dapat meninjau praktik terbaik untuk bermigrasi PSPs ke built-in PSS dalam Panduan Praktik Terbaik EKS
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
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
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