एसजीटीएम। @ Kubernetes/kubectl इस पर कोई विचार?

यह अनुचित नहीं है, लेकिन हमें उपयोगकर्ता इनपुट को नियंत्रित करने के लिए पॉड सुरक्षा नीति की आवश्यकता होगी और हमें शायद उपयोगकर्ता को नाम से अस्वीकार करना होगा (चूंकि हम इसे कंटेनरों के लिए अनुमति नहीं देते हैं - आपको यूआईडी निर्दिष्ट करना होगा)।

@sttts और @ncdc पुनः निष्पादित

वैध उपयोग-मामला

इस पर किसी भी अद्यतन?

मेरी ऐप कंटेनर छवि बिल्डपैक का उपयोग करके बनाई गई है। मैं एक खोल खोलना चाहता हूँ। जब मैं करता हूं, मैं रूट हूं, और सभी एनवी वर्र्स सेट हैं। लेकिन बिल्डपैक से उत्पन्न वातावरण नहीं है। यदि मैं ऐप उपयोगकर्ता ( su -l u22055 ) के लिए एक लॉगिन शेल खोलता हूं तो मेरे पास मेरा ऐप वातावरण है, लेकिन अब कुबेरनेट्स एनवी वर्र्स गायब हैं।

मैंने सोचा su -l env vars की प्रतिलिपि नहीं बनाई? आपको स्पष्ट रूप से कॉपी करना है
स्वयं या किसी भिन्न आदेश का उपयोग करें।

मंगलवार, अक्टूबर 11, 2016 को शाम 5:26 बजे, माइकल एल्स्डॉर्फर < नोटिफिकेशन @github.com

लिखा था:

मेरी ऐप कंटेनर छवि बिल्डपैक का उपयोग करके बनाई गई है। मैं एक खोलना चाहता हूँ
सीप। जब मैं करता हूं, मैं रूट हूं, और सभी एनवी वर्र्स सेट हैं। लेकिन वो
बिल्डपैक से उत्पन्न वातावरण नहीं है। अगर मैं के लिए एक लॉगिन शेल खोलता हूं
ऐप उपयोगकर्ता (su -l u22055) मेरे पास मेरा ऐप वातावरण है, लेकिन अब
कुबेरनेट्स एनवी वर्र्स गायब हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आप उस टीम में हैं जिसका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/30656#issuecomment -253085398,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABG_p7sIu20xnja2HsbPUUgD1m4gXqVAks5qzCksgaJpZM4Jk3n0
.

@ चमत्कार 2k - क्या आपने su -m -l u22055 की कोशिश की है? -m पर्यावरण चर को संरक्षित करने वाला माना जाता है।

@adarshaj @smarterclayton सुझावों के लिए धन्यवाद। su -m के अपने मुद्दे हैं (घरेलू डीआईआर गलत है), लेकिन मैंने इस बीच इसे काम किया। हालांकि मुद्दा यह है - इसलिए मैंने इसे यहां पोस्ट किया है - यह है कि मैं "कुबेक्टल निष्पादन" को सही काम करना चाहता हूं। शायद उस उपयोगकर्ता का भी उपयोग करें जिसे डॉकर फ़ाइल परिभाषित करती है।

यहां एक उदाहरण दिया गया है कि मुझे इस कार्यक्षमता की आवश्यकता कैसे है।

आधिकारिक जेनकिंस छवि उपयोगकर्ता जेनकिंस के रूप में चलती है। मेरे पास एक सतत डिस्क संलग्न है जिसे मुझे आकार बदलने की आवश्यकता है। अगर Kubectl में --user होता तो मैं रूट और resize2fs के रूप में बैश कर सकता था। दुर्भाग्य से इसके बिना यह एक अत्यधिक दर्द है।

एक अतिरिक्त उपयोग का मामला - आप सुरक्षा के प्रति जागरूक हो रहे हैं इसलिए कंटेनर के अंदर चलने वाली सभी प्रक्रियाएं विशेषाधिकार प्राप्त नहीं हैं। लेकिन अब कुछ अनपेक्षित रूप से काम नहीं कर रहा है और आप रूट के रूप में जाना चाहते हैं जैसे डिबग उपयोगिताओं को स्थापित करना और यह पता लगाना कि लाइव सिस्टम में क्या गलत है।

डिबगिंग उद्देश्यों के लिए सामान स्थापित करना मेरा उपयोग मामला भी है। वर्तमान में मैं कुबेरनेट्स चलाने वाले नोड्स में ssh हूं, और सीधे docker exec का उपयोग करता हूं।

इस पर क्या स्थिति है? यह कार्यक्षमता अत्यधिक उपयोगी होगी

मैंने जाँच नहीं की, लेकिन क्या --as और --as-group वैश्विक झंडे यहाँ मदद करते हैं? क्या वे exec के साथ भी काम करते हैं? cc @liggitt

मैंने जाँच नहीं की, लेकिन क्या --as और --as-group वैश्विक झंडे यहाँ मदद करते हैं? क्या वे निष्पादन के साथ भी काम करते हैं? cc @liggitt

नहीं, उन्हें कुबेरनेट्स एपीआई के लिए खुद को पहचानने के साथ करना है, न कि निष्पादन कॉल के लिए चुने गए यूआईडी को सूचित करने के लिए

उपयोगकर्ता ध्वज की कमी एक परेशानी है। उपयोग का मामला यह है कि मेरे पास एक कंटेनर है जो एक अनपेक्षित उपयोगकर्ता के रूप में चलता है, मैं उस पर एक वॉल्यूम माउंट करता हूं, लेकिन वॉल्यूम फ़ोल्डर उपयोगकर्ता के स्वामित्व में नहीं है। निर्दिष्ट अनुमतियों के साथ वॉल्यूम माउंट करने का कोई विकल्प नहीं है। मैं अनुमतियों को बदलने के लिए एंट्रीपॉइंट स्क्रिप्ट का उपयोग नहीं कर सकता क्योंकि यह अनपेक्षित उपयोगकर्ता के रूप में चलता है। मैं एक lifecycle.preStart हुक का उपयोग नहीं कर सकता क्योंकि यह अनपेक्षित उपयोगकर्ता के रूप में भी चलता है। kubectl exec -u root ऐसा कर सकता है, अगर '-u' विकल्प मौजूद होता।

मुझे लगता है कि कंटेनर उपयोगकर्ता के अलावा 'निष्पादन' को अनुमति/ब्लॉक करने के लिए यह एक अतिरिक्त आरबीएसी अनुमति होनी चाहिए।

