Kode pengontrol penerimaan sedang ditinjau di: https://github.com/kubernetes/kubernetes/pull/24600

Fitur ini melompat langsung ke Beta karena memiliki eksposur awal di OpenShift.

Ini akan dinonaktifkan secara default di kubernetes/kubernetes#24600. Setelah itu masuk, kita perlu perubahan pada pengontrol penerimaan untuk menghubungkan PSP ke pengguna.

Mencatat https://github.com/kubernetes/kubernetes/pull/20573 sebagai ketergantungan untuk langkah selanjutnya pada PSP (akses tingkat subjek)

Ini statusnya apa? Apakah deskripsi di komentar pertama mutakhir?

Apakah deskripsi di komentar pertama mutakhir?

tidak (saya tidak memiliki izin untuk memperbarui). Saya yakin semua persyaratan alpha telah terpenuhi. Jenis awal, api, dan pengujian telah digabungkan. Pengontrol masuk tidak diaktifkan secara default.

IMO pekerjaan yang tersisa untuk beta/1.4 adalah integrasi auth untuk izin, pembaruan untuk bidang baru yang ingin kami batasi (seccomp - dalam proses, sysctl), dan semua dokumen/tutorial yang diperlukan.

Dan tes e2e.

Pada Selasa, 12 Juli 2016 pukul 06:23, Paul Weil [email protected] menulis:

Apakah deskripsi di komentar pertama mutakhir?

tidak (saya tidak memiliki izin untuk memperbarui). Saya percaya semua alpha
persyaratan telah terpenuhi. Jenis awal, api, dan tes telah
bergabung. Pengontrol masuk tidak diaktifkan secara default.

IMO pekerjaan yang tersisa untuk beta/1.4 adalah integrasi auth untuk izin,
memperbarui untuk bidang baru yang ingin kami batasi (seccomp - sedang berlangsung,
sysctl), dan semua dokumen/tutorial yang diperlukan.

—
Anda menerima ini karena Anda yang menulis utas.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/features/issues/5#issuecomment -232045429,
atau matikan utasnya
https://github.com/notifications/unsubscribe/AHuudqFwephlYk0Y1PS77y0xxA5QW0_-ks5qU5U7gaJpZM4IaU8n
.

Bagaimana dengan interaksi dengan penyedia cloud? Akan menyenangkan untuk dengan mudah menetapkan setiap pod peran IAM yang berbeda sehingga mereka hanya dapat mengakses subset layanan cloud yang benar-benar mereka butuhkan. Apakah itu dalam ruang lingkup atau dianggap sebagai detail SecurityContext?

@therc yang harus dilakukan melalui ServiceAccount.

@goltermann Saya perhatikan ini ditandai dengan alfa tetapi saya yakin itu mungkin memerlukan tag beta berdasarkan https://github.com/kubernetes/features/issues/5#issuecomment -217939650

@erictune apakah beta terdengar benar berdasarkan komentar @pweil-?

@goltermann Saya pikir secara teknis ini akan menjadi beta di 1.3, ini bukan hal baru untuk 1.4 meskipun pengembangan sedang berlangsung.

Ya, beta benar. Saya salah ketika saya mengatakan alpha sebelumnya hari ini.

bagus, perbaiki

@pweil- Apakah dokumennya sudah siap? Harap perbarui dokumen ke https://github.com/kubernetes/kubernetes.github.io , lalu tambahkan nomor PR dan centang kotak dokumen di deskripsi masalah

@janetkuo dokumen PR https://github.com/kubernetes/kubernetes.github.io/pull/1150

edit: https://github.com/kubernetes/kubernetes.github.io/pull/1206 adalah PR 1,4 yang benar

cc @kubernetes/feature-reviewers

@pweil- Saya kira, PR ini sebenarnya - https://github.com/kubernetes/kubernetes.github.io/pull/1206?

benar

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Cegah masalah dari penutupan otomatis dengan komentar /lifecycle frozen .

Jika masalah ini aman untuk ditutup sekarang, silakan lakukan dengan /close .

Kirim umpan balik ke sig-testing, kubernetes/test-infra dan/atau @fejta .
/siklus hidup basi

