SGTM. @kubernetes/kubectl ada pemikiran tentang ini?

Ini bukannya tidak masuk akal, tetapi kami memerlukan kebijakan keamanan pod untuk mengontrol input pengguna dan kami mungkin harus melarang nama pengguna (karena kami tidak mengizinkannya untuk container - Anda harus menentukan UID).

@sttts dan @ncdc re exec

Kasus penggunaan yang sah

Ada pembaruan tentang ini?

Gambar wadah aplikasi saya dibuat menggunakan buildpacks. Saya ingin membuka cangkang. Ketika saya melakukannya, saya root, dan semua env vars disetel. Tetapi lingkungan yang dihasilkan buildpack tidak ada di sana. Jika saya membuka shell login untuk pengguna aplikasi ( su -l u22055 ) saya memiliki lingkungan aplikasi saya, tetapi sekarang kubernetes env vars hilang.

Saya pikir su -l tidak menyalin env vars? Anda harus secara eksplisit melakukan penyalinan
sendiri atau gunakan perintah yang berbeda.

Pada Selasa, 11 Okt 2016 jam 17:26, Michael Elsdörfer < [email protected]

menulis:

Gambar wadah aplikasi saya dibuat menggunakan buildpacks. Saya ingin membuka
kerang. Ketika saya melakukannya, saya root, dan semua env vars disetel. Tetapi
lingkungan yang dihasilkan buildpack tidak ada. Jika saya membuka shell login untuk
pengguna aplikasi (su -l u22055) Saya memiliki lingkungan aplikasi saya, tetapi sekarang
kubernetes env vars tidak ada.

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

@miracle2k - Sudahkah Anda mencoba su -m -l u22055 ? -m seharusnya melestarikan variabel lingkungan.

@adarshaj @smarterclayton Terima kasih atas tipnya. su -m memiliki masalah sendiri (direktori home salah), tetapi saya membuatnya berfungsi sementara itu. Intinya adalah - itu sebabnya saya mempostingnya di sini - adalah saya ingin melihat "kubectl exec" melakukan hal yang benar. Bahkan mungkin menggunakan pengguna yang didefinisikan oleh file buruh pelabuhan.

Berikut adalah contoh bagaimana saya membutuhkan fungsi ini.

Gambar Jenkins resmi berjalan sebagai pengguna Jenkins. Saya memiliki persistent disk yang harus saya ubah ukurannya. Jika kubectl memiliki --user saya bisa bash sebagai root dan resize2fs. Sayangnya tanpa itu adalah rasa sakit yang luar biasa.

Kasus penggunaan tambahan - Anda sadar akan keamanan sehingga semua proses yang berjalan di dalam wadah tidak memiliki hak istimewa. Tapi sekarang sesuatu yang tidak terduga tidak berfungsi dan Anda ingin masuk sebagai root untuk misalnya menginstal utilitas debug dan mencari tahu apa yang salah pada sistem langsung.

Menginstal barang untuk tujuan debugging adalah kasus penggunaan saya juga. Saat ini saya ssh ke dalam node yang menjalankan kubernetes, dan menggunakan docker exec secara langsung.

Ini statusnya apa? Fungsionalitas ini akan sangat berguna

Saya tidak memeriksa, tetapi apakah flag global --as dan --as-group membantu di sini? Apakah mereka bahkan bekerja dengan exec ? cc @liggitt

Saya tidak memeriksa, tetapi apakah flag global --as dan --as-group membantu di sini? Apakah mereka bahkan bekerja dengan exec? cc @liggitt

Tidak, itu ada hubungannya dengan mengidentifikasi diri Anda ke API kubernetes, tidak melewati untuk menginformasikan uid yang dipilih untuk panggilan exec

Kurangnya bendera pengguna merepotkan. Kasus penggunaan adalah saya memiliki wadah yang berjalan sebagai pengguna yang tidak memiliki hak, saya memasang volume di atasnya, tetapi folder volume tidak dimiliki oleh pengguna. Tidak ada opsi untuk memasang volume dengan izin yang ditentukan. Saya tidak dapat menggunakan skrip titik masuk untuk mengubah izin karena itu berjalan sebagai pengguna yang tidak memiliki hak istimewa. Saya tidak dapat menggunakan hook lifecycle.preStart karena itu juga berjalan sebagai pengguna yang tidak memiliki hak. kubectl exec -u root dapat melakukannya, jika opsi '-u' ada.

Saya kira meskipun ini harus menjadi izin RBAC tambahan, untuk mengizinkan/memblokir 'exec' selain pengguna kontainer.

Idealnya kait lifeCycle harus dapat dijalankan sebagai root dalam wadah, bahkan ketika wadah tidak. Saat ini alternatif terbaik mungkin adalah menjalankan wadah init terhadap pemasangan yang sama; semacam overhead untuk memulai wadah terpisah dan memasang volume, padahal sebenarnya saya hanya membutuhkan perintah satu baris sebagai root saat wadah dimulai.

/sig kli

+1 untuk fitur ini. Tidak memiliki ini membuat hal-hal men-debug jauh lebih menyakitkan.