आदर्श रूप से लाइफसाइकिल हुक कंटेनर में रूट के रूप में चलने में सक्षम होना चाहिए, भले ही कंटेनर न हो। अभी सबसे अच्छा विकल्प शायद एक ही माउंट के खिलाफ एक इनिट कंटेनर चलाने के लिए है; एक अलग कंटेनर शुरू करने और वॉल्यूम माउंट करने के लिए एक ओवरहेड की तरह, जब वास्तव में मुझे कंटेनर स्टार्ट पर रूट के रूप में केवल एक-लाइन कमांड की आवश्यकता होती है।

/सिगरेट क्लिक

इस सुविधा के लिए +1। ऐसा नहीं होने से डिबगिंग चीजें बहुत अधिक दर्दनाक हो जाती हैं।

इस सुविधा के लिए +1। मुझे अपने डॉकटर कंटेनर का पुनर्निर्माण करना है और सुनिश्चित करना है कि डॉकर फ़ाइल में अंतिम पंक्ति के रूप में USER रूट है, फिर डिबग करें, फिर इसे अक्षम करें।

ऐसा लगता है कि docker कमांड लाइन में --user झंडा है

जॉनजंग, यदि आपके पास नोड तक एसएसएच पहुंच है तो आप उपयोगकर्ता ध्वज के साथ डॉकर का उपयोग कर कंटेनर से कनेक्ट कर सकते हैं जो आपको थोड़ा सा समय बचा सकता है।

हम्म, कमाल है, मुझे यह कोशिश करने दें

10 जुलाई, 2017 को 11:34 -0400, BenAbineriBubble [email protected] ने लिखा:

जॉनजंग, यदि आपके पास नोड तक एसएसएच पहुंच है तो आप उपयोगकर्ता ध्वज के साथ डॉकर का उपयोग कर कंटेनर से कनेक्ट कर सकते हैं जो आपको थोड़ा सा समय बचा सकता है।
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

+1 वास्तव में एक मुद्दा है, मुझे ssh करना है और फिर docker exec को निष्पादित करना है, इस तरह के कष्टप्रद

/सीसी @frobware

+1 कृपया। अब वर्कअराउंड के रूप में docker exec -u का उपयोग नहीं करना चाहते हैं।

+1 - kubectl exec docker exec पर इतना बड़ा समय बचाने वाला है, कि यह मुझे हर बार रोता है मुझे उपयोगकर्ता को निर्दिष्ट करने के लिए docker exec पर वापस जाना पड़ता है।

विचार:

• यूआईडी को सीआरआई के लिए निष्पादन इंटरफ़ेस का हिस्सा बनने की आवश्यकता होगी, और सभी रनटाइम को इसका समर्थन करने की आवश्यकता होगी
• यह पता लगाने की आवश्यकता होगी कि प्राधिकरण जांच क्या होगी, यूआईडी पर पॉड सुरक्षा नीति प्रतिबंध क्या होगा

+1 क्योंकि यह असुरक्षित वर्कअराउंड को रोकेगा जिसकी हमने दुर्भाग्य से आदत बना ली है (यानी, runAsUser को रूट पर सेट करना ... और सार्वजनिक 😮 को तैनात करते समय मान को वापस करना भूल जाते हैं)।

+1

मेरे लिए +1, पॉड में लॉगिन करने के लिए वास्तव में --user ध्वज की आवश्यकता है और रन उपयोगकर्ता के रूप में रूट के साथ कंटेनर को पुन: नियोजित किए बिना परिवर्तन करें

ऐसा लगता है कि इस मुद्दे को काफी मजबूत समर्थन प्राप्त है, क्या इसे प्राथमिकता देने के लिए कुछ किया जा सकता है? (हाँ, हाँ, पैच स्वीकार किए जाते हैं :))

+1 जो परिभाषित उपयोगकर्ता के साथ निष्पादित करने की क्षमता रखने में आसान होगा

मुझे लगता है कि सुरक्षा चिंताओं के कारण इसका कार्यान्वयन मुश्किल हो सकता है? उदाहरण के लिए यदि डॉकरफाइल को शुरू में एक गैर-रूट उपयोगकर्ता के रूप में सेट किया गया था, तो क्या आपको इसे अब रूट उपयोगकर्ता के रूप में कमांड निष्पादित करने की अनुमति देनी चाहिए? - डॉकर के यूजर फ्लैग ने इसे कैसे हैंडल किया? अगर वे इसे उचित तरीके से संभालते हैं तो मुझे लगता है कि हमें इसे पास करने के लिए कुबेक्टल एक्ज़ीक्यूटिव कमांड को पैच करने की आवश्यकता है।

क्या कोई मुझे बता सकता है कि क्या यह एक उपयुक्त रणनीति है? तब मैं एक पीआर . पर शुरू कर सकता हूं

@johnjjung हां, मेरा मानना ​​​​है कि यहां रणनीति docker --user ध्वज को पास करने के लिए kubectl exec को पैच कर रही है।

साथ ही, सुरक्षा संबंधी चिंताएं मामूली लगती हैं क्योंकि हमारे पास Kubectl से कनेक्ट करने के लिए GCP से अंतर्निहित प्रमाणीकरण है।

साथ ही, सुरक्षा संबंधी चिंताएं मामूली लगती हैं क्योंकि हमारे पास Kubectl से कनेक्ट करने के लिए GCP से अंतर्निहित प्रमाणीकरण है।

ऐसा कैसे? पॉड स्पेक में किस उपयोगकर्ता की अनुमति है, इस पर नियंत्रण है। मैं निष्पादन कॉल में निर्दिष्ट किसी भी उपयोगकर्ता आईडी पर समकक्ष नियंत्रण की अपेक्षा करता हूं। मेरे पास इसी तरह के प्रश्न हैं कि मूल कंटेनर नहीं होने पर निष्पादन को रूट के रूप में चलाया जा सकता है या नहीं। यदि ऐसा है, तो हम बिना यह सोचे कि पॉड सुरक्षा संदर्भ और पॉड सुरक्षा नीति नियंत्रण इस नए विकल्प पर कैसे लागू होंगे, इसका खुलासा नहीं कर सकते।

@liggitt यह उपयोगकर्ता को Dockerfile में ही सेट करने से अलग नहीं है, और फिर भी, अभी भी Docker के उपयोगकर्ता ध्वज के साथ रूट के रूप में निष्पादित करने में सक्षम है।

डॉकर की प्राथमिक चिंता _within_ a _running_ कंटेनर से रूट एक्सेस को रोकने के आसपास लगती है, क्या इसे समझौता किया जाना था। कुछ बिंदु पर, वास्तव में उपयोगकर्ताओं को उपकरण के साथ विकसित करने और काम करने की अनुमति देने के लिए विश्वास दिया जाना चाहिए।

उदाहरण के लिए यदि डॉकरफाइल को शुरू में एक गैर-रूट उपयोगकर्ता के रूप में सेट किया गया था, तो क्या आपको इसे अब रूट उपयोगकर्ता के रूप में कमांड निष्पादित करने की अनुमति देनी चाहिए? - डॉकर के यूजर फ्लैग ने इसे कैसे हैंडल किया?