pekerjaan sedang terjadi di 1.10 untuk memindahkan PSP ke grup API non-ekstensinya
cc @php-coder

@erictune doc update, tolong? Lihat juga [spreadsheet pelacakan fitur 1.10[(https://docs.google.com/spreadsheets/d/17bZrKTk8dOx5nomLrD1-93uBfajK5JS-v1o-nCLJmzE/edit#gid=0). lmk jika Anda memiliki pertanyaan. Kami perlu agar PR dokumen ditinjau dan digabungkan sebelum 3/9. Terima kasih!

@php-coder ^

@Bradamant3 @liggitt Pembaruan dokumen apa yang diperlukan?

Untuk perubahan terkait transisi grup API, saya telah mengirimkan: https://github.com/kubernetes/website/pull/7562 , https://github.com/kubernetes/examples/pull/206 , dan https:/ /github.com/kubernetes/examples/pull/208

Saya bukan pemilik yang tepat untuk pembaruan PSP Doc.

Pada Jum, 2 Mar 2018 jam 11:26, Vyacheslav Semushin <
[email protected]> menulis:

@Bradamant3 https://github.com/bradamant3 @liggitt
https://github.com/liggitt Pembaruan dokumen apa yang diperlukan?

Untuk perubahan yang terkait dengan transisi grup API, saya telah mengirimkan:
kubernetes/website#7562 https://github.com/kubernetes/website/pull/7562 ,
kubernetes/examples#206 https://github.com/kubernetes/examples/pull/206 ,
dan kubernetes/contoh#208
https://github.com/kubernetes/examples/pull/208

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/features/issues/5#issuecomment-370026485 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AHuudtBCup17Kt91pqJzBRpKWStoXUt-ks5taZzcgaJpZM4IaU8n
.

Itu saja yang kita butuhkan. Saya telah menambahkan PR ke spreadsheet pelacakan. Terima kasih!

@php-coder @liggitt @tallclair
Ada rencana untuk ini di 1.11?

Jika demikian, dapatkah Anda memastikan bahwa fitur tersebut mutakhir dengan yang sesuai:

• Keterangan
• Tonggak pencapaian
• Penerima Tugas
• Label:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

@php-coder Bisakah Anda menanggapi komentar @justaugutus dengan pekerjaan yang Anda lakukan di sini? Apakah ada perubahan selain perpindahan grup kebijakan?

Apakah ada perubahan selain perpindahan grup kebijakan?

Tidak, saya hanya mengerjakan ini.

Saya berharap @liggitt akan memperbarui deskripsi ketika dia punya waktu (karena saya tidak memiliki izin yang sesuai).

Selesai.

@tallclair hanya untuk memperjelas, kami melacak stabil sebagai target untuk 1.11, benar?
Saya telah memperbarui label, hanya ingin memastikan.

Tidak, ini masih versi beta. Saya tidak yakin PodSecurityPolicy akan pernah menjadi stabil (yaitu akan digantikan oleh sesuatu yang lain), tetapi orang lain mungkin tidak setuju dengan saya dalam hal ini.

Mengerti. Terima kasih atas pembaruannya, @tallclair!

@justaugutus Saya akan menghapus ini dari tonggak 1.11, karena tidak ada kemajuan signifikan yang akan terjadi dalam rilis saat ini.

Tidak ada pembaruan yang direncanakan untuk 1.12

@tallclair saya mungkin bisa mendapatkan tombol RunAsGroup PSP di 1.12

ak. Ini masih akan dalam versi beta. Saat ini belum ada rencana PSP untuk masuk ke GA. Ada beberapa masalah kegunaan utama yang perlu ditangani sebelum kami melanjutkan ini. (lihat https://github.com/kubernetes/kubernetes/issues/60001 dan https://github.com/kubernetes/kubernetes/issues/56174

/batalkan penetapan

/assign @tallclair

Hai
Peningkatan ini telah dilacak sebelumnya, jadi kami ingin memeriksa dan melihat apakah ada rencana untuk menyelesaikan tahap ini di Kubernetes 1.13. Rilis ini ditargetkan lebih 'stabil' dan memiliki timeline yang agresif. Harap sertakan peningkatan ini hanya jika ada tingkat kepercayaan yang tinggi bahwa perangkat tersebut akan memenuhi tenggat waktu berikut:

• Dokumen (PR placeholder terbuka): 11/8
• Kode Lumpur: 11/9
• Pembekuan Kode Dimulai: 11/15
• Dokumen Lengkap dan Diulas: 27/11

Harap luangkan waktu untuk memperbarui pencapaian pada kiriman asli Anda untuk pelacakan di masa mendatang dan ping ke @kacole2 jika perlu disertakan dalam Lembar Pelacakan Peningkatan 1.13

Terima kasih!

Tidak ada perubahan yang direncanakan di 1.13.

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, silakan lakukan dengan /close .

Kirim umpan balik ke sig-testing, kubernetes/test-infra dan/atau fejta .
/siklus hidup basi

/hapus siklus hidup basi

@tallclair Halo - Saya memimpin peningkatan untuk 1.14 dan saya memeriksa masalah ini untuk melihat pekerjaan apa (jika ada) yang direncanakan untuk rilis 1.14. Pembekuan perangkat tambahan adalah 29 Januari dan saya ingin mengingatkan bahwa semua perangkat tambahan harus memiliki KEP

Tidak ada yang direncanakan untuk 1,14.

Apa celah untuk ini menjadi GA? Saya dapat memikirkan beberapa, tetapi saya tidak melihat kriteria apa pun dalam deskripsi.

Sebelum ini bisa masuk ke GA, kita perlu memperbaiki masalah ini:

1. Model otorisasi yang cacat - penggunaan PSP diberikan melalui RBAC, dan dapat diberikan kepada pengguna, atau pod yang dibuat. Memberikannya kepada pengguna adalah pendekatan intuitif, tetapi bermasalah (lihat penjelasan). Pendekatan ini juga memiliki beberapa masalah keamanan.
2. Sulit untuk diluncurkan - Karena pod ditolak secara default, kami tidak dapat meluncurkan PSP ke semua cluster tanpa merusaknya. Demikian pula, pengguna yang ingin mengaktifkan PSP perlu memastikan cakupan lengkap dari semua beban kerja sebelum mereka dapat menyalakannya, yang membuatnya sulit untuk diaktifkan (karenanya penggunaan yang relatif rendah). Karena fitur harus diaktifkan secara eksplisit, kami tidak memiliki cakupan pengujian yang memadai (matriks fitur terlalu kompleks).
3. API Tidak Konsisten - Sedikit masalah mendasar, tetapi evolusi API PSP dalam rentang waktu yang lama dari rilis k8s telah menyebabkan sejumlah inkonsistensi sehingga sulit untuk digunakan. Secara khusus, mutasi digabungkan dengan validasi, yang dapat menyebabkan beberapa hasil yang tidak terduga ketika sebuah pod memiliki akses ke beberapa PSP.

@liggitt dan saya punya beberapa ide tentang cara mengatasi ini, tetapi ada pertanyaan terbuka tentang apakah ini termasuk dalam inti Kubernetes. Saya ingin memiliki peta jalan di bulan depan, baik rencana untuk pergi ke GA atau rencana untuk dihentikan.

Terima kasih telah berbagi informasi!

Karena pod ditolak secara default, kami tidak dapat meluncurkan PSP ke semua cluster tanpa merusaknya.

Saya kira itu tidak benar-benar itu. Kami melakukan ini dengan membuat PodSecurityPolicy yang cukup terbuka (atau bahkan membuka semua) terlebih dahulu, lalu menyempurnakannya secara bertahap.

@zhouhaibing089 pengguna Kubrenetes dapat menggunakan metode yang berfungsi karena mereka mengontrol kebijakan. Namun, kami tidak dapat meluncurkannya sebagai default Kubernetes karena PodSecurityPolicy hanya membuka cluster, yang berarti sangat sulit untuk mengelola PSP yang mengizinkan semua yang dikontrol sistem.

Halo @liggitt @tallclair , saya Pemimpin Peningkatan untuk 1,15. Apakah fitur ini akan lulus tahap alfa/beta/stabil di 1.15? Tolong beri tahu saya agar dapat dilacak dengan benar dan ditambahkan ke spreadsheet. Proposal komunitas perlu dimigrasikan ke KEP untuk dimasukkan dalam 1.15.

Setelah pengkodean dimulai, harap cantumkan semua k/k PR yang relevan dalam edisi ini sehingga dapat dilacak dengan benar.

Tidak ada perubahan yang direncanakan untuk 1,15

@tallclair Akan sangat senang melihat tanah ini sebagai GA di 1.16. Apakah itu mungkin?

@lachie83 Tidak, kami tidak yakin kami ingin PodSecurityPolicy masuk ke GA. Tidak jelas apakah ini adalah kasus penggunaan yang harus diselesaikan oleh inti Kubernetes, dan kami sedang mencari alternatif di luar inti. Jika Anda ingin membahasnya lebih detail, ini adalah topik yang bagus untuk SIG-Auth.

@tallclair Akankah hal-hal seperti penjaga gerbang Agen Kebijakan Terbuka menjadi jalan yang lebih baik untuk turun?

Iya benar sekali. Itu mungkin pesaing utama, dan saya bekerja sama dengan tim itu untuk memastikan tim itu akan mencakup kasus penggunaan ini.

Satu hal yang saya tunggu-tunggu, adalah alat yang berpotensi menerjemahkan PodSecurityPolicy --> kebijakan rego OPA. Itu akan membuat mencela mereka dari sudut pandang Anda jauh lebih mudah.

@tallclair menghargai tanggapan yang cepat

@SEJeff setuju. Kami tidak akan menghentikan PodSecurityPolicy sampai ada penggantian yang jelas dengan paritas fitur dan jalur migrasi.

Hai @tallclair , Anda menyebutkan peta jalan ke GA atau rencana penghentian. Sepertinya kita condong ke arah yang terakhir.

Apakah kita memiliki sesuatu yang ditulis untuk membantu orang-orang yang melihat PSP sebagai solusi menutup loop?

Belum. Bagian dari keraguan adalah bahwa kami tidak ingin mengatakan bahwa kami akan mencelanya demi sesuatu yang lain sampai ada pengganti yang jelas. Meskipun saya senang dengan gatekeeper, ia belum memiliki fitur (atau stabilitas) yang kami perlukan untuk mengganti PSP. Kemungkinan lain adalah bahwa kita dapat memindahkan PSP keluar dari pohon, dan membawanya ke GA sebagai webhook penerimaan (2 opsi tidak saling eksklusif). Kami belum secara resmi menyusun peta jalan.

Wtf

Hai @tallclair sepertinya tidak ada yang terjadi di sini untuk 1,16 juga jadi saya akan tetap sama.

Hai @tallclair -- 1,17 Peningkatan memimpin di sini -- sepertinya ini tetap seperti untuk 1,17. Jika itu berubah, jangan ragu untuk memberi saya colekan dan saya dapat menambahkannya ke lembar pelacakan 👍

Apakah sudah ada diskusi lagi tentang jalan yang jelas untuk masa depan PSP?

Iya benar sekali. Itu mungkin pesaing utama, dan saya bekerja sama dengan tim itu untuk memastikan itu akan mencakup kasus penggunaan ini.

@tallclair - kami telah menerapkan sebagian besar pemeriksaan PSP di Kyverno. Bisa bantu lihat? Ingin mendiskusikan ide dan detail.

https://github.com/nirmata/kyverno/blob/master/samples/README.md

Proyek Gatekeeper juga telah melihat seperti apa dunia pasca-PSP nantinya. Pendekatan awal kami telah memecah sumber daya PSP menjadi kendala individu . Kami bertanya-tanya apa pendapat masyarakat tentang pendekatan ini. Mungkin ini saat yang tepat untuk membayangkan kembali bagaimana kebijakan ini disusun? Migrasi untuk pengguna baru dan pengguna PSP yang sudah ada juga penting.

cc @maxsmythe @sozercan @tsandall

Saya memiliki beberapa kekhawatiran tentang memecah kebijakan menjadi batasan individu, yaitu bahwa saya perlu membuat lebih banyak objek batasan. Jika saya pikir perlu mengkloning atau mengubahnya untuk beban kerja yang berbeda, saya khawatir itu akan menjadi sangat kompleks.

Saya pikir pendekatan terbaik adalah pendekatan yang berpusat pada pengguna. Jika kita bisa mendapatkan umpan balik nyata tentang bagaimana PSP digunakan, dan kemudian melihat seperti apa pengaturan serupa di bawah plugin alternatif ini, maka itu dapat membantu membentuk desain.

@tallclair salah satu kasus penggunaan yang kami kejar terkait dengan multi-tenancy berbasis namespace. Tujuannya adalah menggunakan kebijakan untuk menerapkan pembatasan dan memastikan bahwa ruang nama dikonfigurasi dengan benar.

Sebelum ini bisa masuk ke GA, kita perlu memperbaiki masalah ini:

1. Model otorisasi yang cacat - penggunaan PSP diberikan melalui RBAC, dan dapat diberikan kepada pengguna, atau pod yang dibuat. Memberikannya kepada pengguna adalah pendekatan intuitif, tetapi bermasalah (lihat penjelasan). Pendekatan ini juga memiliki beberapa masalah keamanan.

@tallclair , saya ingin tahu tentang hal di atas -- dapatkah Anda menguraikan bagaimana pendekatan ini bermasalah dan/atau memiliki masalah keamanan?

Bisakah seseorang yang lebih tahu tolong konfirmasi tweet ini:

https://twitter.com/TechJournalist/status/1197658440040165377

Dan jika itu benar, apa yang harus dilakukan oleh orang-orang yang menggunakan PSP untuk membatasi kemampuan linux saat ini?

Halo semua,
Ini adalah diskusi yang sangat menarik dan kami sedang mencari solusi untuk mengamankan pembuatan Pod di cluster Kubernetes.

Kami telah melihat OPA Gatekeeper dan PodSecurityPolicies, serta upaya untuk mengimplementasikan kembali PSP dalam batasan OPA.
Masalah mendasar yang kami temukan dengan perbandingan ini adalah bahwa kami berhadapan dengan dua model yang berlawanan.

• OPA Gatekeeper mengikuti model open-by-default, di mana semuanya diperbolehkan dan admin melarang hal-hal tertentu dengan batasan.
• PSP mengikuti model closed-by-default, di mana semuanya dilarang dan admin mengizinkan hal-hal tertentu dengan kebijakan.

Dari perspektif keamanan, saya berpendapat bahwa model PSP lebih baik, meskipun lebih sulit untuk dibawa ke dalam cluster yang ada karena semua beban kerja harus sesuai dengannya.

Bagaimana Anda berencana untuk menjembatani kesenjangan mendasar dalam arsitektur ini, antara PSP dan Kerangka Batasan?

/cc @ritazh Saya ingin mendengar pendapat Anda tentang ini, karena Anda telah bekerja untuk mem-porting fungsionalitas PSP ke OPA.

Pendekatan yang berbeda pasti membuat migrasi lebih rumit. Kami sedang menjajaki berbagai cara untuk membuat transisi lebih lancar.

Di dunia yang sempurna, saya setuju bahwa tolak-semua-secara-default adalah pendekatan yang lebih aman. Namun, itu salah satu hal yang membuat PSP begitu sulit untuk digunakan dan diluncurkan. Dalam praktiknya, saya pikir secara bertahap menurunkan izin lebih layak, dan seperti pepatah lama "keamanan terbaik adalah keamanan yang Anda gunakan".

Sebagai tambahan, kami juga membahas cara memilih keluar / mengecualikan / mendapatkan pengecualian untuk batasan (misalnya untuk melindungi namespace sistem kube). Bergantung pada cara kerjanya, Anda dapat menerapkan pendekatan tolak secara default dengan mengunci semuanya, lalu memberikan pengecualian. Saya tidak yakin apakah itu use case yang ingin kami desain ...

@tallclair apakah Anda mengharapkan kemajuan dalam hal ini di 1.18? Saya bayangan perangkat tambahan untuk rilis dan ingin tahu apakah kita harus melacak ini.

Tidak ada perubahan yang direncanakan untuk 1.18

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, silakan lakukan dengan /close .

Kirim umpan balik ke sig-testing, kubernetes/test-infra dan/atau fejta .
/siklus hidup basi

/hapus siklus hidup basi

@tallclair Hai Tim. Ada rencana untuk ini di 1.19?

Tidak ada rencana untuk v1.19, meskipun saya berharap untuk melihat beberapa pergerakan dalam jangka waktu v1.20.

Baru saja menemukan Kebijakan Keamanan Pod Kubernetes dengan Agen Kebijakan Terbuka . @tallclair dapatkah Anda membagikan apa yang menghalangi kami dan di mana bantuan diperlukan, dengan senang hati berkontribusi juga.

dapatkah Anda membagikan apa yang memblokir kami?

Pada dasarnya kita hanya perlu membuat keputusan tentang jalan ke depan. Saat ini, saya pikir ada kesepakatan bahwa PSP tidak boleh GA dalam bentuk saat ini, tetapi kami belum menetapkan penggantinya. Opsi yang telah kita diskusikan:

1. Tidak ada penggantian - sarankan memilih dari opsi pihak ketiga dengan webhook masuk. Dokumen standar keamanan Pod yang baru-baru ini diterbitkan mencoba membuatnya lebih lancar dengan mempromosikan fungsionalitas yang setara.
2. Kontrol bawaan alternatif
   
   
   
   1. @deads2k telah mengusulkan upstreaming openshifts SecurityContextConstraints
   
   
   2. Saya telah mengusulkan fitur yang dapat dikonfigurasi secara minimal yang hanya memberlakukan kebijakan standar yang ditautkan di atas (dan merekomendasikan solusi pihak ketiga ketika diperlukan lebih banyak konfigurasi)
   
   
3. Perbaiki kebijakan keamanan pod - Meskipun beberapa masalah cukup inti untuk desain, bahwa ini harus tidak kompatibel-mundur, pada titik itu mungkin juga menjadi alternatif baru di (2)

Apakah saya membaca https://github.com/kubernetes/kubernetes/pull/90603 dengan benar bahwa karena standar keamanan pod diterbitkan, tidak ada rencana penggantian untuk PSP di server API dan penggantian apa pun perlu diterapkan sebagai sistem luar?

Lihat https://github.com/kubernetes/enhancements/issues/5#issuecomment -637066475

Jadwal penghentian untuk versi beta saat ini di 1.22 tidak tergantung pada apakah implementasi in-tree dari profil keamanan pod standar akan disediakan atau tidak. Itu belum ditentukan.

Terima kasih @liggitt mengonfirmasi bahwa tidak ada yang disetel. mengira awalnya tidak ada yang akan ditinggalkan sampai pengganti tersedia. Tidak jelas apakah keputusan telah dibuat dengan satu atau lain cara.

Garis waktu penghentian tidak khusus untuk PSP dan ditambahkan sebagai bagian dari https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1635-prevent-permabeta

jika saya membaca ini dengan benar, apa yang mendorong penghentian adalah bahwa tidak ada API yang harus dalam versi beta yang sama selama lebih dari 9 bulan sehingga PSP perlu dipromosikan atau ditinggalkan dan karena tidak akan ada beta atau GA baru dari psp itu perlu di jalur untuk penghentian meskipun penggantinya belum diputuskan?

jika saya membaca ini dengan benar, yang mendorong penghentian adalah bahwa tidak ada API yang harus dalam versi beta yang sama selama lebih dari 9 bulan

tepat. semua versi beta mendatang dari semua API bawaan akan hadir dengan target penghentian dan penghapusan yang telah dibuat sebelumnya saat pertama kali diperkenalkan

Hai @tallclair

Peningkatan Pimpin di sini. Ada rencana untuk ini di 1.20?

Terima kasih,
Kirsten

Tidak ada rencana untuk v1.20.

Situasi ini sangat membuat frustrasi bagi kita yang perlu menjalankan cluster keamanan tinggi. Pilihan kami adalah:

1. Duduk dan tunggu PSP tidak digunakan lagi.
2. Mengalihdayakan penegakan keamanan runtime beban kerja ke vendor (Styra), karena OPA tidak mendokumentasikan cara menjalankan penggantian PSP yang sepenuhnya membatasi dengan Rego.

Jadi, perusahaan saya telah menerapkan PSP yang dikunci sepenuhnya. Mereka tidak mudah diterapkan, dan men-debug mereka adalah tugas, tetapi mereka sangat fungsional, dan mereka benar-benar berfungsi. Kami bahkan menerbitkan posting blog yang merinci bagaimana mereka dapat digunakan dengan cara ini, dan bagaimana menangani pengecualian ketika itu terjadi.

IMO, PSP beta harus digabung apa adanya ke inti kubernetes arus utama. Alasan saya adalah:

1. Sementara PSP memiliki kekurangan, mereka berfungsi, dan telah berfungsi selama 10 rilis.
2. Kubernetes sebagai sebuah proyek harus memperhatikan keamanan runtime beban kerja. Pelepasan kontainer terlalu mudah. PSP adalah salah satu dari sedikit alat yang mempersulit penyerang.
3. Sempurna adalah musuh Selesai. Gabungkan PSP apa adanya, dan dorong implementasi "lebih baik" ke policy/v2.
4. Terakhir, dan yang paling penting, ini memungkinkan pengembang OSS untuk menjalankan cluster keamanan yang lebih tinggi, bukan hanya perusahaan yang mampu membeli vendor seperti Styra.

@ zapman449 dapatkah Anda mengklarifikasi apa yang Anda maksud dengan "penggantian PSP yang sepenuhnya membatasi"?

Semoga dengan adanya library Gatekeeper PSP semakin memudahkan penegakan aturan yang serupa dengan yang digunakan oleh PSP. Saya benar-benar tertarik dengan celah fungsional yang Anda lihat.

@ zapman449 apakah Anda memiliki tautan ke posting blog itu?

@christianhuening https://developer.squareup.com/blog/kubernetes-pod-security-policies

@maxsmythe Saya belum mengetahui apa yang dilakukan Gatekeeper PSP, akan ditinjau.

Namun, yang saya maksud adalah:

1. Kontrol penuh atas kemampuan proses seperti NET_BIND_SERVICE, SYS_ADMIN, dll
2. Batasi UID/GID/FSGroups ke nilai bukan nol
3. Daftar eksplisit jalur host yang dapat dipasang
4. Daftar eksplisit jenis pemasangan volume yang diizinkan
5. Blokir Hak Istimewa, blokir eskalasi hak istimewa
6. Blokir akses ke primitif komunikasi antarproses tingkat host
7. Blokir akses ke jaringan host
8. batasi port host mana yang diizinkan
9. Terapkan readOnlyRootFilesystem
10. Titik koneksi untuk SELinux

Ini disediakan hari ini dengan PSP.

Jika kami meminta daftar keinginan, saya akan senang:

1. Default cerdas untuk SysCalls dari wadah. Ada persentase kecil dari total daftar syscall linux yang dibutuhkan sebagian besar container. Izinkan saya membatasi sebagian besar container ke daftar itu, lalu izinkan saya secara eksplisit mengizinkan panggilan tertentu untuk pod tertentu yang dimiliki oleh akun layanan tertentu, atau untuk memberikan wewenang penuh kepada akun layanan tertentu.
2. Biarkan aku bermimpi sedikit lagi, dan aku akan menemukan sesuatu. ;-)

@zapman449 - Jika Anda belum melihatnya, kami membahas masa depan PSP di pertemuan terakhir sig-auth (https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/view#heading=h.hsgtsqg ). Kami akan melanjutkan diskusi pada pertemuan 9 Desember jika Anda mampu, tetapi kami juga tidak akan membuat keputusan akhir tanpa proposal yang dikirim ke milis.

Niat kami di sini sama sekali tidak meninggalkan siapa pun tinggi dan kering. Kita tahu bahwa PSP memenuhi kebutuhan keamanan yang penting untuk Kubernetes, dan tujuan dari diskusi ini adalah untuk mencari tahu cara terbaik untuk memenuhi kebutuhan tersebut di masa depan.