+1 untuk fitur ini. Saya harus membangun kembali wadah buruh pelabuhan saya dan memastikan file Docker memiliki root USER sebagai baris terakhir, lalu debug, lalu nonaktifkan ini.

baris perintah buruh pelabuhan tampaknya memiliki --user flag

johnjjung, jika Anda memiliki akses ssh ke node, Anda dapat terhubung ke wadah menggunakan buruh pelabuhan dengan flag pengguna yang mungkin menghemat sedikit waktu Anda.

Hmm, luar biasa, izinkan saya mencoba ini

Pada 10 Juli 2017, 11:34 -0400, BenAbineriBubble [email protected] , menulis:

johnjjung, jika Anda memiliki akses ssh ke node, Anda dapat terhubung ke wadah menggunakan buruh pelabuhan dengan flag pengguna yang mungkin menghemat sedikit waktu Anda.
—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

+1 benar-benar masalah, saya harus ssh dan kemudian menjalankan eksekutif buruh pelabuhan, sangat menyebalkan

/cc @frobware

+1 tolong. Tidak ingin menggunakan docker exec -u sebagai solusi lagi.

+1 - kubectl exec adalah penghemat waktu yang sangat besar dibandingkan docker exec, sehingga membuat saya menangis setiap kali saya harus kembali ke docker exec untuk menentukan pengguna.

pertimbangan:

• uid perlu menjadi bagian dari antarmuka exec untuk CRI, dan semua runtime perlu mendukungnya
• perlu mencari tahu apa pemeriksaan otorisasi yang akan menjadi pembatasan kebijakan keamanan pod wrt pada uids

+1 karena ini akan mencegah solusi tidak aman yang sayangnya telah kami jadikan kebiasaan (yaitu, menyetel runAsUser ke root...dan lupa mengembalikan nilainya saat menerapkan public ).

+1

+1 untuk saya, sangat membutuhkan --user flag untuk masuk ke pod dan membuat perubahan tanpa memindahkan wadah dengan root sebagai pengguna yang dijalankan

Isu ini tampaknya mendapat dukungan yang cukup kuat, adakah yang bisa dilakukan untuk memprioritaskannya? (ya, ya, tambalan diterima :))

+1 yang akan berguna untuk memiliki kemampuan ini untuk dieksekusi dengan pengguna yang ditentukan

Saya pikir implementasi ini mungkin rumit karena masalah keamanan? Misalnya jika Dockerfile awalnya ditetapkan sebagai pengguna non-root, haruskah Anda mengizinkannya menjalankan perintah sebagai pengguna root sekarang? -- Bagaimana flag pengguna buruh pelabuhan menangani ini? Jika mereka menanganinya dengan tepat, saya pikir kita hanya perlu menambal perintah kubectl exec untuk meneruskan ini..

Adakah yang bisa memberi tahu saya apakah ini strategi yang tepat? Lalu saya bisa memulai PR

@johnjjung Ya, saya percaya strategi di sini adalah menambal kubectl exec untuk melewati flag docker --user.

Selain itu, masalah keamanan tampak kecil karena kami memiliki otentikasi implisit dari GCP untuk terhubung dari kubectl.

Selain itu, masalah keamanan tampak kecil karena kami memiliki otentikasi implisit dari GCP untuk terhubung dari kubectl.

Bagaimana? Ada kontrol atas pengguna yang diizinkan dalam spesifikasi pod. Saya mengharapkan kontrol yang setara atas setiap id pengguna yang ditentukan dalam panggilan exec. Saya memiliki pertanyaan serupa tentang apakah exec dapat dijalankan sebagai root ketika wadah aslinya tidak. Jika demikian, maka kami tidak dapat mengeksposnya tanpa memikirkan bagaimana konteks keamanan pod dan kontrol kebijakan keamanan pod akan berlaku untuk opsi baru ini

@liggitt Itu tidak berbeda dengan mengatur pengguna di Dockerfile itu sendiri, namun, masih dapat dieksekusi sebagai root dengan flag pengguna Docker.

Perhatian utama Docker tampaknya berada di sekitar mencegah akses root dari _dalam_ wadah _running_, jika itu akan dikompromikan. Pada titik tertentu, kepercayaan harus diberikan untuk benar-benar memungkinkan pengguna mengembangkan dan bekerja dengan alat tersebut.

Misalnya jika Dockerfile awalnya ditetapkan sebagai pengguna non-root, haruskah Anda mengizinkannya menjalankan perintah sebagai pengguna root sekarang? -- Bagaimana flag pengguna buruh pelabuhan menangani ini?

@johnjjung seperti yang dikatakan @jordanwilson230 , argumen runtime buruh pelabuhan mengesampingkan direktif Dockerfile. Di luar kepala saya, ini adalah cara kerja sebagian besar argumen runtime (seperti nomor port).

Saya memiliki pertanyaan serupa tentang apakah exec dapat dijalankan sebagai root ketika wadah aslinya tidak