@johnjjung यह @ jordanwilson230 कहता है, docker रनटाइम तर्क Dockerfile निर्देश को ओवरराइड करता है। मेरे सिर के ऊपर से, इस प्रकार अधिकांश रनटाइम तर्क काम करते हैं (जैसे पोर्ट नंबर)।

मेरे पास इसी तरह के प्रश्न हैं कि क्या मूल कंटेनर नहीं होने पर एक निष्पादन को रूट के रूप में चलाया जा सकता है

@liggitt बस स्पष्ट करने के लिए, पॉड स्पेक में परिभाषित उपयोगकर्ता आईडी की भूमिका नहीं बदलेगी और इसका इच्छित प्रभाव जारी रहेगा। कंटेनर (और इसकी प्रक्रियाओं) को उस उपयोगकर्ता के रूप में लॉन्च किया जाएगा। यहां उठाया गया मुद्दा मुख्य रूप से डिबगिंग उद्देश्यों के लिए प्रमाणित उपयोगकर्ताओं को रूट - या किसी भी उपयोगकर्ता के साथ निष्पादित करने के लिए मैन्युअल विकल्प की अनुमति देना था।

यहां उठाया गया मुद्दा मुख्य रूप से डिबगिंग उद्देश्यों के लिए प्रमाणित उपयोगकर्ताओं को रूट - या किसी भी उपयोगकर्ता के साथ निष्पादित करने के लिए मैन्युअल विकल्प की अनुमति देना था।

और मेरा कहना यह है कि उपयोगकर्ता को एक कंटेनर को रूट के रूप में चलाने से रोकने के लिए आज हमारे पास जो नियंत्रण हैं, उन्हें रूट के साथ निष्पादित करने से रोकने के लिए यहां भी लागू करने की आवश्यकता होगी।

@liggitt मुझे क्षमा करें, मुझे नहीं पता कि अधिक स्पष्ट तरीके से कैसे समझाया जाए। आपकी उपरोक्त टिप्पणी के संबंध में, इसे आजमाएं:

• अपने पॉड को चलाने वाले नोड पर ssh (मेरा पॉड काफ्का चला रहा है, काफ्का उपयोगकर्ता भी 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:/#
  यह स्थापित करने के बाद कि यह GKE के दृष्टिकोण से पहले से ही संभव है (यद्यपि गंभीर रूप से कष्टप्रद तरीके से), आप किस नई सुरक्षा चिंताओं के बारे में सोच रहे हैं? यह मुद्दा पहिया को फिर से नहीं खोज रहा है, यह एक सुविधा प्रदान करने के बारे में है।

यह स्थापित करने के बाद कि यह GKE के दृष्टिकोण से पहले से ही संभव है (यद्यपि गंभीर रूप से कष्टप्रद तरीके से), आप किस नई सुरक्षा चिंताओं के बारे में सोच रहे हैं?

समस्या कुबेरनेट्स एपीआई के माध्यम से शक्ति को उजागर कर रही है जो आज नहीं है। उपयोगकर्ता के लिए एपीआई के माध्यम से वर्कलोड चलाने की अनुमति देना सामान्य है और नोड तक एसएसएच एक्सेस की अनुमति नहीं है।

एपीआई के माध्यम से कार्य करना बहुत अच्छा है, जब तक:

1. क्लस्टर व्यवस्थापक के पास नीति के माध्यम से नियंत्रित करने की क्षमता है कि क्या इसकी अनुमति है
2. जिस तरह से नीति व्यक्त की जाती है वह मौजूदा नीति के अनुरूप है (इस मामले में, यह आदर्श रूप से उसी PodSecurityPolicy तंत्र के आधार पर किया जाएगा)
3. नया फ़ंक्शन पहले से सुरक्षित सिस्टम में कोई छेद नहीं खोलता है (डिफ़ॉल्ट बंद है, या मौजूदा नीति के आधार पर गेट किया गया है)

@liggitt बिल्कुल सही। इसलिए, सुरक्षा प्रभावों के दायरे को _node_ एक्सेस तक सीमित करने के बाद, हम ( @johnjjung और अन्य) अंततः इस चर्चा का उपयोग कार्रवाई योग्य पदार्थ के लिए करना शुरू कर सकते हैं। मैंने GKE प्लेटफॉर्म पर रूट के रूप में निष्पादित करने के लिए एक kubectl प्लगइन शुरू किया है। मुझे एडब्ल्यूएस और अन्य तक पहुंचने में थोड़ा समय लगेगा। @johnjjung क्या आप अभी भी अपने अंत तक लेने को तैयार हैं?

@liggitt ने आपके द्वारा किए गए संपादन को देखा, जो इस पर आगे बढ़ने में उपयोगी होगा। धन्यवाद।

संबंधित चर्चा के लिए, मौजूदा पॉड में अलग-अलग निर्दिष्ट उपयोगकर्ता आईडी सहित मनमानी कंटेनरों को चलाने की अनुमति देने का प्रस्ताव देखें - https://github.com/kubernetes/community/pull/1269

जितना अधिक आप चलाना चाहते हैं, उसके सुरक्षा पहलू मूल कंटेनर से प्रस्थान करते हैं, उतना ही महत्वपूर्ण यह है कि संपूर्ण युक्ति को एक सुसंगत कंटेनर के रूप में मौजूदा प्रवेश तंत्र द्वारा मान्य किया जा सके।

@ jordanwilson230 कोडबेस की समीक्षा कर रहे हैं, मुझे kubectl exec कमांड के लिए एकीकरण के बिंदु मिले, जो एक अच्छा शुरुआती बिंदु है, मुझे यकीन नहीं है कि मुझे अन्य कुबेरनेट्स कोडबेस में बदलाव करने होंगे जहां हम डॉकटर को अनुमति दे सकते हैं - तुम झंडे। कहा जा रहा है, मुझे लगता है कि मैं वहां कहीं से शुरू कर सकता हूं, और क्लस्टर व्यवस्थापक/पॉड सुरक्षा नीतियों आदि के साथ इस मुद्दे पर वापस सर्कल कर सकता हूं ... एक समय में एक कदम।

अगर किसी को पता है कि कुबेरनेट्स docker --user झंडे कहाँ चलाता है, उसके लिए परिवर्तन कहाँ करना है, तो यह मददगार होगा।

हाय @johnjjung। एक बार (<1.6) कुबेरनेट्स kubelets ने सीधे डॉकर का उपयोग किया और इस तरह के विकल्पों को पास कर सकता था। अब कई रनटाइम, सीआरआई का समर्थन करने के लिए एक मानक इंटरफ़ेस है। यह सीआरआई की क्षमताएं हैं जो यह निर्धारित करती हैं कि डॉकर जैसे रनटाइम को कौन से निर्देश पारित किए जा सकते हैं।

Kubernetes विभिन्न कंटेनर रनटाइम ( dockershim +Docker+ containerd , cri-containerd + containerd , rkt, cri-o, lxd, Frakti आदि) को बताता है कि क्या करना है सीआरआई इंटरफेस का उपयोग करते हैं। या तो सीधे cri-o रनटाइम कार्यान्वयन के लिए, या dockershim या cri-containerd जैसे शिम के माध्यम से। इसलिए हम यहां जो चाहते हैं उसे करने में सक्षम होने के लिए (कंटेनर की तुलना में एक अलग उपयोगकर्ता के रूप में चल रहे मौजूदा कंटेनरों में प्रक्रियाएं जोड़ें), आपको पहले उस विकल्प का समर्थन करने के लिए सीआरआई स्पेक को विस्तारित करने की आवश्यकता है (उदाहरण के लिए शायद ExecSync को एक uid विकल्प की आवश्यकता है, और LinuxContainerSecurityContext को इसे प्रतिबंधित करने की आवश्यकता नहीं है। मुझे लगता है कि @liggitt ने जितना ऊपर कहा है )।

फिर प्रत्येक कंटेनर रनटाइम या रनटाइम शिम आगे बढ़ सकता है और इसके लिए समर्थन लागू कर सकता है। डॉकर के लिए जिसका अर्थ है dockershim कार्यान्वयन का विस्तार करना ताकि सीआरआई स्पेक/इंटरफ़ेस को जोड़ने का समर्थन किया जा सके। हालांकि मुझे उम्मीद है कि कुछ और रिलीज के भीतर dockershim +डॉकर को cri-containerd + containerd के पक्ष में हटा दिया जाएगा, इसलिए हम शायद 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

डीबग कंटेनर प्रस्ताव के रूप में इस चर्चा के लिए भी प्रासंगिक है। आपको एक नई kubectl debug कमांड का उपयोग करके उसी पॉड स्पेस में दूसरी कंटेनर छवि चलाने देना चाहिए। संभवतः अतिरिक्त कंटेनर को किसी भिन्न उपयोगकर्ता के रूप में चलाया जा सकता है?

@whereisaaron आपकी पोस्ट एक बड़ी मदद है। यह सब विस्तार से लिखने के लिए धन्यवाद।

@whereisaaron विवरण के लिए धन्यवाद। अगर मैं आपको समझ रहा हूं, तो ऐसा लगता है कि डिबग प्रस्ताव (यदि यह हो जाता है) दिन के अंत में इसे रखने के लिए सबसे अच्छी जगह हो सकती है। सुनिश्चित नहीं है कि इसे काम करने के लिए अनुमोदित किया गया है, लेकिन यह मूल रूप से आपको उस पॉड को डीबग करने के लिए अपनी पसंद का एक कंटेनर संलग्न करने की अनुमति देता है (जो बहुत अच्छा लगता है), लेकिन क्या यह आपको अपने उपयोगकर्ता को मूल कंटेनर में बदलने की अनुमति देता है? साथ ही, क्या इसका मतलब यह है कि मुझे प्रतीक्षा करनी चाहिए या क्रि-कंटेनर का उपयोग करके पैच के साथ आगे बढ़ना चाहिए?

ऐसा लगता है कि इसे अभी तक लागू नहीं किए जाने का एक कारण यह था कि विभिन्न क्षेत्रों में काम करने वाले कई समूहों के साथ कई रेपो हैं।

@johnjjung मेरा मानना ​​​​है कि डीबग कंटेनर को कुबेरनेट्स 1.9 में 'अल्फा' सुविधा के रूप में लागू करने के लिए अनुमोदित किया गया है (जब तक आप स्पष्ट रूप से सुविधा को सक्षम नहीं करते हैं तब तक बंद कर दिया जाता है)। मुझे नहीं लगता कि उन्होंने इसे 1.9 में बनाया है। तो शायद 1.10 या उसके बाद तक नहीं।

जैसा कि मैं इसे समझता हूं, डिबग कंटेनर लक्ष्य पॉड 'डीबग किए जा रहे' के अंदर एक प्रक्रिया के रूप में चलते हैं, इसलिए वे पॉड के समान कर्नेल सुरक्षा संदर्भ में हैं, उनके पास बस अपनी कंटेनर छवि/फ़ाइल सिस्टम है। तो आप किसी भी प्रक्रिया को डीबग कर सकते हैं, और पॉड के किसी भी वॉल्यूम को माउंट कर सकते हैं। लेकिन चूंकि आप एक ही सुरक्षा संदर्भ में हैं, मुझे आश्चर्य है कि क्या आप यूआईडी पर उसी कर्नेल लगाए गए सीमा से फंस गए हैं जिसे आप पॉड में उपयोग कर सकते हैं या नहीं? मैं वहां निश्चित नहीं हूं, आपको इस पर काम कर रहे #sig-node लोगों से पूछना होगा।

सीआरआई को विस्तारित करने के संबंध में, मुझे लगता है कि ऐसा करने के लिए आपको #sig-node से बहुत अधिक समर्थन की आवश्यकता होगी, साथ ही विभिन्न रनटाइम परियोजनाओं से कोई आपत्ति नहीं होगी, जैसे cri-containerd , और cri-o , जो हो सकता है फिर समर्थन को लागू करना होगा।

मेरे पास आज ज्यादा समय नहीं है, लेकिन जीकेई पर चलने वालों के लिए, मैंने उपयोगकर्ता [-यू] ध्वज के साथ निष्पादन के लिए एक एड-हॉक कुबेक्टल प्लगइन बनाया है:

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

इंस्टॉल स्क्रिप्ट चलाकर उस प्लगइन या उन सभी को संशोधित/कॉपी करने के लिए स्वतंत्र महसूस करें। @johnjjung तक बस एक तदर्थ समाधान और अन्य अधिक लेने में सक्षम हैं।

एक वैकल्पिक समाधान है जो जीसीपी के लिए विशिष्ट नहीं है। यह SSH का बिल्कुल भी उपयोग नहीं करता है और केवल kubectl कार्य करने की आवश्यकता है।

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

क्या Kubectl-exec-user का पॉड उस व्यक्ति को सत्यापित करता है जिसका उपयोग करने वाले के पास उस कंटेनर तक पहुंच है जिसे खोलने का अनुरोध किया जा रहा है?

यह वापस आता है कि कुबेरनेट्स एपीआई किस एक्सेस की अनुमति देता है। यह तभी काम करेगा जब RBAC किसी कंटेनर को नोड डॉक सॉकेट माउंट करने की अनुमति देता है।

मेरे समाधान को एसएसएच की आवश्यकता के बिना नोड पर एक कंटेनर से बाहर निकलने का एक रचनात्मक तरीका मानें। सभी समान सुरक्षा शर्तों पर विचार करने की आवश्यकता है लेकिन कम से कम यह कुबेरनेट्स एपीआई सर्वर प्रतिबंधों का सम्मान करता है।

90d निष्क्रियता के बाद मुद्दे पुराने हो जाते हैं।
/remove-lifecycle stale के साथ समस्या को ताज़ा के रूप में चिह्नित करें।
अतिरिक्त 30d निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

अगर इस मुद्दे को अभी बंद करना सुरक्षित है तो कृपया /close के साथ ऐसा करें।

sig-testing, Kubernetes/test-infra और/या fejta को फ़ीडबैक भेजें।
/जीवनचक्र बासी

/निकालें-जीवनचक्र बासी

यह अत्यंत स्वागत योग्य होगा। सुरक्षा के प्रति जागरूक होने और सभी प्रक्रियाओं को गैर-रूट के रूप में चलाने के लिए दंडित किया जाना अच्छा नहीं है। (फिर से लिखना https://github.com/kubernetes/kubernetes/issues/30656#issuecomment-272055993)

/ हस्ताक्षर नोड

इस सुविधा के लिए एक रिबेस-आवश्यक अधूरा पीआर प्रतीत होता है: https://github.com/kubernetes/kubernetes/pull/59092। क्या कोई है जो इसे उठा सकता है और अंतिम रूप दे सकता है? सीसी @louyihua

+1
(मैं @SimenB के समान मुद्दे में भाग लेता हूं - मैं डिबगिंग उद्देश्यों के लिए सामान स्थापित करना चाहता हूं। वैसे, "डॉकर सीधे उपयोग करें" संकेत के लिए धन्यवाद)

जबकि हम इसके ठीक से समर्थित होने की प्रतीक्षा कर रहे हैं, एक मध्यवर्ती समाधान यह हो सकता है कि आप अपने डॉकर सीएमडी को su-exec (या तो डॉकरफाइल या K8s मेनिफेस्ट में) के साथ चलाएं। su-exec का वजन केवल 20k (अल्पाइन पर) होता है और इस तरह से आपका ऐप बिना विशेषाधिकार के चलेगा, जबकि अभी भी Kubectl exec में रूट है।

+1

मैं ऐसे -यू ध्वज की भी सराहना करता हूं। +1।

एक विचार है:

उदाहरण के लिए --conainer-type जैसा कुछ किसी भी समर्थित तर्क को सीधे अंतर्निहित कंटेनर कार्यान्वयन में सक्षम करने के लिए एक बड़ा प्लस होगा:

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

यह Kubectl में कंटेनर रनटाइम की अंतर्निहित कार्यक्षमता का केवल एक सबसेट होने से बच जाएगा। इसके अलावा यह प्रयास बचाता है क्योंकि क्यूबलेट परत से समर्थित तर्कों को हर समर्थित कंटेनर प्रकार के लिए कंटेनर तक सभी तरह से मैप और सार करने की कोई आवश्यकता नहीं है।

तो संक्षेप में --container-type ध्वज के बिना केवल Kubectl से अमूर्त तर्कों का उपयोग किया जा सकता है और अंतर्निहित कंटेनर प्रकार पूरी तरह से पारदर्शी है। ध्वज के साथ, कंटेनर विशिष्ट तर्कों को पारित किया जा सकता है। यह Kubectl के उपयोगकर्ता पर निर्भर करता है कि वह कंटेनर प्रकार से जुड़ना चाहता है या नहीं।

BTW: नोड में ssh के संकेत के लिए @SimenB को धन्यवाद और सीधे डॉकर का उपयोग करें। इससे मेरी समस्या अस्थायी रूप से हल हो गई। मिनिक्यूब का उपयोग करके मैं रूट के रूप में लॉग-इन करने के लिए निम्नलिखित कार्य करने में सक्षम था:
minikube ssh "docker exec -it -u 0 <container-id> bash"
शायद यह किसी के लिए मददगार हो सकता है।

एक वर्कअराउंड स्क्रिप्ट जो अप्रिय को स्वचालित करती है। आवश्यक नोड के लिए SSH पहुंच।

उपयोग:

```./shell-in-pod-as-root.sh[सीप]
./shell-into-pod-as-root.sh podname
./shell-into-pod-as-root.sh podname sh

Enjoy!

!/usr/bin/env बैश

सेट -xe

POD=$(kubectl पॉड "$1" का वर्णन करता है)
NODE=$(echo "$POD" | grep -m1 Node | awk -F'/' '{print $2}')
CONTAINER=$(echo "$POD" | grep -m1 'कंटेनर आईडी' | awk -F 'docker://' '{print $2}')

CONTAINER_SHELL=${2:-bash}

सेट +ई

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

अगर [ "$?" -जीटी 0]; फिर
सेट +x
इको 'SSH पॉड में विफल रहा। यदि आपको "निष्पादन योग्य फ़ाइल $PATH में नहीं मिली" जैसा त्रुटि संदेश दिखाई देता है, तो कृपया प्रयास करें:'
गूंज "$0 $1 श"
फाई
```

@Nowaker आप नेमस्पेस को कैसे हैंडल करते हैं?

90d निष्क्रियता के बाद मुद्दे पुराने हो जाते हैं।
/remove-lifecycle stale के साथ समस्या को ताज़ा के रूप में चिह्नित करें।
अतिरिक्त 30d निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

अगर इस मुद्दे को अभी बंद करना सुरक्षित है तो कृपया /close के साथ ऐसा करें।

sig-testing, Kubernetes/test-infra और/या fejta को फ़ीडबैक भेजें।
/जीवनचक्र बासी

/निकालें-जीवनचक्र बासी

मैं ऐसे -यू ध्वज की भी सराहना करता हूं। +1।

एक विचार है:

उदाहरण के लिए --conainer-type जैसा कुछ किसी भी समर्थित तर्क को सीधे अंतर्निहित कंटेनर कार्यान्वयन में सक्षम करने के लिए एक बड़ा प्लस होगा:

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

यह Kubectl में कंटेनर रनटाइम की अंतर्निहित कार्यक्षमता का केवल एक सबसेट होने से बच जाएगा। इसके अलावा यह प्रयास बचाता है क्योंकि क्यूबलेट परत से समर्थित तर्कों को हर समर्थित कंटेनर प्रकार के लिए कंटेनर तक सभी तरह से मैप और सार करने की कोई आवश्यकता नहीं है।

तो संक्षेप में --container-type ध्वज के बिना केवल Kubectl से अमूर्त तर्कों का उपयोग किया जा सकता है और अंतर्निहित कंटेनर प्रकार पूरी तरह से पारदर्शी है। ध्वज के साथ, कंटेनर विशिष्ट तर्कों को पारित किया जा सकता है। यह Kubectl के उपयोगकर्ता पर निर्भर करता है कि वह कंटेनर प्रकार से जुड़ना चाहता है या नहीं।

BTW: नोड में ssh के संकेत के लिए @SimenB को धन्यवाद और सीधे डॉकर का उपयोग करें। इससे मेरी समस्या अस्थायी रूप से हल हो गई। मिनिक्यूब का उपयोग करके मैं रूट के रूप में लॉग-इन करने के लिए निम्नलिखित कार्य करने में सक्षम था:
minikube ssh "docker exec -it -u 0 <container-id> bash"
शायद यह किसी के लिए मददगार हो सकता है।

हाँ - ऐसा करने के लिए केवल docker exec का उपयोग करना तुच्छ है - यह ज्यादातर स्थिरता के बारे में है - बहु-उपयोगकर्ता डॉकटर कंटेनर वास्तव में एक मजाक का एक सा है - एक VM को एक कंटेनर में परिवर्तित करने की विरासत।

मैं इस समय ग्राफाना के साथ काम कर रहा हूं - मुझे लगता है कि यह समय के साथ बीत जाएगा।

@bryanhuntesl ऊपर वर्कअराउंड की चर्चा है जिसके लिए नोड को मैन्युअल ssh'ing की आवश्यकता नहीं है। आप इस प्लगइन को भी आजमा सकते हैं - https://github.com/jordanwilson230/kubectl-plugins

क्या होगा यदि आप उपयोगकर्ताओं को नोड में ssh करने की अनुमति नहीं देना चाहते हैं? उपयोगकर्ताओं को नोड तक ssh एक्सेस की अनुमति देना, साथ ही उन्हें docker तक पहुंच की अनुमति देना, एक सुरक्षा जोखिम हो सकता है। डॉकर नामस्थान या k8s अनुमतियों के बारे में कुछ भी नहीं जानता है। यदि कोई उपयोगकर्ता docker exec चला सकता है, तो वह _any_ नाम स्थान के पॉड में निष्पादित कर सकता है।

एसएसएच उचित समाधान नहीं है, आईएमएचओ।

क्या होगा यदि आप उपयोगकर्ताओं को नोड में ssh करने की अनुमति नहीं देना चाहते हैं? उपयोगकर्ताओं को नोड तक ssh एक्सेस की अनुमति देना, साथ ही उन्हें docker तक पहुंच की अनुमति देना, एक सुरक्षा जोखिम हो सकता है। डॉकर नामस्थान या k8s अनुमतियों के बारे में कुछ भी नहीं जानता है। यदि कोई उपयोगकर्ता docker exec चला सकता है, तो वह _any_ नाम स्थान के पॉड में निष्पादित कर सकता है।

एसएसएच उचित समाधान नहीं है, आईएमएचओ।

मैं उस राय को दूसरा मानता हूं - सीधे पहुंच प्राप्त करने के लिए बैंड तंत्र से बाहर का उपयोग संभावित हमले क्षेत्र में वृद्धि कर रहा है।

क्या होगा यदि आप उपयोगकर्ताओं को नोड में ssh करने की अनुमति नहीं देना चाहते हैं? उपयोगकर्ताओं को नोड तक ssh एक्सेस की अनुमति देना, साथ ही उन्हें docker तक पहुंच की अनुमति देना, एक सुरक्षा जोखिम हो सकता है। डॉकर नामस्थान या k8s अनुमतियों के बारे में कुछ भी नहीं जानता है। यदि कोई उपयोगकर्ता docker exec चला सकता है, तो वह _any_ नाम स्थान के पॉड में निष्पादित कर सकता है।

एसएसएच उचित समाधान नहीं है, आईएमएचओ।

ऐसे समाधान हैं जिन्हें SSH @gjcarneiro की आवश्यकता नहीं है। इसके अलावा, उपयोगकर्ता को पहले अपनी सार्वजनिक SSH कुंजी को कंप्यूट मेटाडेटा में जोड़ना होगा, इससे पहले कि उन्हें SSH को नोड (यदि GCP पर) @bryanhuntesl तक पहुंच की अनुमति दी जाए।

@liggitt इस विषय को शुरू हुए तीन साल हो गए हैं, कोई निष्कर्ष?

मुझे यकीन नहीं है कि इस समाधान का पहले उल्लेख किया गया है, लेकिन हमने वर्कअराउंड के रूप में क्या किया है, हमारे सभी कंटेनरों में एक स्क्रिप्ट शामिल है जो आपको सही उपयोगकर्ता के रूप में लॉग इन करेगी। प्लस एक मोट:

डॉकरफाइल:

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} "

90d निष्क्रियता के बाद मुद्दे पुराने हो जाते हैं।
/remove-lifecycle stale के साथ समस्या को ताज़ा के रूप में चिह्नित करें।
अतिरिक्त 30d निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

अगर इस मुद्दे को अभी बंद करना सुरक्षित है तो कृपया /close के साथ ऐसा करें।

sig-testing, Kubernetes/test-infra और/या fejta को फ़ीडबैक भेजें।
/जीवनचक्र बासी

/निकालें-जीवनचक्र बासी

[exec-as] kubectl प्लगइन का उपयोग करें:

kubectl krew install exec-as

जैसा कि ऊपर उल्लेख किया गया है, इसके लिए वास्तव में एक केईपी और सुरक्षा निहितार्थों के बारे में चर्चा की आवश्यकता है। ऐसा नहीं है कि यह आवश्यक रूप से एक बुरा विचार है, इसका केवल सिस्टम पर महत्वपूर्ण प्रभाव पड़ता है और हमें कोडिंग शुरू करने से पहले एक डिज़ाइन की आवश्यकता होती है।

मुझे इसके लिए एक केईपी की समीक्षा करने और उसका पालन करने में मदद करने में खुशी होगी, लेकिन इसमें निश्चित रूप से कुछ गठजोड़ हैं और इसमें कुछ समय लग सकता है।

@ चमत्कार 2k - क्या आपने su -m -l u22055 की कोशिश की है? -m पर्यावरण चर को संरक्षित करने वाला माना जाता है।

@ चमत्कार 2k मैंने यह कोशिश की (trying to exec as root user) , लेकिन मिला No passwd entry for user '0'

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

नमस्कार। इस समस्या को हल करने के लिए, मैंने "kpexec" CLI विकसित किया।
कृपया अपनी प्रतिक्रिया दें।

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

पॉड चलाने वाले नोड पर:

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 उन अधिकांश क्लस्टरों के लिए जिनमें मैंने संचालित किया है, अंतर्निहित Node. मुझे संदेह है कि अक्सर दूसरों के लिए भी ऐसा होता है।

उन मामलों में, ऐसा लगता है कि अन्य प्रस्तुत विकल्प, जैसे कि कुबेक्टल प्लगइन्स ही एकमात्र तरीका हो सकता है - यह मानते हुए कि डॉकर डेमॉन तक कोई पहुंच नहीं है।

+1

खैर केईपी टेम्पलेट यहाँ है https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

मुझे लगा कि मैं देखूंगा कि एक लिखना कितना काम है और ... हाँ, मैं इसे लिखने वाला व्यक्ति नहीं हूं, टेम्पलेट ने मुझे चेकलिस्ट आइटम एक **Pick a hosting SIG.** में खो दिया है जो प्रक्रिया से अधिक परिचित है मसौदा शुरू करने के लिए? मैं बस एक सक्रिय Kubernetes उपयोगकर्ता के रूप में प्रस्ताव के समर्थन में अपने को चिपकाने के लिए एक जगह चाहता हूं।

यह अटपटा लग सकता है, लेकिन मुझे इस मुद्दे पर लगभग आधा दर्जन अच्छी तरह से कोडित / स्क्रिप्टेड / लिखित वर्कअराउंड दिखाई दे रहे हैं, इसलिए स्पष्ट रूप से वहां _are_ लोग हैं जो मुझसे प्रस्तावित तकनीकी समाधानों का मसौदा तैयार करने की बेहतर स्थिति में हैं।

मुझे ऐसा लगता है कि कुबेरनेट्स नया ओपनस्टैक बन गया है जहां PROCESS के कारण उचित समय सीमा में कुछ भी हासिल नहीं किया जा सकता है।

@VikParuchuri का मूल उपयोग मामला यहां कंटेनर को रूट के रूप में डीबग/समस्या निवारण करने में सक्षम होना है, भले ही कंटेनर स्वयं अविश्वसनीय उपयोगकर्ता के रूप में चल रहा हो। अच्छा उपयोग मामला, क्योंकि, अगर हल हो जाता है, तो यह हम सभी को गैर-रूट उपयोगकर्ताओं के रूप में कंटेनर चलाने के लिए प्रोत्साहित करता है। मैं

इससे पहले कि आप docker exec के लिए एक केईपी तैयार करें, एक त्वरित जांच करें कि k8s अल्पकालिक डिबग कंटेनर आपके लिए इस उपयोग के मामले को संबोधित नहीं करते हैं।

docker exec --user उस उपयोग के मामले को संबोधित करने का केवल एक ही तरीका है, और यह उपयोग किए जा रहे डॉकटर रनटाइम पर निर्भर करता है। जैसे ही k8s containerd , dockerd पर चला जाता है और दोस्त वैकल्पिक होते हैं या अब और इंस्टॉल भी नहीं करते हैं, तो यह संभवतः एक दूरंदेशी विकल्प नहीं है?

इस उपयोग के मामले को संबोधित करने का एक और k8s-मूल तरीका अल्पकालिक डिबग कंटेनर है। मान लें कि आपके पास एक अविश्वसनीय उपयोगकर्ता के रूप में एक कंटेनर चल रहा है। डीबग कंटेनर आपको लक्ष्य कंटेनर के समान प्रक्रिया स्थान में एक अस्थायी कंटेनर शुरू करने की अनुमति देता है, लेकिन रूट (या जो कोई भी) के रूप में चल रहा है। निष्पादन दृष्टिकोण पर इस दृष्टिकोण के कुछ महत्वपूर्ण फायदे हैं, विशेष रूप से आप डीबग कंटेनर के लिए छवि में अपने साथ किसी भी डीबग टूलिंग और उपयोगिताओं को ला सकते हैं। तो बर्तनों और संपादकों आदि के साथ अपनी लक्षित कंटेनर छवि को फूलने के बजाय, यदि आपको (🐑 .., दोषी!) में निष्पादित करने की आवश्यकता है, तो आप इसके बजाय एक अच्छी बड़ी स्विस सेना चाकू डीबग कंटेनर छवि रख सकते हैं और अपनी एप्लिकेशन छवियों को साफ रख सकते हैं . आप अपने डिबग कंटेनर में bash का उपयोग कर सकते हैं जब आपके लक्ष्य में केवल sh हो। आप उन कंटेनरों को भी डिबग कर सकते हैं जिनके पास निष्पादित करने के लिए कोई खोल नहीं है, जैसे एकल बाइनरी कंटेनर, या डिस्ट्रोलेस कंटेनर ।

उदाहरण के लिए कंटेनर को रूट के रूप में डीबग करने के लिए busybox का उपयोग करें।

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

मुझे लगता है कि यह यकीनन एक बेहतर मॉडल है, जिसमें यह कंटेनरों को अलग-थलग प्रक्रियाओं के रूप में मानता है, जिसे आप डिबगिंग के लिए 'संलग्न' करते हैं, बजाय इसके कि आपके द्वारा खोले गए मिनी-वीएम की तरह। नुकसान यह है कि मुझे नहीं लगता कि आप लक्ष्य के फाइल सिस्टम का निरीक्षण कर सकते हैं, जब तक कि आप बाहरी माउंट या 'खाली' माउंट साझा नहीं कर सकते। आप अपने लक्ष्य के साथ प्रक्रिया नाम स्थान साझा करते हैं, ताकि आप लक्ष्य कंटेनर के फाइल सिस्टम तक /proc/$pid/root के माध्यम से भी पहुंच सकें।

अल्पकालिक डिबग कंटेनरों ने पहले ही प्रक्रिया :-) को नेविगेट कर लिया है और कार्यान्वित किया गया है। ये कंटेनर अल्फा हैं क्योंकि ~1.16 और 1.18 kubectl में alpha debug कमांड शामिल है। अधिक जानकारी यहाँ:

संदर्भ:

• 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/enbling-and-using-ephemeral-containers-on-kubernetes-1-16/

विचारशील उत्तर के लिए धन्यवाद @whereisaaron :) मुझे लगता है कि यह चीजों को अच्छी तरह से पकड़ लेता है।

मुझे लगा कि मैं देखूंगा कि एक को लिखना कितना काम है और... हाँ, मैं इसे लिखने वाला व्यक्ति नहीं हूँ, टेम्पलेट ने मुझे चेकलिस्ट आइटम एक पर खो दिया एक होस्टिंग SIG चुनें। प्रक्रिया से परिचित कोई भी व्यक्ति मसौदा शुरू करना चाहता है? मैं बस एक सक्रिय Kubernetes उपयोगकर्ता के रूप में प्रस्ताव के समर्थन में अपने को चिपकाने के लिए एक जगह चाहता हूं।

केईपी काफी कठिन हो सकते हैं, लेकिन मैं उनके आसपास थोड़ा संदर्भ देना चाहता हूं। कुबेरनेट्स अपने आप में बहुत बड़ा है; संभावित परिवर्तनों में योगदानकर्ता आधार और उपयोगकर्ताओं दोनों के लिए एक बहुत बड़ा विस्फोट त्रिज्या है। एक नई विशेषता को लागू करना आसान लग सकता है, लेकिन इसमें दोनों समूहों को व्यापक रूप से प्रभावित करने की क्षमता है।

