@derekwaynecarr @sttts @erictune tidak melihat masalah untuk ini tetapi sudah dalam alfa. Membuat ini sebagai pengingat untuk mendorongnya ke versi beta dan stabil.

@sttts bisakah Anda memberikan tautan yang sesuai ke dokumen dan PR? Saya pikir Anda paling dekat dengan kode ini.

@pweil- @sttts - menurut diskusi kami, ini adalah fitur yang ingin kami sponsori di Kubernetes 1.6 di bawah @kubernetes/sig-node

@pweil- @derekwaynecarr tolong, konfirmasikan bahwa fitur ini harus disetel dengan 1,6 milestone.

@idvoretskyi kami menargetkan untuk memindahkannya ke beta untuk 1.6.

@sttts terima kasih.

Sepertinya ini masih alfa:

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/seccomp.md
https://github.com/kubernetes/kubernetes/blob/master/pkg/api/annotation_key_constants.go#L35

Dan saya tidak dapat menemukan dokumentasi apa pun di kubernetes.io/docs.

@pweil- ada pembaruan untuk 1,8? Apakah fitur ini masih di jalur untuk rilis?

@idvoretskyi ini bukan prioritas untuk 1.8. @php-coder dapatkah Anda menambahkan kartu ini untuk perencanaan PM kami? Kita harus berhenti membiarkan ini jatuh melalui celah dan memindahkannya ke beta dan GA.

@pweil- jika fitur ini tidak direncanakan untuk 1,8 - tolong, perbarui pencapaian dengan "tonggak sejarah berikutnya" atau "1,9"

Saya ingin melihat ini sampai ke beta. Prioritas (atau persyaratan) untuk itu meliputi:

1. Anotasi (Pod & PodSecurityPolicy) harus dipindahkan ke field pada container SecurityContext (lihat https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md#alpha-field- dalam-versi-api yang sudah ada)
2. Tentukan format seccomp spesifikasi OCI , dan tentukan profil default Kubernetes (dapatkah kita menggunakan kembali Docker's?) https://github.com/kubernetes/kubernetes/issues/39128
   A. Cari tahu bagaimana profil Kubernetes dikirimkan ke runtime container melalui CRI (/cc @yujuhong @Random-Liu )
   B. docker/default harus tetap diizinkan jika runtime adalah buruh pelabuhan (untuk kompatibilitas mundur)
3. Profil default Kubernetes harus menjadi default baru. Untuk kompatibilitas mundur, ini HARUS menjadi perilaku opsional (yaitu dikendalikan bendera). https://github.com/kubernetes/kubernetes/issues/39845

Adakah yang tertarik untuk mendorong karya ini untuk pencapaian 1.9 (atau 1.10)? @jessfraz @kubernetes/sig-auth-feature-requests dan @kubernetes/sig-node-feature-requests Saya melihat Anda :wink:

Juga relevan: https://github.com/kubernetes/community/pull/660 (apakah kita perlu menyelesaikan keputusan dalam PR itu sebelum melanjutkan?)

/cc @destijl

Jika seseorang memiliki waktu dan ingin melakukannya, mereka dipersilakan dan saya
akan membantu menjawab pertanyaan apa pun

Pada 22 Sep 2017 20:54, "Tim Allclair (St. Clair)" [email protected]
menulis:

/cc @destijl https://github.com/destijl

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

ok saya akan memperbarui proposal dan memulai ini besok jika tidak ada orang lain yang mau;)

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

Hei @jessfraz tidak yakin apakah Anda mendapatkan ini - saya tidak punya bandwidth untuk mengkodekannya, tetapi senang membantu menguji ...

Masalah basi membusuk setelah 30 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle rotten .
Masalah busuk ditutup setelah 30 hari tambahan tidak aktif.

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 busuk
/hapus siklus hidup basi

Masalah busuk ditutup setelah 30 hari tidak aktif.
Buka kembali masalah dengan /reopen .
Tandai masalah sebagai baru dengan /remove-lifecycle rotten .

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

/buka kembali
/siklus hidup dibekukan
/hapus-siklus hidup busuk

@php-coder: Anda tidak dapat membuka kembali masalah/PR kecuali Anda yang menulisnya atau Anda ditugaskan untuk itu.

/buka kembali
/siklus hidup dibekukan

Pada Senin, 26 Maret 2018 pukul 07.07, k8s-ci-robot [email protected]
menulis:

@php-coder https://github.com/php-coder : Anda tidak dapat membuka kembali masalah/PR
kecuali Anda yang menulisnya atau Anda ditugaskan untuk itu.

Menanggapi hal ini
https://github.com/kubernetes/features/issues/135#issuecomment-376129291
:

/buka kembali
/siklus hidup dibekukan
/hapus-siklus hidup busuk

Petunjuk untuk berinteraksi dengan saya menggunakan komentar PR tersedia di sini
https://git.k8s.io/community/contributors/devel/pull-requests.md . Jika
Anda memiliki pertanyaan atau saran terkait dengan perilaku saya, silakan ajukan
masalah terhadap kubernetes/test-infra
https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:
gudang.

—
Anda menerima ini karena Anda berada di tim yang disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/features/issues/135#issuecomment-376129294 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ABG_p9EwKebniej_GySRKSvzrCMITOA1ks5tiMvrgaJpZM4KgBy_
.

@smarterclayton : Anda tidak dapat membuka kembali masalah/PR kecuali Anda yang menulisnya atau Anda ditugaskan untuk itu.

/buka kembali

@idvoretskyi : Anda tidak dapat membuka kembali masalah/PR kecuali Anda yang menulisnya atau Anda ditugaskan untuk itu.

Ihor 1, bot 0

@pweil- @php-coder @jessfraz
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

@wangzhen127 sedang mengerjakannya, tetapi tidak dapat ditugaskan karena dia belum menjadi anggota.

https://github.com/kubernetes/kubernetes/pull/62662
https://github.com/kubernetes/kubernetes/pull/62671

Terima kasih atas pembaruannya, Tim!
/hapus siklus hidup beku

@pweil- @tallclair -- Kami sedang melakukan satu sapuan lagi pada spreadsheet pelacakan Fitur 1.11 .
Maukah Anda mengisi bidang yang tidak lengkap/kosong untuk item baris fitur ini?

@pweil- @tallclair -- fitur ini telah dihapus dari pencapaian 1.11, karena tidak ada pembaruan, kemajuan, atau dokumen.

cc: @jberkus

@pweil- @tallclair @kubernetes/sig-auth-feature-requests @kubernetes/sig-node-feature-requests --

Fitur ini telah dihapus dari pencapaian sebelumnya, jadi kami ingin memeriksa dan melihat apakah ada rencana untuk ini di Kubernetes 1.12.

Jika demikian, pastikan bahwa masalah ini mutakhir dengan SEMUA informasi berikut:

• Deskripsi fitur satu baris (dapat digunakan sebagai catatan rilis):
• Kontak utama (penerima tugas):
• SIG yang bertanggung jawab:
• Tautan proposal desain (repo komunitas):
• Tautan ke e2e dan/atau pengujian unit:
• Peninjau - (untuk LGTM) merekomendasikan agar 2+ pengulas (setidaknya satu dari file PEMILIK area kode) setuju untuk meninjau. Peninjau dari beberapa perusahaan lebih disukai:
• Penyetuju (kemungkinan dari SIG/area tempat fitur tersebut dimiliki):
• Target fitur (target mana yang sama dengan pencapaian yang mana):
  
  
  
  • Target rilis alfa (xy)
  
  
  • Target rilis beta (xy)
  
  
  • Target rilis stabil (xy)
  
  

Harap dicatat bahwa Pembekuan Fitur adalah 31 Juli, setelah itu setiap masalah Fitur yang tidak lengkap akan memerlukan permintaan Pengecualian untuk diterima ke dalam pencapaian.

Selain itu, harap perhatikan tenggat waktu yang relevan berikut ini:

• Batas waktu dokumen (PR placeholder terbuka): 21/8
• Pembekuan kasus uji: 8/28

Pastikan semua PR untuk fitur memiliki catatan rilis yang relevan juga disertakan.

Selamat pengiriman!

/cc @justaugustus @kacole2 @robertsandoval @rajendar38

Tidak ada perubahan yang direncanakan untuk 1,12

Terima kasih atas pembaruannya, @tallclair!

Adakah yang tertarik untuk mendorong karya ini untuk pencapaian 1.9 (atau 1.10)? @jessfraz @kubernetes/sig-auth-feature-requests dan @kubernetes/sig-node-feature-requests Aku melihatmu mengedipkan mata

@tallclair Saya dapat mencoba mengambil ini sekarang jika masih diinginkan

@stlaz : Mengulangi penyebutan untuk memicu pemberitahuan:
@kubernetes/sig-auth-feature-requests, @kubernetes/sig-node-feature-requests

@stlaz , fitur ini masih diinginkan. Saya telah meluangkan waktu untuk menambahkan profil seccomp ke addons sebagai langkah pertama #39845 . Tapi saya tidak punya cukup waktu untuk mendorong fitur tersebut. Alangkah baiknya jika Anda suka mengerjakan ini. Bantuan apa pun diterima! :)

@ wangzhen127 Terima kasih, saya mencoba membahas hal-hal yang telah dilakukan dan masalah terbuka terkait dengan fitur ini. Tampaknya komentar https://github.com/kubernetes/features/issues/135#issuecomment -331592961 masih memegang dan merangkum dengan tepat pekerjaan yang perlu dilakukan sekarang.

Saya juga memperhatikan Anda mencoba menambahkan FeatureGate untuk ini, tetapi menutup PR, mengapa demikian?

PS: Maaf atas keterlambatan respon, saya pergi sebentar.

Tampaknya komentar #135 (komentar) masih memegang dan meringkas dengan tepat pekerjaan yang perlu dilakukan sekarang.

Itu benar. Satu hal lagi yang ingin saya tambahkan adalah memiliki mode "keluhan". Jadi pengguna memiliki pilihan untuk mendapatkan peringatan (dalam log) menggunakan syscalls terlarang daripada membunuh. Mencatat tindakan seccomp tersedia dengan kernel Linux 4.14+ ( seccomp doc ). Ada kemungkinan bahwa versi kernel yang lebih lama masih digunakan. Jadi kita perlu menangani itu. Ini juga perlu ditambahkan ke spesifikasi OCI.

Saya juga memperhatikan Anda mencoba menambahkan FeatureGate untuk ini, tetapi menutup PR, mengapa demikian?

Tujuan dari gerbang fitur itu adalah untuk mengubah profil default seccomp dari tidak dibatasi menjadi "runtime/default". Saya mendapat banyak kekhawatiran tentang kompatibilitas ke belakang, sehingga sepertinya tidak mungkin terjadi. Kami saat ini tidak memiliki rencana untuk mengubah default keamanan secara umum karena itu melanggar. Pendekatan terbaik yang menurut saya saat ini adalah mendorong seccomp ke stabil dan itu masih harus menjadi fitur opt-in daripada opt-out.

Mencatat tindakan seccomp tersedia dengan kernel Linux 4.14+ ( seccomp doc ).

Saya kira karena kita akan mendefinisikan format seccomp default khusus Kubernetes sebagai bagian dari langkah kedua, kita juga bisa memiliki format yang akan masuk sebagai gantinya. Apakah ada nilai yang cukup untuk itu? Bisakah itu digunakan bagi orang untuk beralih dari "tidak terbatas" ke "kube/default" ketika yang terakhir gagal terlalu banyak? Apakah mereka peduli untuk beralih-ke-switch-back?
Ada distribusi LTS yang menggunakan kernel 4.13- Linux (Debian - 8,9; RHEL - 6, 7; Ubuntu LTS - 14.04, 16.04), jadi kompatibilitas Kernel jelas merupakan sesuatu yang perlu diingat.

Saya mendapat banyak kekhawatiran tentang kompatibilitas ke belakang, sehingga sepertinya tidak mungkin terjadi.

Runtime container harus melalui perubahan ini di masa lalu juga, ketika mereka mengaktifkan seccomp untuk pertama kalinya. Saat ini setidaknya kapal buruh pelabuhan dengan perilaku default yang kurang memungkinkan daripada "tidak dibatasi", yang mungkin dapat merusak seseorang. Saya tidak berpikir kita melakukan sesuatu yang salah jika kita hanya mengikuti perilaku komponen yang mendasarinya (yang juga menyediakan pilihan untuk mematikan perilaku ini).

Apakah ada nilai yang cukup untuk itu?

Ini bisa didiskusikan. Pikiran awal saya adalah mengubah default dari unconfined menjadi logging. Jadi kami tidak memiliki masalah kompatibilitas ke belakang. Dan jika kami entah bagaimana dapat mengumpulkan data dan menunjukkan bahwa dalam X% kasus, kami tidak melihat apa pun yang dicatat, yang berarti profil default tidak akan merusak banyak hal. Kemudian kami dapat mengusulkan untuk mengubah logging menjadi kill. Mengumpulkan bagian data itu rumit dan bisa jadi banyak pekerjaan. Bahkan jika kita tidak benar-benar menempuh rute itu, saya pikir memiliki profil logging akan bermanfaat bagi orang-orang ketika mereka ingin mencoba seccomp tetapi belum percaya diri.

Runtime container harus melalui perubahan ini di masa lalu juga, ketika mereka mengaktifkan seccomp untuk pertama kalinya. Saat ini setidaknya kapal buruh pelabuhan dengan perilaku default yang kurang memungkinkan daripada "tidak dibatasi", yang mungkin dapat merusak seseorang. Saya tidak berpikir kita melakukan sesuatu yang salah jika kita hanya mengikuti perilaku komponen yang mendasarinya (yang juga menyediakan pilihan untuk mematikan perilaku ini).

Ketika buruh pelabuhan mengubah nilai default, kubernetes secara eksplisit mengatur ulang nilai tersebut menjadi tidak dibatasi. Saya menghubungi orang-orang arsitektur secara offline sebelumnya dan mereka sangat khawatir tentang masalah kompatibilitas ke belakang.

Dan jika kami entah bagaimana dapat mengumpulkan data dan menunjukkan bahwa dalam X% kasus, kami tidak melihat apa pun yang dicatat, yang berarti profil default tidak akan merusak banyak hal.

Aku suka ide ini. Bagian yang sulit tentu saja mendapatkan datanya, saya tidak tahu bagaimana cara melakukannya. Juga, pertama-tama kita harus mengusulkan perubahan ini ke spesifikasi OCI dan kemudian mungkin mengimplementasikannya untuk setidaknya satu runtime container, bukan? Apakah itu boleh terjadi di bagian Beta dari siklus hidup?

Ketika buruh pelabuhan mengubah nilai default, kubernetes secara eksplisit mengatur ulang nilai tersebut menjadi tidak dibatasi. Saya menghubungi orang-orang arsitektur secara offline sebelumnya dan mereka sangat khawatir tentang masalah kompatibilitas ke belakang.

Jadi begitu. Mungkin kita memang bisa menggunakan profil "tidak dibatasi" sebagai profil default (mungkin menggantinya dengan sesuatu seperti kube/logging nanti). Tampaknya ini mungkin akan lebih dikendalikan oleh PSP dengan cara penolakan-aturan, di mana kita mulai dengan asumsi bahwa semuanya diizinkan secara default dan kita hanya memotong hak istimewa lebih lanjut. Memiliki kontrol bendera atas ini mungkin berguna untuk kasus-kasus di mana PSP dimatikan, sehingga seseorang harus masuk juga, namun menggunakan kedua mekanisme ini sekaligus mungkin akan sedikit berantakan.

Saya kira itu arah yang sedikit berbeda dari yang dianggap semula - itu bertentangan dengan pekerjaan yang dilakukan di https://github.com/kubernetes/kubernetes/issues/39845 , tetapi jika kita menyetujui hal di atas, kita harus memikirkan profil seccomp kami akhirnya akan mengirimkan. Sejauh ini saya melihat runtime/default , kube/default , kube/logging , bersama dengan opsi untuk mengatur profil ke unconfined . Selebihnya tentu saja kemampuan untuk memiliki profil localhost/.* , yang sudah disediakan oleh implementasi saat ini.

Apakah itu boleh terjadi di bagian Beta dari siklus hidup?

Terdengar bagus untukku. Meskipun saya pikir itu membantu untuk memulai proposal spesifikasi OCI lebih awal.

Pergi dengan "tidak terbatas" sebagai default untuk saat ini terdengar bagus untuk saya. Untuk kubernetes/kubernetes#39845, saya menambahkan anotasi ke addons. Dan saya tidak berpikir kita bisa melangkah lebih jauh.

Sejauh ini saya melihat runtime/default, kube/default, kube/logging, bersama dengan opsi untuk mengatur profil menjadi tidak dibatasi. Selebihnya tentu saja kemampuan untuk memiliki profil localhost/.*, yang sudah disediakan oleh implementasi saat ini.

Bekerja untuk saya. Untuk kube/default , kita bisa mulai dengan docker/default .

Mencatat tindakan seccomp tersedia dengan kernel Linux 4.14+ (seccomp doc).

Pemahaman saya adalah ini mencatat tindakan dengan PID - belum tentu info terkait wadah. Jadi baik auditd atau daemon lain di Host perlu melakukan pencarian/pemetaan agar log benar-benar berguna ...

Dan jika kami entah bagaimana dapat mengumpulkan data dan menunjukkan bahwa dalam X% kasus, kami tidak melihat apa pun yang dicatat, yang berarti profil default tidak akan merusak banyak hal. Kemudian kami dapat mengusulkan untuk mengubah logging menjadi kill. Mengumpulkan bagian data itu rumit dan bisa jadi banyak pekerjaan.

Bukankah @jessfraz sudah melakukannya saat meluncurkan profil default buruh pelabuhan untuk buruh pelabuhan? Jika itu bukan sinyal yang cukup kuat, akan sangat sulit untuk mengumpulkan sinyal yang lebih kuat...

@tallclair Anda benar, saya agak tersesat dalam semua komentar masalah. Untuk referensi, inilah komentar yang menyatakan Dockerfiles diperiksa: https://github.com/kubernetes/community/pull/660#issuecomment -303860107. Saya kira kita bisa aman memiliki default "membunuh".

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 sejenak untuk memperbarui pencapaian pada kiriman asli Anda untuk pelacakan di masa mendatang dan ping ke @kacole2 jika perlu disertakan dalam Lembar Pelacakan Penyempurnaan 1.13

Terima kasih!

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

Masalah peningkatan yang dibuka di kubernetes/enhancements tidak boleh ditandai sebagai dibekukan.
Pemilik Penyempurnaan dapat memastikan bahwa perangkat tambahan tetap segar dengan memperbarui status mereka secara konsisten di seluruh siklus rilis.

/hapus siklus hidup beku

Masalah basi membusuk setelah 30 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle rotten .
Masalah busuk ditutup setelah 30 hari tambahan tidak aktif.

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 busuk

/hapus-siklus hidup busuk

Halo @stlaz @pweil- , 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. Ini juga akan membutuhkan KEP untuk dimasukkan ke dalam 1,15

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

tidak ada perubahan yang direncanakan untuk 1,15

Hai @tallclair @pweil- @stlaz , saya Pemimpin/Bayangan Peningkatan 1.16. Apakah fitur ini akan lulus tahap alfa/beta/stabil di 1.16? Tolong beri tahu saya agar dapat ditambahkan ke 1,16 Pelacakan Spreadsheet . Jika tidak lulus, saya akan menghapusnya dari tonggak sejarah dan mengubah label yang dilacak.

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

Sebagai pengingat, setiap penyempurnaan memerlukan KEP dalam kondisi yang dapat diterapkan dengan Kriteria Kelulusan yang menjelaskan setiap persyaratan tahapan alfa/beta/stabil.

Tanggal pencapaian adalah Enhancement Freeze 30/7 dan Code Freeze 29/8.

Terima kasih.

Saya memiliki rencana awal untuk membawanya ke GA, tetapi mungkin akan sulit untuk mencapainya di 1,16. Saya akan mencoba mengeluarkan proposal dengan pembekuan perangkat tambahan.

Halo @tallclair @pweil- , 1.17 Enhancement Shadow di sini! 🙂

Saya ingin menghubungi untuk melihat *apakah peningkatan ini akan ditingkatkan ke alfa/beta/stabil di 1.17?
Harap beri tahu saya agar peningkatan ini dapat ditambahkan ke lembar pelacakan 1,17 .

Terima kasih!

Pengingat Ramah

• Jadwal rilis saat ini adalah
  
  
  
  • Senin, 23 September - Siklus Rilis Dimulai
  
  
  • Selasa, 15 Oktober, EOD PST - Enhancements Freeze
  
  
  • Kamis, 14 November, EOD PST - Pembekuan Kode
  
  
  • Selasa, 19 November - Dokumen harus dilengkapi dan ditinjau
  
  
  • Senin, 9 Desember - Kubernetes 1.17.0 Dirilis
  
  

• Proposal Penyempurnaan Kubernetes (KEP) harus memenuhi kriteria berikut sebelum Pembekuan Penyempurnaan agar dapat diterima ke dalam rilis

  • PR digabung menjadi
  • Dalam keadaan implementable
  • Sertakan rencana ujian dan kriteria kelulusan

• Semua PR k/k yang relevan harus dicantumkan dalam edisi ini

Ya, saya berencana untuk lulus ini ke stabil di v1.17 - KEP di sini: https://github.com/kubernetes/enhancements/pull/1148

Hai @tallclair , saya akan menambahkan peningkatan ini ke lembar pelacakan untuk dilacak 👍

Silakan lihat pesan di atas untuk pengingat ramah dan perhatikan bahwa KEP dalam status sementara . KEP harus dalam keadaan yang dapat diimplementasikan untuk ditambahkan ke rilis 1,17.

/ tonggak sejarah v1.17
/stadium stabil

Hai @tallclair Bisakah Anda memposting tautan ke tes di testgrid dan melacak setiap tes yang ditambahkan untuk peningkatan ini?

Terima kasih!

Akan melakukan. Sudah ada banyak tes seccomp, tetapi saya tidak dapat menemukannya di tab dasbor mana pun (apakah ada cara untuk mencari di semua testgrid untuk tes tertentu?)
https://github.com/kubernetes/kubernetes/blob/0956acbed17fb71e76e3fbde89f2da9f8ec8b603/test/e2e/node/security_context.go#L147 -L177

@tallclair tidak ada cara yang baik untuk mencari di semua testgrid =/

Tebakan terbaik saya (setidaknya untuk 4 yang Anda referensikan) adalah bahwa mereka sebenarnya tidak disertakan. 😬

Sepertinya mereka harus menjadi bagian dari dashboard node-kubelet-features , tetapi konfigurasi pekerjaan untuk ci-kubernetes-node-kubelet-features memiliki ini untuk test_args :

--test_args=--nodes=8 --focus="\[NodeFeature:.+\]" --skip="\[Flaky\]|\[Serial\]"

Tes ginkgo sendiri ditandai dengan [Feature:Seccomp] dan bendera fokus tidak akan cocok.

Saya pikir kita harus menghapus tag fitur setelah ini pindah ke GA. Saya pikir seccomp adalah standar di linux, jadi tag [LinuxOnly] sudah cukup.

Untuk masalah umum tes yang tidak dijalankan, saya mengajukan https://github.com/kubernetes/test-infra/issues/14647

Hai @tallclair , Kami hanya 5 hari lagi dari Enhancements Freeze (Selasa, 15 Oktober, EOD PST) . Pengingat ramah lainnya bahwa untuk dapat lulus ini dalam rilis 1.17, KEP harus digabung dan harus dalam kondisi yang dapat diimplementasikan. Sepertinya KEP masih buka dan dalam keadaan sementara.

Hai @tallclair , sayangnya batas waktu pembekuan peningkatan 1.17 telah berlalu dan sepertinya KEP masih terbuka. Saya akan menghapus peningkatan ini dari pencapaian 1,17.

Harap dicatat bahwa Anda dapat mengajukan pengecualian peningkatan jika Anda perlu mendapatkan ini untuk 1.17

/pencapaian jelas

Ya, tidak berhasil. Berharap untuk memasukkannya ke dalam
/ tonggak sejarah v1.18

Boleh juga! Saya akan menandai ini sebagai ditangguhkan ke v1.18 di lembar pelacakan peningkatan .

Hei , apakah ada yang bisa kita lakukan untuk memajukan yang satu ini. Saya akan senang untuk berkontribusi di sini serta untuk masalah AppArmor.

Hai @tallclair

1.18 Tim peningkatan check-in! Apakah Anda berencana untuk lulus ke stable di 1.18? Sepertinya KEP masih buka.

Jadwal rilisnya sebagai berikut:

Tingkatkan Pembekuan: 28 Januari
Pembekuan Kode: 5 Maret
Dokumen Siap: 16 Maret
v1.18 Rilis: 24 Maret

Sebagai pengingat, KEP perlu digabungkan, dengan status disetel ke implementable .

Terima kasih!

@saschagrunert terima kasih atas tawarannya! Saya perlu mengambil izin lain di KEP untuk menindaklanjuti ulasan API yang saya miliki dengan @liggitt. Setelah KEP disetujui, saya akan menerima bantuan Anda dalam implementasinya.

Saya pikir pertanyaan terbuka terbesar di KEP saat ini adalah bagaimana menangani tipe profil localhost. Karena kami ingin menghentikan fitur tersebut (idealnya mendukung sesuatu seperti https://github.com/kubernetes/enhancements/pull/1269, /cc @pjbgf ), saya ingin menghindari menempatkan bidang untuk itu di API .

Hai @tallclair , ada pembaruan apakah ini akan membuatnya menjadi 1,18 atau tidak? Saat ini ditandai dalam tonggak sejarah tetapi Anda belum mengonfirmasi apakah kami harus melacak ini atau tidak.

Terima kasih!

v1.18 tampaknya tidak mungkin untuk ini. Saya pikir kita bisa bertemu
/tonggak sejarah v1.19

Hebat, terima kasih atas pembaruannya @tallclair :)

Hai @tallclair -- 1.19 Enhancements Lead di sini, apakah Anda berencana untuk meningkatkan Enhancement ini ke stable rilis ini?

Tidak ada rencana untuk lulus di v1.19. Saya memiliki KEP terbuka, tetapi tidak akan bekerja pada kuartal ini. @pjbgf dapat mengambilnya di v1.20

@tallclair -- Terima kasih atas pembaruannya. :slightly_smiling_face:

/tonggak sejarah v1.20

Ada sedikit perubahan rencana yang satu ini - seperti yang disepakati pada pertemuan tanda tangan kemarin. Ini sekarang direncanakan untuk:

/tonggak sejarah v1.19

@pjbgf : Anda harus menjadi anggota tim GitHub kubernetes/milestone-maintainers untuk menetapkan pencapaian. Jika Anda yakin Anda dapat mengeluarkan perintah / milestone, harap hubungi Anda dan minta mereka mengusulkan Anda sebagai delegasi tambahan untuk tanggung jawab ini.

@palnabarun Apakah Anda keberatan mengatur masalah ini ke tonggak v1.19?

/tugaskan pjbgf

/tonggak sejarah v1.19

Terima kasih @pjbgf @tallclair untuk pembaruannya. Saya telah memperbarui lembar pelacakan sesuai dengan rencana Anda.

Bisakah Anda memberi tahu saya tahap kelulusan mana yang Anda targetkan dan tautan ke KEP?

Terima kasih! Hargai semua usahanya. :slightly_smiling_face:

Jadwal rilis saat ini adalah:

• Senin, 13 April: Minggu 1 - Siklus rilis dimulai
• Selasa, 19 Mei: Minggu 6 - Enhancements Freeze
• Kamis, 25 Juni: Minggu 11 - Pembekuan Kode
• Kamis, 9 Juli: Minggu 14 - Dokumen harus diselesaikan dan ditinjau
• Selasa, 4 Agustus: Minggu 17 - Kubernetes v1.19.0 dirilis

Menargetkan GA

KEP: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md
KEP masih memiliki bagian yang belum terselesaikan, dengan PR tindak lanjut: https://github.com/kubernetes/enhancements/pull/1747

Hai @tallclair , terima kasih atas pembaruannya. :+1:

Saya telah memperbarui lembar pelacakan yang sesuai.

PS: Saya telah memperbarui deskripsi masalah dengan tautan ke KEP dan PR pembaruan KEP terbaru.

terima kasih @palnabarun untuk pembaruannya. :+1:

Hai @tallclair 1.19 dokumen bayangan di sini! Apakah pekerjaan peningkatan yang direncanakan untuk 1.19 ini memerlukan dokumen baru atau modifikasi?

Pengingat ramah bahwa jika baru/modifikasi dokumen diperlukan, PR placeholder terhadap k/website (cabang dev-1.19 ) diperlukan pada hari Jumat, 12 Juni.

@annajung itu untuk perhatian. Ya, akan ada beberapa modifikasi pada seccomp docs.

Menambahkan @hasheddan yang mengambil ini (https://github.com/kubernetes/kubernetes/issues/58211).

Bagus, terima kasih atas pembaruannya! Saya akan memodifikasi lembar pelacakan yang sesuai.
Harap beri tahu kami setelah PR placeholder terhadap k/situs web telah dibuat. Terima kasih!

@pjbgf -- Bisakah Anda menautkan ke semua PR implementasi di sini - k/k atau sebaliknya? :slightly_smiling_face:

Jadwal rilis saat ini adalah:

• ~Senin, 13 April: Minggu 1 - Siklus rilis dimulai~
• ~Selasa, 19 Mei: Minggu 6 - Enhancements Freeze~
• Kamis, 25 Juni: Minggu 11 - Pembekuan Kode
• Kamis, 9 Juli: Minggu 14 - Dokumen harus diselesaikan dan ditinjau
• Selasa, 4 Agustus: Minggu 17 - Kubernetes v1.19.0 dirilis

@palnabarun inilah yang saat ini:
https://github.com/kubernetes/kubernetes/pull/91381
https://github.com/kubernetes/kubernetes/pull/91408
https://github.com/kubernetes/kubernetes/pull/91182
https://github.com/kubernetes/kubernetes/pull/91442

Saya juga membuat masalah payung yang berisi semuanya.

Hai @pjbgf @hasheddan Sekedar pengingat bahwa PR placeholder terhadap k/website akan jatuh tempo pada hari Jumat, 12 Juni. Tolong beri tahu saya setelah Anda membuat PR, terima kasih!

@annajung terima kasih sudah mengingatkan! Akan segera dibuka :+1:

Hai @pjbgf -- Terima kasih telah membuat masalah payung. :+1:

Kami melacak hal yang sama. :slightly_smiling_face:

Hai @pjbgf -- hanya ingin memeriksa tentang kemajuan peningkatan.

Garis waktu rilis telah direvisi baru-baru ini, detail lebih lanjut dapat ditemukan di sini .

Tolong beri tahu saya jika Anda memiliki pertanyaan. :slightly_smiling_face:

Jadwal rilis yang direvisi adalah:

• Kamis, 9 Juli: Minggu 13 - Pembekuan Kode
• Kamis, 16 Juli: Minggu 14 - Dokumen harus diselesaikan dan ditinjau
• Selasa, 25 Agustus: Minggu 20 - Kubernetes v1.19.0 dirilis

Terima kasih updatenya @palnabarun. Kode sebagian besar sudah selesai, tetapi kami sekarang menunggu tinjauan lanjutan. Secara keseluruhan, kami masih terlihat bagus. :+1:

Hai @pjbgf @hasheddan , pengingat ramah tentang tenggat waktu berikutnya yang akan datang.
Harap ingat untuk mengisi PR dokumen placeholder Anda dan menyiapkannya untuk ditinjau paling lambat Senin, 6 Juli.

Hai @pjbgf @hasheddan :wave:, Saya melihat masih ada 3 item tindakan yang tertunda di https://github.com/kubernetes/kubernetes/issues/91286 untuk perubahan terkait implementasi dan 1 item tindakan yang tertunda untuk dokumentasi. Apakah Anda pikir mereka akan berhasil melewati pembekuan kode pada Kamis, 9 Juli?

Terima kasih. :slightly_smiling_face:

Code Freeze dimulai pada hari Kamis, 9 Juli EOD PST

@palnabarun docs PR sebagian besar sudah siap, hanya menambahkan panduan khusus untuk seccomp. Sudah memiliki LGTM dari @saschagrunert tentang perubahan saat ini. Terima kasih telah menjaga kami tetap di sini :)

Hai @hasheddan , terima kasih atas pembaruan di atas. Sekedar pengingat cepat untuk menyiapkan PR dokumen Anda untuk ditinjau (Hapus WIP/berbasis ulang/semua siap digunakan) oleh EOD. Terima kasih!

@annajung akan melakukannya! Terima kasih!

@hasheddan -- Terima kasih atas pembaruannya. :senyum:

@pjbgf -- Saya melihat bahwa di https://github.com/kubernetes/kubernetes/issues/91286 dua item tindakan inti belum digabungkan dan juga tidak ada dalam kumpulan gabungan. Apakah Anda pikir mereka akan masuk sebelum Code Freeze?

Terima kasih. :slightly_smiling_face:

@palnabarun kami mencoba menyelesaikannya sebelum kode dibekukan, setelah semuanya sudah lgtm. Kami mengalami beberapa masalah dengan beberapa tes atm yang tidak stabil. 😅

Terima kasih atas perhatiannya.

Untuk kejelasan 2 prs yang kami tunggu untuk digabungkan adalah:
https://github.com/kubernetes/kubernetes/pull/91408 dan https://github.com/kubernetes/kubernetes/pull/92856

Yang terakhir (https://github.com/kubernetes/kubernetes/pull/92856) tampaknya gagal dalam pemeriksaan verifikasi. Menurut https://github.com/kubernetes/kubernetes/pull/92856#issuecomment -655950700 ini akan memerlukan rebase/repush/rereview sebelum dapat bergabung..

@kikisdeliveryservice terima kasih atas klarifikasinya. Kami sedang menunggu tes yang tidak stabil di https://github.com/kubernetes/kubernetes/pull/91408 untuk berhenti gagal, setelah digabungkan, kami dapat melakukan rebase PR kedua yang bergantung padanya.

Hai @pjbgf :wave:, Kita masuk ke Code Freeze sekarang.

Karena, https://github.com/kubernetes/kubernetes/pull/91408 ada di kumpulan gabungan dan https://github.com/kubernetes/kubernetes/pull/92856 memerlukan rebase melalui https://github.com/ kubernetes/kubernetes/pull/91408 menurut https://github.com/kubernetes/kubernetes/pull/92856#issuecomment -655950700 , kami merasa bahwa tindakan terbaik di sini adalah mengajukan permintaan pengecualian untuk mendapatkan waktu tambahan dalam menyelesaikan yang kedua PR setelah kumpulan gabungan menjadi jelas.

Menghapus peningkatan dari tonggak untuk saat ini.

Terima kasih!

Terbaik,
Tim Peningkatan Rilis Kubernetes v1.19

/pencapaian jelas

Karena, kubernetes/kubernetes#91408 berada di kumpulan gabungan dan kubernetes/kubernetes#92856 memerlukan rebase atas kubernetes/kubernetes#91408 menurut kubernetes/kubernetes#92856 (komentar), kami merasa bahwa tindakan terbaik di sini adalah mengajukan pengecualian permintaan untuk mendapatkan waktu tambahan dalam menyelesaikan PR kedua setelah kumpulan gabungan selesai.

Rebase pada PR yang disetujui dalam antrian gabungan tidak memerlukan permintaan pengecualian. PR adalah kode lengkap dan disetujui sehari penuh sebelum batas waktu.

Hai @liggitt :wave:, terima kasih atas masukannya. :+1:

Kami akan memasukkan peningkatan kembali ke dalam siklus. Semua kekhawatiran kami tentang rebase. Karena itu diurutkan, ini bagus untuk dilakukan. :slightly_smiling_face:

/tonggak sejarah v1.19

@pjbgf @saschagrunert @hasheddan -- terima kasih atas semua kontribusi Anda. :100:

Terima kasih @palnabarun atas detail pelacakan peningkatannya. Kami menghargai itu! 🙏

@saschagrunert akhirnya PR kubernetes/kubernetes#92856 bergabung. Selamat! Saya akan memperbarui lembar pelacakan untuk mencerminkan hal ini.

@tallclair @pjbgf menurut Anda kami dapat menutup masalah ini sekarang karena seccomp adalah GA?

@saschagrunert Kami biasanya menunggu rilis terjadi, lalu tandai KEP yang sesuai sebagai implemented dan kemudian tutup masalah peningkatan.

Silakan lanjutkan dan lakukan perubahan untuk menandai https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md sebagai implemented . :slightly_smiling_face:

@saschagrunert Kami biasanya menunggu rilis terjadi, lalu tandai KEP yang sesuai sebagai implemented dan kemudian tutup masalah peningkatan.

Silakan lanjutkan dan lakukan perubahan untuk menandai https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md sebagai implemented .

Terima kasih atas klarifikasinya, buka PR di https://github.com/kubernetes/enhancements/pull/1932

KEP telah diperbarui untuk diimplementasikan (PR akhirnya digabungkan!)

Jangan ragu untuk menutup masalah ini @saschagrunert

Terima kasih semua untuk semua pekerjaan Anda!!

/pencapaian jelas

/Menutup
Itu selesai.

@saschagrunert Saya tidak ingat apakah kita membahas ini sebelumnya, tetapi apakah ada rencana untuk akhirnya membersihkan anotasi (yaitu menghapus dukungan)? Motivasi utama untuk melakukannya adalah agar alat pihak ke-3 (misalnya gatekeeper, krail) tidak perlu tahu untuk memeriksa anotasi & bidang

@saschagrunert Saya tidak ingat apakah kita membahas ini sebelumnya, tetapi apakah ada rencana untuk akhirnya membersihkan anotasi (yaitu menghapus dukungan)? Motivasi utama untuk melakukannya adalah agar alat pihak ke-3 (misalnya gatekeeper, krail) tidak perlu tahu untuk memeriksa anotasi & bidang

Ya, ini direncanakan untuk v1.23. Ini digabungkan dengan mekanisme peringatan (belum dilakukan), yang dapat dilakukan setelah fungsi utilitas yang diperlukan ada (ref https://github.com/kubernetes/kubernetes/issues/94626).

Dari KEP:

Untuk meningkatkan kesadaran penggunaan anotasi (dalam kasus otomatisasi lama), mekanisme peringatan akan digunakan untuk menyoroti bahwa dukungan akan dihentikan di v1.23. Mekanisme yang dipertimbangkan adalah anotasi audit, anotasi pada objek, peristiwa, atau peringatan seperti yang dijelaskan dalam KEP #1693.

…

Karena kami mendukung hingga 2 rilis minor versi miring antara master dan node, anotasi harus terus didukung dan diisi ulang untuk setidaknya 2 versi yang lulus implementasi awal. Namun, kita dapat memutuskan untuk memperpanjang dukungan lebih jauh untuk mengurangi kerusakan. Jika fitur ini diterapkan di v1.19, saya mengusulkan v1.23 sebagai target untuk menghapus perilaku lama.

Apakah Anda lebih suka membuka kembali masalah ini sampai bit-bit itu diimplementasikan juga?

Ya, biarkan ini tetap terbuka sampai fitur selesai sepenuhnya. Apakah ada masalah ak/k yang diajukan untuk pekerjaan yang Anda jelaskan?

Ya, biarkan ini tetap terbuka sampai fitur selesai sepenuhnya. Apakah ada masalah ak/k yang diajukan untuk pekerjaan yang Anda jelaskan?

Sekarang kami memilikinya, di sana: https://github.com/kubernetes/kubernetes/issues/95171 :)