@liggitt Sekedar memperjelas, peran id pengguna yang ditentukan dalam spesifikasi pod tidak akan berubah dan akan terus memiliki efek yang diinginkan. Wadah (dan prosesnya) akan diluncurkan sebagai pengguna itu. Masalah yang diangkat di sini adalah untuk mengizinkan (sudah) mengautentikasi pengguna opsi manual untuk dieksekusi dengan root -- atau pengguna mana pun, terutama untuk tujuan debugging.

Masalah yang diangkat di sini adalah untuk mengizinkan (sudah) mengautentikasi pengguna opsi manual untuk dieksekusi dengan root -- atau pengguna mana pun, terutama untuk tujuan debugging.

Dan maksud saya adalah bahwa kontrol yang kita miliki saat ini untuk mencegah pengguna menjalankan wadah sebagai root perlu diterapkan di sini juga untuk mencegahnya dijalankan dengan root.

@liggitt Maaf, saya tidak tahu bagaimana menjelaskan dengan cara yang lebih jelas. Mengenai komentar Anda di atas, coba ini:

• ssh ke node yang menjalankan pod Anda (pod saya menjalankan Kafka, dengan pengguna kafka juga diatur di pod.spec)
  jordan@gke-my-default-pool-dsioiaag-i9f3 ~ $ docker exec -it -u root myKafkaContainer bash root@kafka-0:/# echo "I've exec'd into my container as $(whoami) despite defining the kafka user in pod.spec...." I've exec'd into my container as root despite defining the kafka user in pod.spec.... root@kafka-0:/#
  Setelah menetapkan bahwa ini sudah mungkin dari perspektif GKE (walaupun dengan cara yang sangat mengganggu), masalah keamanan baru apa yang Anda pikirkan? Masalah ini bukan menciptakan kembali roda, ini tentang memberikan kenyamanan.

Setelah menetapkan bahwa ini sudah mungkin dari perspektif GKE (walaupun dengan cara yang sangat mengganggu), masalah keamanan baru apa yang Anda pikirkan?

Masalahnya adalah mengekspos kekuatan melalui API kubernetes yang tidak ada saat ini. Adalah normal bagi pengguna untuk diizinkan menjalankan beban kerja melalui API dan tidak diizinkan mengakses ssh ke node.

Sangat bagus untuk memiliki fungsi melalui API, selama:

1. admin cluster memiliki kemampuan untuk mengontrol melalui kebijakan apakah diizinkan
2. cara kebijakan diekspresikan koheren dengan kebijakan yang ada (dalam hal ini, idealnya dilakukan berdasarkan mekanisme PodSecurityPolicy yang sama)
3. fungsi baru tidak membuka lubang di sistem yang sebelumnya diamankan (default mati, atau terjaga keamanannya berdasarkan kebijakan yang ada)

@liggitt Benar sekali. Jadi, setelah mempersempit cakupan implikasi keamanan terhadap akses _node_, kami ( @johnjjung dan lainnya) akhirnya dapat mulai menggunakan diskusi ini untuk substansi yang dapat ditindaklanjuti. Saya telah memulai plugin kubectl untuk dijalankan sebagai root pada platform GKE. Butuh sedikit waktu bagi saya untuk beralih ke AWS dan lainnya. @johnjjung apakah Anda masih bersedia untuk menjemput Anda?

@liggitt Baru saja melihat hasil edit yang Anda buat, yang akan berguna untuk kemajuan ini. Terima kasih.

Untuk diskusi terkait, lihat proposal untuk mengizinkan menjalankan wadah arbitrer, termasuk ID pengguna yang ditentukan secara terpisah, di pod yang ada - https://github.com/kubernetes/community/pull/1269

Semakin banyak aspek keamanan dari apa yang ingin Anda jalankan berangkat dari wadah aslinya, semakin penting bagi seluruh spesifikasi untuk dapat divalidasi oleh mekanisme penerimaan yang ada sebagai wadah yang koheren

@jordanwilson230 Telah meninjau basis kode, saya menemukan titik integrasi untuk perintah kubectl exec, yang merupakan titik awal yang baik, saya tidak yakin di mana saya harus membuat perubahan di basis kode kubernetes lain di mana kami dapat mengizinkan buruh pelabuhan - kamu bendera. Karena itu, saya pikir saya dapat memulai dari suatu tempat di sana, dan kembali ke masalah ini dengan admin cluster / kebijakan keamanan pod, dll... Selangkah demi selangkah.

Jika ada yang tahu di mana harus membuat perubahan di mana kubernetes menjalankan flag docker --user , itu akan sangat membantu.

Hai @johnjjung. Dahulu kala (<1.6), Kubernetes kubelets menggunakan Docker secara langsung dan hanya dapat melewatkan opsi seperti ini. Sekarang ada antarmuka standar untuk mendukung beberapa runtime, CRI. Ini adalah kemampuan CRI yang menentukan instruksi apa yang dapat diteruskan ke runtime, seperti Docker.