हम कोड आधार के कुछ हिस्सों का प्रबंधन एसआईजी को सौंपते हैं; और यह केईपी के माध्यम से है कि एक या एक से अधिक एसआईजी एक विशेषता पर सहमति के लिए आ सकते हैं। सुविधा क्या करती है, इस पर निर्भर करते हुए, यह एक एपीआई समीक्षा के माध्यम से जा सकता है, स्केलेबिलिटी चिंताओं आदि के लिए मूल्यांकन किया जा सकता है।

यह सब यह सुनिश्चित करने के लिए है कि जो उत्पादित होता है उसकी सफलता की सबसे बड़ी संभावना होती है और इसे इस तरह से विकसित किया जाता है कि एसआईजी इसका समर्थन करने के लिए तैयार हों। यदि मूल लेखक (लेखक) हट जाते हैं, तो इसे बनाए रखने की जिम्मेदारी एसआईजी पर आ जाती है। यदि कहें, किसी सुविधा को स्थिर में प्रचारित किया गया था और फिर बहिष्करण के लिए फ़्लैग किया गया था, तो उसे बहिष्कृत करने की नीति का पालन करते हुए उसे निकालने में कम से कम एक वर्ष का समय लगेगा .

यदि किसी सुविधा के लिए पर्याप्त मांग है, तो आमतौर पर कोई व्यक्ति जो KEP प्रक्रिया से अधिक परिचित है, वह इसे आगे बढ़ाने और इसे साथ रखने में मदद करने की पेशकश करेगा, लेकिन इसे चलाने के लिए अभी भी किसी की आवश्यकता है।