Kubernetes memberi tahu berbagai runtime container ( dockershim +Docker+ containerd , cri-containerd + containerd , rkt, cri-o, lxd, Frakti dll.) apa yang harus lakukan dengan menggunakan antarmuka CRI . Baik secara langsung untuk implementasi runtime cri-o , atau melalui shim seperti dockershim atau cri-containerd . Jadi agar dapat melakukan apa yang kita inginkan di sini (menambahkan proses ke wadah yang ada yang berjalan sebagai pengguna yang berbeda dari wadah yang dimulai), Anda harus terlebih dahulu memperluas spesifikasi CRI untuk mendukung opsi itu (misalnya mungkin ExecSync membutuhkan opsi uid, dan LinuxContainerSecurityContext tidak perlu melarangnya. Saya pikir @liggitt mengatakan seperti di atas ).

Kemudian setiap runtime container atau shim runtime dapat melanjutkan dan mengimplementasikan dukungan untuknya. Untuk Docker itu berarti memperluas implementasi dockershim untuk mendukung penambahan spesifikasi/antarmuka CRI. Namun saya berharap dockershim +Docker akan ditinggalkan demi cri-containerd + containerd dalam beberapa rilis lagi, jadi kami mungkin lebih baik untuk fokus pada cri-containerd .

http://blog.kubernetes.io/2017/11/containerd-container-runtime-options-kubernetes.html

https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md

Juga relevan dengan diskusi ini sebagai proposal penampung debug . Seharusnya Anda dapat menjalankan image container kedua di ruang Pod yang sama menggunakan perintah kubectl debug baru. Mungkin wadah tambahan dapat dijalankan sebagai pengguna yang berbeda?

@whereisaaron posting Anda sangat membantu. Terima kasih telah menulis semuanya dengan detail.

@whereisaaron terima kasih atas detailnya. Jika saya memahami Anda, sepertinya proposal debug (jika berhasil) mungkin merupakan tempat terbaik untuk meletakkan ini di penghujung hari. Tidak yakin apakah itu disetujui untuk dikerjakan, tetapi pada dasarnya memungkinkan Anda untuk melampirkan wadah pilihan Anda ke pod itu untuk men-debug pod itu (yang terdengar luar biasa), tetapi apakah itu memungkinkan Anda untuk mengubah pengguna Anda di dalam wadah aslinya? Juga, apakah itu berarti saya harus menunggu atau melanjutkan dengan patch menggunakan cri-containerd?

Sepertinya salah satu alasan mengapa ini belum diterapkan adalah karena ada banyak repo dengan banyak grup yang bekerja di area yang berbeda.

@johnjjung Saya yakin wadah debug telah disetujui untuk diimplementasikan sebagai fitur 'alfa' di Kubernetes 1.9 (dinonaktifkan kecuali Anda mengaktifkan fitur tersebut secara eksplisit). Saya tidak berpikir mereka berhasil menjadi 1.9 sekalipun. Jadi mungkin tidak sampai 1,10 atau lebih baru.

Seperti yang saya pahami, kontainer debug berjalan sebagai proses di dalam Pod target 'sedang di-debug', jadi mereka berada dalam konteks keamanan kernel yang sama dengan Pod, mereka hanya memiliki image/sistem file kontainer mereka sendiri. Jadi Anda dapat men-debug proses apa pun, dan memasang volume apa pun yang dimiliki Pod. Tetapi karena Anda berada dalam konteks keamanan yang sama, saya ingin tahu apakah Anda terjebak dengan batasan kernel yang sama pada uid yang dapat Anda gunakan di Pod atau tidak? Saya tidak yakin di sana, Anda harus bertanya kepada orang #sig-node yang mengerjakannya.

Mengenai memperluas CRI, saya pikir Anda akan membutuhkan banyak dukungan dari #sig-node untuk melakukan ini, ditambah tidak ada keberatan dari berbagai proyek runtime, seperti cri-containerd , dan cri-o , yang mungkin kemudian harus menerapkan dukungan.

Saya tidak punya banyak waktu hari ini, tetapi bagi mereka yang menjalankan GKE, saya telah membuat plugin kubectl ad-hoc untuk dijalankan dengan flag [-u] pengguna:

https://github.com/jordanwilson230/kubectl-plugins

Jangan ragu untuk memodifikasi/menyalin plugin itu atau semuanya dengan menjalankan skrip instalasi. Hanya solusi ad-hoc sampai @johnjjung dan yang lainnya dapat mengambil lebih banyak.

Memiliki solusi alternatif yang tidak spesifik untuk GCP. Ini tidak menggunakan SSH sama sekali dan hanya membutuhkan kubectl yang berfungsi.

https://github.com/mikelorant/kubectl-exec-user

Apakah pod kubectl-exec-user memverifikasi bahwa orang yang menggunakannya memiliki akses ke wadah yang diminta untuk masuk?

Itu kembali ke akses yang diizinkan oleh kubernetes API. Ini hanya akan berfungsi jika RBAC mengizinkan wadah untuk memasang soket buruh pelabuhan node.

Pertimbangkan solusi saya sebagai cara kreatif untuk keluar dari wadah ke node tanpa memerlukan SSH. Semua kondisi keamanan yang sama perlu dipertimbangkan tetapi setidaknya menghormati batasan server API kubernetes.

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

Ini akan sangat disambut. Tidaklah keren untuk dihukum karena sadar akan keamanan dan menjalankan semua proses sebagai non-root. (Mengulangi https://github.com/kubernetes/kubernetes/issues/30656#issuecomment-272055993)

/ tanda tangan simpul

Tampaknya ada PR yang belum selesai yang membutuhkan rebase untuk fitur ini: https://github.com/kubernetes/kubernetes/pull/59092. Adakah yang bisa mengambilnya dan menyelesaikannya? CC @louyihua

+1
(Saya mengalami masalah yang sama dengan @SimenB - Saya ingin menginstal barang-barang untuk keperluan debugging. Sampai jumpa, terima kasih atas petunjuk "gunakan buruh pelabuhan secara langsung")

Sementara kami menunggu ini untuk didukung dengan benar, solusi perantara dapat menjalankan CMD buruh pelabuhan Anda dengan su-exec (baik di Dockerfile atau dalam manifes K8). su-exec beratnya hanya 20k (di alpine) dan dengan cara ini aplikasi Anda akan berjalan tanpa hak, sementara masih memiliki root di kubectl exec.

+1

Saya juga akan menghargai bendera -u seperti itu. +1.

Hanya sebuah ide:

Misalnya sesuatu seperti --conainer-type akan menjadi nilai tambah yang besar untuk memungkinkan meneruskan argumen yang didukung langsung ke implementasi wadah yang mendasarinya:

kubectl exec --container-type=docker -it -u 0 NAME

Ini akan menghindari hanya sebagian dari fungsionalitas yang mendasari runtime container di kubectl. Selain itu, menghemat tenaga karena tidak perlu memetakan dan mengabstraksi argumen yang didukung dari lapisan kubelet hingga ke wadah untuk setiap jenis wadah yang didukung.

Jadi secara ringkas tanpa flag --container-type hanya argumen abstrak dari kubectl yang dapat digunakan dan tipe container yang mendasarinya benar-benar transparan. Dengan bendera, argumen khusus wadah dapat diteruskan. Terserah pengguna kubectl apakah dia ingin mengikat ke jenis wadah atau tidak.

BTW: Terima kasih kepada @SimenB atas petunjuknya untuk ssh ke dalam node dan menggunakan Docker secara langsung. Itu memecahkan masalah saya untuk sementara. Menggunakan Minikube, saya dapat melakukan hal berikut untuk masuk sebagai root:
minikube ssh "docker exec -it -u 0 <container-id> bash"
Mungkin ini bisa membantu seseorang.

Skrip solusi yang mengotomatiskan yang tidak menyenangkan. Akses SSH ke node diperlukan.

Penggunaan:

```./shell-into-pod-as-root.sh[kerang]
./shell-into-pod-as-root.sh nama pod
./shell-into-pod-as-root.sh nama pod sh

Enjoy!

!/usr/bin/env bash

set -xe

POD=$(kubectl mendeskripsikan pod "$1")
NODE=$(echo "$POD" | grep -m1 Node | awk -F'/' '{print $2}')
CONTAINER=$(echo "$POD" | grep -m1 'Container ID' | awk -F 'docker://' '{print $2}')

CONTAINER_SHELL=${2:-bash}

atur +e

ssh -t "$NODE" sudo docker exec --user 0 -it "$CONTAINER" "$CONTAINER_SHELL"

jika [ "$?" -gt 0 ]; kemudian
atur +x
echo 'SSH ke dalam pod gagal. Jika Anda melihat pesan kesalahan yang mirip dengan "file yang dapat dieksekusi tidak ditemukan di $PATH", silakan coba:'
echo "$0 $1 sh"
fi
```

@Nowaker bagaimana Anda menangani ruang nama?

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

Saya juga akan menghargai bendera -u seperti itu. +1.

Hanya sebuah ide:

Misalnya sesuatu seperti --conainer-type akan menjadi nilai tambah yang besar untuk memungkinkan meneruskan argumen yang didukung langsung ke implementasi wadah yang mendasarinya:

kubectl exec --container-type=docker -it -u 0 NAME

Ini akan menghindari hanya sebagian dari fungsionalitas yang mendasari runtime container di kubectl. Selain itu, menghemat tenaga karena tidak perlu memetakan dan mengabstraksi argumen yang didukung dari lapisan kubelet hingga ke wadah untuk setiap jenis wadah yang didukung.

Jadi secara ringkas tanpa flag --container-type hanya argumen abstrak dari kubectl yang dapat digunakan dan tipe container yang mendasarinya benar-benar transparan. Dengan bendera, argumen khusus wadah dapat diteruskan. Terserah pengguna kubectl apakah dia ingin mengikat ke jenis wadah atau tidak.

BTW: Terima kasih kepada @SimenB atas petunjuknya untuk ssh ke dalam node dan menggunakan Docker secara langsung. Itu memecahkan masalah saya untuk sementara. Menggunakan Minikube, saya dapat melakukan hal berikut untuk masuk sebagai root:
minikube ssh "docker exec -it -u 0 <container-id> bash"
Mungkin ini bisa membantu seseorang.

Ya - sepele untuk hanya menggunakan docker exec untuk melakukan ini - ini sebagian besar tentang konsistensi - wadah buruh pelabuhan multi-pengguna benar-benar sedikit lelucon - warisan dari mengubah VM menjadi wadah.

Saya sedang berurusan dengan grafana saat ini - saya kira ini akan berlalu seiring waktu.

@bryanhuntesl Ada diskusi tentang solusi di atas yang tidak memerlukan ssh'ing manual ke node. Anda juga dapat mencoba plugin ini -- https://github.com/jordanwilson230/kubectl-plugins

Bagaimana jika Anda tidak ingin mengizinkan pengguna memasukkan ssh ke dalam simpul? Mengizinkan pengguna ssh mengakses sebuah node, serta mengizinkan mereka memiliki akses ke buruh pelabuhan, dapat menjadi risiko keamanan. Docker tidak tahu apa-apa tentang namespace atau izin k8s. Jika pengguna dapat menjalankan docker exec , ia dapat dieksekusi ke dalam pod _any_ namespace.

SSH bukan solusi yang tepat, IMHO.

Bagaimana jika Anda tidak ingin mengizinkan pengguna memasukkan ssh ke dalam simpul? Mengizinkan pengguna ssh mengakses sebuah node, serta mengizinkan mereka memiliki akses ke buruh pelabuhan, dapat menjadi risiko keamanan. Docker tidak tahu apa-apa tentang namespace atau izin k8s. Jika pengguna dapat menjalankan docker exec , ia dapat dieksekusi ke dalam pod _any_ namespace.

SSH bukan solusi yang tepat, IMHO.

Saya mendukung pendapat itu - menggunakan mekanisme out of band untuk mendapatkan akses langsung meningkatkan area serangan potensial.

Bagaimana jika Anda tidak ingin mengizinkan pengguna memasukkan ssh ke dalam simpul? Mengizinkan pengguna ssh mengakses sebuah node, serta mengizinkan mereka memiliki akses ke buruh pelabuhan, dapat menjadi risiko keamanan. Docker tidak tahu apa-apa tentang namespace atau izin k8s. Jika pengguna dapat menjalankan docker exec , ia dapat dieksekusi ke dalam pod _any_ namespace.

SSH bukan solusi yang tepat, IMHO.

Ada solusi yang tidak memerlukan SSH @gjcarneiro. Selain itu, pengguna harus terlebih dahulu menambahkan kunci SSH publik mereka di Metadata Komputasi sebelum mereka diizinkan mengakses SSH ke node (jika di GCP) @bryanhuntesl.

@liggitt Sudah tiga tahun sejak topik ini dimulai, ada kesimpulan?

Saya tidak yakin apakah solusi ini telah disebutkan sebelumnya, tetapi apa yang kami lakukan sebagai solusinya adalah membuat semua wadah kami menyertakan skrip yang akan memasukkan Anda sebagai pengguna yang benar. Ditambah sebuah motd:

File Docker:

USER root
RUN echo "su -s /bin/bash www-data" >> /root/.bashrc
# this exit statement here is needed in order to exit from the new shell directly or else you need to type exit twice
RUN echo "exit" >> /root/.bashrc
# /var/www is www-data's home directory
COPY motd.sh /var/www/.bashrc

motd.sh:

RED='\033[0;31m'
YELLOW='\033[0;33m'

echo -e "${RED}"
echo "##################################################################"
echo "#        You've been automatically logged in as www-data.        #"
echo "##################################################################"
echo -e "${YELLOW} "
echo "If you want to login as root instead:"
echo -e "$(if [ "$KUBERNETES_PORT" ]; then echo 'kubectl'; else echo 'docker'; fi) exec -ti $(hostname) -- bash --noprofile -norc"

TEXT_RESET='\033[0m'

echo -e "${TEXT_RESET} "

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

gunakan plugin kubectl [exec-as]:

kubectl krew install exec-as

Seperti disebutkan di atas, ini sangat membutuhkan KEP dan diskusi tentang implikasi keamanan. Bukan berarti itu ide yang buruk, itu hanya memiliki dampak yang signifikan terhadap sistem dan membutuhkan desain sebelum kita dapat memulai pengkodean.

Saya akan dengan senang hati membantu meninjau dan menggembalakan KEP untuk ini, tetapi pasti ada beberapa kesalahan dan mungkin perlu waktu.

@miracle2k - Sudahkah Anda mencoba su -m -l u22055 ? -m seharusnya melestarikan variabel lingkungan.

@miracle2k Saya mencoba ini (trying to exec as root user) , tetapi mendapat No passwd entry for user '0'

$ su -m -l 0
No passwd entry for user '0'

Halo. Untuk mengatasi masalah ini, saya mengembangkan "kpexec" CLI.
Tolong beri tanggapan Anda.

• https://github.com/ssup2/kpexec

Pada node yang menjalankan pod:

docker exec -u 0 -it \
    `kubectl -n NAMESPACE get pod \
          -l label=value \
          -o jsonpath='{range .items[*].status.containerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3` \
sh

@cristichiru Untuk sebagian besar cluster tempat saya beroperasi, tidak ada akses shell langsung ke Node.js yang mendasarinya. Saya menduga itu juga sering terjadi pada orang lain.

Dalam kasus tersebut, tampaknya opsi lain yang disajikan di sini, seperti plugin kubectl mungkin satu-satunya cara - dengan asumsi tidak ada akses ke daemon buruh pelabuhan juga.

+1

Nah template KEP ada di sini https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

Saya pikir saya akan melihat berapa banyak pekerjaan untuk menulis satu dan... ya saya bukan orang yang menulis ini, Template kehilangan saya di daftar periksa item satu **Pick a hosting SIG.** siapa pun yang lebih akrab dengan proses ingin untuk memulai draf? Saya hanya ingin tempat menempel 👍 saya untuk mendukung proposal sebagai pengguna aktif Kubernetes.

Ini mungkin terdengar sembrono, tetapi saya melihat sekitar setengah lusin solusi yang dikodekan / ditulis / ditulis dengan baik untuk masalah ini, jadi jelas ada _are_ orang yang berada dalam posisi yang lebih baik untuk merancang solusi teknis yang diusulkan daripada saya.

Saya merasa seperti Kubernetes menjadi OpenStack baru di mana tidak ada yang dapat dicapai dalam jangka waktu yang wajar karena PROSES .

Kasus penggunaan asli @VikParuchuri di sini adalah untuk dapat men-debug/memecahkan masalah wadah sebagai root, meskipun wadah itu sendiri berjalan sebagai pengguna yang tidak tepercaya. Kasus penggunaan yang bagus, karena, jika diselesaikan, ini mendorong kita semua untuk menjalankan container sebagai pengguna non-root. 🎉.

Sebelum Anda menyiapkan KEP untuk docker exec , periksa dulu apakah wadah debug ephemeral k8s tidak menangani kasus penggunaan ini untuk Anda.

docker exec --user hanya satu cara untuk mengatasi kasus penggunaan itu, dan itu bergantung pada runtime buruh pelabuhan yang digunakan. Saat k8s pindah ke containerd , dockerd dan teman-teman adalah opsional atau bahkan tidak diinstal lagi, jadi ini mungkin bukan opsi berwawasan ke depan?

Cara asli k8s lainnya untuk mengatasi kasus penggunaan ini adalah wadah debug singkat. Katakanlah Anda memiliki wadah yang berjalan sebagai pengguna yang tidak tepercaya. Wadah debug memungkinkan Anda untuk memulai wadah sementara di ruang proses yang sama dengan wadah target, tetapi berjalan sebagai root (atau siapa pun). Pendekatan ini memiliki beberapa keunggulan signifikan dibandingkan pendekatan exec, khususnya Anda dapat membawa alat dan utilitas debug apa pun yang Anda butuhkan dalam gambar untuk wadah debug. Jadi, alih-alih menggembungkan gambar wadah target Anda dengan utilitas dan editor, dll. untuk berjaga-jaga jika Anda perlu menjalankan (🐑 .., bersalah!), Anda dapat memiliki gambar wadah debug pisau tentara swiss besar yang bagus dan menjaga gambar aplikasi Anda tetap bersih . Anda dapat menggunakan bash dalam wadah debug Anda ketika target Anda hanya memiliki sh . Anda bahkan dapat men-debug container yang tidak memiliki shell untuk dieksekusi sama sekali, seperti container biner tunggal, atau container distroless .

Misalnya gunakan busybox untuk men-debug wadah sebagai root.

kubectl alpha debug -it ephemeral-demo --image=busybox --target=ephemeral-demo

Saya pikir ini bisa dibilang model yang lebih baik, karena memperlakukan wadah sebagai proses yang terisolasi, yang Anda 'lampirkan' untuk debugging, daripada seperti mini-VM yang Anda gunakan. Kerugiannya adalah saya tidak berpikir Anda dapat memeriksa sistem file target, kecuali jika Anda dapat membagikan mount eksternal atau mount 'kosong'. Anda membagikan ruang nama proses dengan target Anda, sehingga Anda juga dapat mengakses sistem file penampung target, melalui /proc/$pid/root .

Wadah debug singkat telah menavigasi PROSES :-) dan telah diimplementasikan. Wadah ini alfa karena ~1.16 dan 1.18 kubectl menyertakan perintah alpha debug . Info lebih lanjut di sini:

Referensi:

• https://medium.com/01001101/ephemeral-containers-the-future-of-kubernetes-workload-debugging-c5b7ded3019f
• https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral -container
• https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/
• https://www.shogan.co.uk/kubernetes/enabling-and-using-ephemeral-containers-on-kubernetes-1-16/

Terima kasih atas balasan yang bijaksana @whereisaaron :) Saya pikir itu menangkap banyak hal dengan cukup baik.

Saya pikir saya akan melihat berapa banyak pekerjaan untuk menulis satu dan ... ya saya bukan orang yang menulis ini, Template kehilangan saya di item checklist satu Pilih SIG hosting. ada yang lebih paham dengan prosesnya ingin memulai draf? Saya hanya ingin tempat menempel 👍 saya untuk mendukung proposal sebagai pengguna aktif Kubernetes.

KEP bisa sangat menakutkan, tetapi saya ingin memberikan sedikit konteks di sekitarnya. Kubernetes sendiri sangat besar; potensi perubahan memiliki radius ledakan yang sangat besar, baik untuk basis kontributor maupun pengguna. Sebuah fitur baru mungkin tampak mudah untuk diterapkan tetapi memiliki potensi untuk berdampak luas pada kedua kelompok.

Kami mendelegasikan pengelolaan bagian dari basis kode ke SIG; dan melalui KEP-lah satu atau lebih SIG dapat mencapai konsensus tentang suatu fitur. Bergantung pada apa yang dilakukan fitur, itu mungkin melalui tinjauan API, dievaluasi untuk masalah skalabilitas, dll.