किसी भी मामले में, मुझे आशा है कि कम से कम इस बात पर प्रकाश डाला जाएगा कि एक सुविधा को मर्ज करने से जुड़ी एक प्रक्रिया क्यों है। :+1: यदि आपके कोई प्रश्न हैं, तो कृपया बेझिझक सीधे संपर्क करें।

नुकसान यह है कि मुझे नहीं लगता कि आप लक्ष्य के फाइल सिस्टम का निरीक्षण कर सकते हैं, जब तक कि आप बाहरी माउंट या 'खाली' माउंट साझा नहीं कर सकते।

मेरे लिए फाइल सिस्टम को रूट के रूप में निरीक्षण करना, और चल रही उपयोगिताओं जो फाइल सिस्टम के साथ रूट के रूप में इंटरैक्ट कर सकती हैं, अनुरोधित सुविधा के लिए समर्थन प्राप्त करने का नंबर एक कारण है। संक्षेप में, यह सुझाव मेरी समस्या का समाधान बिल्कुल नहीं करता है।

नुकसान यह है कि मुझे नहीं लगता कि आप लक्ष्य के फाइल सिस्टम का निरीक्षण कर सकते हैं

मैं इसके बारे में गलत था, क्योंकि आपका इंजेक्शन डीबग कंटेनर आपके लक्षित कंटेनर के साथ प्रक्रिया नामस्थान साझा करता है, आप अपने डीबग कंटेनर से लक्ष्य कंटेनर में किसी भी प्रक्रिया के फाइल सिस्टम तक पहुंच सकते हैं। और इसमें कंटेनर फाइल सिस्टम और उन कंटेनरों में लगे किसी भी फाइल सिस्टम दोनों को शामिल किया जाएगा।