Semua ini untuk memastikan bahwa apa yang dihasilkan memiliki peluang sukses terbesar dan dikembangkan sedemikian rupa sehingga SIG bersedia mendukungnya. Jika penulis asli mengundurkan diri, tanggung jawab untuk mempertahankannya jatuh ke SIG. Jika katakanlah, sebuah fitur dipromosikan ke stabil dan kemudian ditandai untuk dihentikan, itu akan menjadi minimal satu tahun sebelum dapat dihapus mengikuti kebijakan penghentian .

Jika ada cukup permintaan untuk fitur, biasanya seseorang yang lebih akrab dengan proses KEP akan menawarkan untuk membantu menjalankannya dan mengawalnya, tetapi masih membutuhkan seseorang untuk mengemudikannya.

Bagaimanapun, saya harap itu menjelaskan setidaknya sedikit tentang mengapa ada proses yang terkait dengan penggabungan fitur. :+1: Jika Anda memiliki pertanyaan, silakan hubungi langsung.

Kerugiannya adalah saya tidak berpikir Anda dapat memeriksa sistem file target, kecuali jika Anda dapat membagikan mount eksternal atau mount 'kosong'.

Bagi saya, memeriksa sistem file sebagai root, dan menjalankan utilitas yang dapat berinteraksi dengan sistem file sebagai root, adalah alasan nomor satu untuk mendapatkan dukungan untuk fitur yang diminta. Singkatnya, saran ini tidak menyelesaikan masalah saya sama sekali.