कंटेनर फाइल सिस्टम /proc/$pid/root लिंक के माध्यम से पॉड में अन्य कंटेनरों को दिखाई देता है।

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

90d निष्क्रियता के बाद मुद्दे पुराने हो जाते हैं।
/remove-lifecycle stale के साथ समस्या को ताज़ा के रूप में चिह्नित करें।
अतिरिक्त 30d निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

अगर इस मुद्दे को अभी बंद करना सुरक्षित है तो कृपया /close के साथ ऐसा करें।

sig-testing, Kubernetes/test-infra और/या fejta को फ़ीडबैक भेजें।
/जीवनचक्र बासी

/निकालें-जीवनचक्र बासी

कुबेक्टल अल्फा डिबग-इट एपेमेरल-डेमो --इमेज = बिजीबॉक्स --टारगेट = क्षणिक-डेमो

error: ephemeral containers are disabled for this cluster

@whereisaaron ऐसा लगता है कि अधिकांश क्लाउड प्रदाता इसका समर्थन नहीं करते हैं, और प्रीमियर के लिए हम केवल एक नोड पर जा सकते हैं और docker exec कंटेनर में जा सकते हैं। तो फिर, उपयोगिता काफी सीमित लगती है।

/proc/$pid/root के माध्यम से भी पहुंच वह नहीं है जो मैं चाहता हूं, मुझे सीधी पहुंच चाहिए "साइड विंडो" के माध्यम से नहीं। उदाहरण के लिए apt/apk _in the महाद्वीप_ जैसे बर्तन चलाना आसान नहीं है जब रूट फाइल सिस्टम वह जगह नहीं है जहां वे इसकी अपेक्षा करते हैं।

मुझे एक समान समस्या थी: मुझे आधिकारिक हेल्म चार्ट (जेनकींस) द्वारा तैनात आधिकारिक छवि पर कुछ निर्देशिकाएं, लिंक बनाने और गैर-रूट उपयोगकर्ता के लिए अनुमति जोड़ने की आवश्यकता थी।

मैं इसे exec-as प्लगइन का उपयोग करके हल करने में सक्षम था।

नियोजित डॉकर पदावनति और बाद में हटाने के साथ, इसे कब संबोधित किया जाएगा? अल्पकालिक कंटेनर अभी भी अल्फा में हैं। डॉकर को सीआरआई के रूप में उपयोग किए बिना स्थिर विकल्प क्या है?

अल्फा होने के अलावा, अल्पकालिक कंटेनर केवल kubectl exec --user की तुलना में उपयोग करने के लिए बहुत अधिक जटिल है।

इसके लिए एक अन्य उपयोगकेस कंटेनरों में स्क्रिप्ट को मैन्युअल रूप से निष्पादित कर रहा है। उदाहरण के लिए, नेक्स्टक्लाउड की occ रखरखाव स्क्रिप्ट को www-data के रूप में चलाने की आवश्यकता है। छवि में कोई sudo या समान नहीं है, और डॉक्टर डॉकर वातावरण में docker exec -u 33 का उपयोग करने की सलाह देते हैं।

आप नेक्स्टक्लाउड के साथ चलकर समस्या का समाधान कर सकते हैं

su -s /bin/bash www-data

लेकिन यह आदर्श नहीं है।