Kerugiannya adalah saya tidak berpikir Anda dapat memeriksa sistem file target

Saya salah tentang itu, karena wadah debug Anda yang disuntikkan berbagi ruang nama proses dengan wadah target Anda, Anda dapat mengakses sistem file dari proses apa pun dalam wadah target dari wadah debug Anda. Dan itu akan mencakup sistem file wadah dan sistem file apa pun yang dipasang ke wadah itu.

Sistem file container dapat dilihat oleh container lain di dalam pod melalui link /proc/$pid/root.

https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/#understanding -process-namespace-sharing

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

kubectl alpha debug -it ephemeral-demo --image=busybox --target=ephemeral-demo

error: ephemeral containers are disabled for this cluster

@whereisaaron Sepertinya sebagian besar penyedia cloud tidak mendukung ini, dan untuk prem kita bisa pergi ke node dan docker exec ke dalam wadah. Jadi sekali lagi, kegunaannya tampaknya cukup terbatas.

Juga akses melalui /proc/$pid/root tidak seperti yang saya inginkan, saya ingin akses langsung bukan melalui "jendela samping". Misalnya menjalankan utils seperti apt/apk _in the continer_ tidak mudah ketika sistem file root tidak seperti yang mereka harapkan.

Saya memiliki masalah serupa: Saya perlu membuat beberapa direktori, tautan, dan menambahkan izin untuk pengguna non-root pada gambar resmi yang digunakan oleh bagan helm resmi (jenkins).

Saya dapat menyelesaikannya dengan menggunakan plugin exec-as.

Dengan penghentian Docker yang direncanakan dan penghapusan selanjutnya, kapan ini akan ditangani? Wadah fana masih dalam versi alfa. Apa alternatif stabil tanpa menggunakan Docker sebagai CRI?

Selain alfa, wadah ephemeral jauh lebih rumit untuk digunakan daripada hanya kubectl exec --user .

Kasus penggunaan lain untuk ini adalah mengeksekusi skrip secara manual dalam wadah. Misalnya, skrip pemeliharaan occ NextCloud harus dijalankan sebagai www-data. Tidak ada sudo atau yang serupa dalam gambar, dan doc menyarankan untuk menggunakan docker exec -u 33 saat berada di lingkungan Docker.

Anda dapat memecahkan masalah dengan nextcloud dengan menjalankan

su -s /bin/bash www-data

Tapi ini tidak ideal.