Kubernetes: रूट स्वामित्व और सख्त अनुमतियों के साथ कंटेनर में वॉल्यूम बनाए जाते हैं

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

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

मैंने https://github.com/docker/docker/issues/9360 दायर किया

क्या इसे स्पष्ट रूप से बाध्य करने के लिए user और/या permissions विकल्प को volumeMounts या emptyDir जोड़ना उचित होगा?

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

बुधवार, 26 नवंबर, 2014 को सुबह 9:07 बजे, कार्लोस सांचेज़ नोटिफिकेशन @github.com
लिखा था:

क्या इसमें उपयोगकर्ता और/या अनुमति विकल्प जोड़ना उचित होगा
वॉल्यूममाउंट या खाली डीआईआर स्पष्ट रूप से इसे मजबूर करने के लिए?

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -64678153
.

ये मुझे अच्छा लग रहा है

यह एक अच्छा स्टार्टर प्रोजेक्ट है

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

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

Kuberentes पक्ष पर प्रस्तावित समाधान

1. पॉड बनाते समय, यदि कंटेनरों को शुरू करने से पहले खालीडिर वॉल्यूम की आवश्यकता होती है, तो प्रत्येक कंटेनर छवि से USER को पुनः प्राप्त करें (प्रत्येक कंटेनर छवि के लिए JSON का आत्मनिरीक्षण करें), यदि कोई कंटेनर अपनी मुख्य प्रक्रिया को गैर-रूट के रूप में लॉन्च कर रहा है, तो पॉड निर्माण विफल हो जाता है।
2. पॉड बनाते समय, यदि साझा वॉल्यूम बनाने से पहले उसे एक EmptyDir वॉल्यूम की आवश्यकता होती है, तो वॉल्यूम को माउंट करने वाले पहले कंटेनर के USER को इसे चुनें।
3. इस दृष्टिकोण के साथ समस्याएं:
   
   
   
   1. कुबेरनेट्स के साथ एक पॉड में कई कंटेनर हो सकते हैं जो एक वॉल्यूम साझा करते हैं, लेकिन प्रत्येक कंटेनर संभावित रूप से अलग-अलग उपयोगकर्ताओं के साथ अपनी प्रक्रियाओं को चला सकता है, जिसका अर्थ है कि भले ही वॉल्यूम के मालिक को बदल दिया गया हो, जब तक कि मालिक को एक समूह में नहीं बदला गया था कि सभी कंटेनरों को पता था (और सभी प्रासंगिक उपयोगकर्ता इसका हिस्सा थे), समस्या अभी भी मौजूद होगी।
      
      
      
      
      
      • इतना बड़ा सौदा नहीं है क्योंकि हम इसे docker/docker#9360 . के साथ संभाल सकते हैं
      
      
      
   
   
   2. समस्या का एक और दिलचस्प आयाम यह है कि कंटेनर के बाहर से साझा वॉल्यूम पर CHOWN चलाना विफल हो सकता है यदि होस्ट मशीन में कंटेनर के अंदर समान उपयोगकर्ता नहीं है (कंटेनर छवियां एक नया उपयोगकर्ता बना सकती हैं, जिससे होस्ट अनजान है, और प्रवेश प्रक्रिया उस उपयोगकर्ता के रूप में चलती है, लेकिन चूंकि वह उपयोगकर्ता होस्ट पर मौजूद नहीं है, होस्ट से उस उपयोगकर्ता के लिए CHOWN विफल हो जाएगा)।
      
      इसके लिए एक काम मेजबान और कंटेनर के बीच आदि/पासवार्ड फ़ाइल साझा करना है, लेकिन यह बहुत सीमित है।
      
      मेजबान के लिए एक और संभावित समाधान यह होगा कि आरंभीकरण के दौरान कंटेनर के अंदर कैसे पहुंचे (साझा वॉल्यूम माउंट होने से पहले), USER को पढ़ें कि मुख्य प्रक्रिया के साथ शुरू होगा और छवि "/ etc / passwd" फ़ाइल का उपयोग मैप करने के लिए करेगा। यूआईडी के लिए उपयोगकर्ता, और उस यूआईडी के लिए होस्ट पर साझा वॉल्यूम को चुनें (होस्ट पर CHOWN केवल तभी विफल होगा जब उसे उपयोगकर्ता _string_ नहीं मिलता है क्योंकि यह मैपिंग खोजने के लिए /etc/passwd का उपयोग करता है, लेकिन यह हमेशा UIDs के साथ सफल होता है क्योंकि यह बिना किसी लुकअप के सीधे यूंट वैल्यू सेट करता है)।
   
   

दोनों दृष्टिकोण मुझे ऐसा लगता है जैसे वे कुबेरनेट्स को कंटेनर में पहुंचकर अमूर्तता की एक परत तोड़ रहे हैं ताकि यह पता लगाया जा सके कि मुख्य प्रक्रिया किस उपयोगकर्ता के रूप में शुरू होगी, और उस जानकारी के साथ कंटेनर के बाहर कुछ कर रही है। मुझे लगता है कि सेटअप के दौरान (उपयोगकर्ता बनाने और स्थापित करने के बाद) किसी भी "माउंटेड वॉल्यूम" को चुनने के लिए कंटेनरों के लिए सही दृष्टिकोण होगा।

विचार?

@thockin , कुछ लोगों से बात करने के बाद, मुझे लगता है कि @carlossg एपीआई में उपयोगकर्ता को स्पष्ट रूप से निर्दिष्ट करने का दृष्टिकोण सबसे साफ काम होगा। मुझे कोई फर्क नहीं पड़ता कि हम अमूर्तता के icky उल्लंघन के बिना "छिपे हुए अनुमान" लागू कर सकते हैं (जैसे कंटेनर में पहुंचने के लिए यह पता लगाने के लिए कि किस उपयोगकर्ता नाम का उपयोग करना है और फिर संबंधित यूआईडी को समझने के लिए कंटेनर की /etc/passwd फ़ाइल को बढ़ाना )

एपीआई को संशोधित करने का प्रस्ताव:

• वैकल्पिक रूप से एक अहस्ताक्षरित पूर्णांक UID निर्दिष्ट करने के लिए EmptyDir , GitRepo , और GCEPersistentDisk संस्करणों के लिए API का विस्तार करें।
  
  
  
  • यदि UID निर्दिष्ट है, तो होस्ट निर्देशिका के स्वामी को उस UID में बदल देगा और अनुमतियों को 750 (उपयोगकर्ता: rwx , Group: r-x , World: --- ) जब वॉल्यूम डायरेक्टरी बनाई जाती है।
  
  
  • यदि यूआईडी निर्दिष्ट नहीं है, तो मेजबान मालिक को नहीं बदलेगा, लेकिन अनुमतियों को 757 पर सेट करेगा (उपयोगकर्ता: rwx , समूह: r-x , विश्व: rxw ), यानी विश्व लिखने योग्य, जब वॉल्यूम निर्देशिका बनाई जाती है।
  
  
  • HostDir के संस्करणों को अछूता छोड़ दिया जाएगा, क्योंकि वे निर्देशिकाएँ Kubernetes द्वारा नहीं बनाई गई हैं।
  
  
  • उपयोगकर्ता नाम स्ट्रिंग के बजाय यूआईडी की आवश्यकता होती है, इसलिए यदि उपयोगकर्ता होस्ट मशीन पर मौजूद है तो कोई समस्या नहीं है (ऊपर मुद्दा 2.ii)।
  
  

विचार?

सीसी: @bgrant0607 , @dchen1107 , @lavalamp

मुझे लगता है कि यूआईडी को वॉल्यूम में जोड़ना एक हैक और बेमानी है। मैं चाहूंगा कि हम करें
सही बात और पूरक समूह आईडी का समर्थन करने के लिए डॉकर प्राप्त करें।

https://github.com/docker/docker/issues/9360

गुरु, 18 दिसंबर, 2014 को अपराह्न 3:13 बजे, साद अली सूचनाएं @github.com ने लिखा:

@thockin https://github.com/thockin , कुछ लोगों से बात करने के बाद, I
@carlossg https://github.com/carlossg के दृष्टिकोण के बारे में स्पष्ट रूप से सोचें
एपीआई में उपयोगकर्ता को निर्दिष्ट करना सबसे साफ काम होगा। मैं नही
बात हम icky उल्लंघन किए बिना "छिपी हुई ह्युरिस्टिक्स" लागू कर सकते हैं
एब्स्ट्रैक्शन (जैसे किसी कंटेनर में पहुंचकर यह पता लगाना कि उपयोगकर्ता नाम क्या है
उपयोग करने के लिए और फिर पता लगाने के लिए कंटेनर की /etc/passwd फ़ाइल को माउंट करना
संबंधित यूआईडी)।

एपीआई को संशोधित करने का प्रस्ताव:

• EmptyDir, GitRepo, और GCEPersistentDisk वॉल्यूम के लिए API का विस्तार करें
  वैकल्पिक रूप से एक अहस्ताक्षरित पूर्णांक यूआईडी निर्दिष्ट करने के लिए।
  
  
  
  • अगर यूआईडी निर्दिष्ट है, तो मेजबान मालिक को बदल देगा
    
    उस यूआईडी के लिए निर्देशिका और अनुमतियों को 750 पर सेट करें (उपयोगकर्ता: rwx,
    
    Group: rx, World:---) जब वॉल्यूम डायरेक्टरी बनाई जाती है।
  
  
  • यदि यूआईडी निर्दिष्ट नहीं है, तो मेजबान मालिक को नहीं बदलेगा,
    
    लेकिन अनुमतियों को 757 पर सेट करें (उपयोगकर्ता: rwx, समूह: rx, विश्व: rxw),
    
    यानी वर्ल्ड राइटेबल, जब वॉल्यूम डायरेक्टरी बनाई जाती है।
  
  
  • उन निर्देशिकाओं के बाद से HostDir संस्करणों को अछूता छोड़ दिया जाएगा
    
    कुबेरनेट्स द्वारा नहीं बनाया गया है।
  
  
  • उपयोगकर्ता नाम स्ट्रिंग के बजाय यूआईडी की आवश्यकता है ताकि कोई समस्या न हो
    
    यदि उपयोगकर्ता होस्ट मशीन पर मौजूद है (ऊपर मुद्दा 2.ii)।
  
  

विचार?

सीसी: @bgrant0607 https://github.com/bgrant0607 , @dchen1107
https://github.com/dchen1107 , @lavalamp https://github.com/lavalamp

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -67573932
.

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

पुनरारंभ परिभाषित करें? क्या आपका मतलब है कि कंटेनर दुर्घटनाग्रस्त हो गया और वापस आ गया, या आप?
मतलब मशीन रिबूट हो गई और एक नया पॉड शेड्यूल किया गया और होने की उम्मीद है
पिछले पॉड द्वारा उपयोग किए गए डिस्क स्थान को पुनः प्राप्त करने में सक्षम? या कुछ और?

सोम, 12 जनवरी, 2015 को रात 11:56 बजे, लुकमान नोटिफिकेशन @github.com ने लिखा:

@ साद-अली https://github.com/saad-ali मुझे लगता है कि HostDir नहीं होना चाहिए
अछूता छोड़ दिया। आइए इस पर विचार करें: Hadoop पुनरारंभ होने पर, ब्लॉक को पुनर्स्थापित करता है
निर्देशिका से यह डेटा संग्रहीत करता है। यदि हम खालीडिर का उपयोग करते हैं, तो कंटेनर
जिसे पुनः आरंभ करने पर दूसरी निर्देशिका मिलेगी और पिछला डेटा होगा
खोया। और Hadoop को निर्देशिका की अनुमति और स्वामित्व की आवश्यकता होती है
Hadoop (HDFS) शुरू करने वाले उपयोगकर्ता के लिए सेट करें। अगर HostDir को बदलने की अनुमति नहीं है
प्रति उपयोगकर्ता अनुमतियाँ, फिर इसके समान उपयोग के मामलों को प्राप्त नहीं किया जा सकता है।
कृपया टिप्पणी करें।

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -69707793
.

@thockin पुनरारंभ कुछ भी हो सकता है। यह पॉड की विफलता या कंटेनर की विफलता के बाद हो सकता है। या कंटेनर को फिर से शुरू किया जा सकता है, कुछ कॉन्फ़िगरेशन बदलने के बाद (कॉन्फ़िगरेशन में बदलाव के बाद Hadoop को पुनरारंभ करने की आवश्यकता होती है)। क्या वह उत्तर देता है?

इस दस्तावेज़ में उल्लेख किया गया है कि जब कोई पॉड अनबाउंड होता है, तो खाली डायर हटा दिया जाता है। Hadoop के उपयोग के मामले में, डेटा आवश्यक हो सकता है और इसकी आवश्यकता तब हो सकती है जब Hadoop का दूसरा पॉड वापस आता है (या कंटेनर पुनरारंभ होता है)। इसलिए, डेटा को बनाए रखने के लिए HostDir का उपयोग किया जाना चाहिए, यहां तक ​​​​कि पॉड अनबाउंड भी है। लेकिन Hadoop को डेटा निर्देशिका के लिए उपयोगकर्ता के लिए अनुमतियों की आवश्यकता होती है। आशा है कि यह समझाता है।

docker/libcontainer/pull/322 के साथ, docker कंटेनर अब AdditionalGroups (पूरक समूह GIDs) निर्दिष्ट करने की अनुमति देते हैं। तो एक पॉड में विभिन्न कंटेनरों के बीच साझा वॉल्यूम को संभालने का एक अद्यतन प्रस्ताव:

• नए पॉड के लिए EmptyDir , GitRepo , या GCEPersistentDisk वॉल्यूम बनाते समय, क्यूबलेट करेगा:
  
  
  
  1. होस्ट मशीन पर पॉड के लिए एक नया लिनक्स समूह बनाएं
     
     
     
     
     
     • समूह अगले उपलब्ध समूह आईडी नंबर (जीआईडी) के साथ बनाया गया है
     
     
     
  
  
  2. नई निर्देशिका के समूह (होस्ट मशीन पर) को नए बनाए गए समूह में बदलें।
  
  
  3. नई निर्देशिका (होस्ट मशीन पर) की अनुमतियों को 770 (उपयोगकर्ता: rwx , समूह: rwx , विश्व: --- ) पर सेट करें।
  
  
  4. प्रत्येक डॉकटर कंटेनर के लिए, नए समूह के GID में AdditionalGroups में docker कंटेनर कॉन्फ़िगरेशन के माध्यम से पास करें।
     
     
     
     
     
     • अभी भी docker को libcontainer (https://github.com/docker/docker/issues/9360) के माध्यम से AdditionalGroups पास करने का समर्थन करने की आवश्यकता है।
     
     
     
     • अद्यतन करने की आवश्यकता हो सकती fsouza/go-dockerclient समर्थन करने के लिए AdditionalGroups
     
     
     
  
  
• नए पॉड के लिए HostDir वॉल्यूम बनाते समय, क्यूबलेट करेगा:
  
  
  
  • वॉल्यूम को अछूता छोड़ दें, क्योंकि उन निर्देशिकाओं को कुबेरनेट्स द्वारा नहीं बनाया गया है।
  
  
  • @LuqmanSahaf : यह बहस के लिए है, लेकिन मेरी सोच यह है कि चूंकि कुबेरनेट्स HostDir नहीं बनाता है, और चूंकि इसमें मौजूदा डेटा हो सकता है, कुबेरनेट्स को इसे संशोधित करने के व्यवसाय में नहीं आना चाहिए। हमें इसे HostDir के निर्माता और अनुरक्षक पर छोड़ देना चाहिए कि वह इसके स्वामित्व या अनुमतियों को संशोधित करे ताकि कंटेनरों को इसे एक्सेस करने की अनुमति मिल सके।
  
  

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

जैसे ही यूजर नेमस्पेस लैंड करता है, यह सब अधिक जटिल हो जाता है।

बुध, १४ जनवरी, २०१५ को दोपहर १२:०४ बजे, लुकमान नोटिफिकेशन @github.com ने लिखा:

इस दस्तावेज़
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/volumes.md#emptydir ,
उल्लेख करता है कि जब एक पॉड अनबाउंड होता है, तो खाली डीआईआर हटा दिया जाता है। उपयोग के मामले में
Hadoop, डेटा आवश्यक हो सकता है और किसी अन्य पॉड के लिए आवश्यक हो सकता है
Hadoop वापस आता है (या कंटेनर पुनरारंभ होता है)। तो, HostDir का उपयोग किया जाना चाहिए
डेटा जारी रखने के लिए यहां तक ​​कि पॉड भी अनबाउंड है। लेकिन Hadoop को अनुमतियों की आवश्यकता है
डेटा निर्देशिका के लिए उपयोगकर्ता के लिए सेट किया जाना चाहिए। आशा है कि यह समझाता है।

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -69881834
.

अगर मैं वर्तमान प्रस्ताव को सही ढंग से समझ रहा हूं, तो मुझे लगता है कि यह एक निश्चित वर्ग के अनुप्रयोगों के लिए आश्चर्यजनक व्यवहार पैदा करेगा।

कई पुराने एप्लिकेशन जो कम (विशेषाधिकार प्राप्त) पोर्ट से जुड़ते हैं, पहले रूट के रूप में शुरू होते हैं, फिर तुरंत किसी अन्य उपयोगकर्ता को विशेषाधिकार छोड़ देते हैं। ऐसे परिदृश्य में, एप्लिकेशन को रूट के रूप में प्रारंभ करने के लिए कंटेनर को कॉन्फ़िगर किया जाना चाहिए, और इसलिए मूल उपयोगकर्ता (रूट) के पास वॉल्यूम तक पहुंच होगी। एक बार जब एप्लिकेशन setuid(2) / seteuid(2) कॉल करता है, तो उसके पास अब एक्सेस नहीं होगा। अब उस निर्देशिका तक पहुंच प्राप्त करने का एकमात्र तरीका है कि एप्लिकेशन को शुरू करने से पहले कंटेनर को chown वॉल्यूम में संशोधित किया जाए। यह वह स्थिति है जिसमें मैं वर्तमान में हूं।

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

कम से कम खालीदिर को सुरक्षा संदर्भ (यदि निर्दिष्ट हो) के यूआईडी/जीआईडी/लेबल का उपयोग करना चाहिए।

मुझे लगता है कि यूआईडी को वॉल्यूम में जोड़ना एक हैक और बेमानी है। मैं चाहता हूं कि हम सही काम करें और पूरक समूह आईडी का समर्थन करने के लिए डॉकर प्राप्त करें।

+1, लेकिन यह भी:

कम से कम खालीदिर को सुरक्षा संदर्भ (यदि निर्दिष्ट हो) के यूआईडी/जीआईडी/लेबल का उपयोग करना चाहिए।

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

1. क्या खाली डीआईआर को माउंट करने वाले सभी कंटेनरों में एक ही यूआईडी होना चाहिए?
2. क्या कंटेनरों में ठीक वही SELinux विकल्प होने चाहिए?
3. क्या हम ऐसे मामलों का उपयोग कर सकते हैं जहां दो अलग-अलग SELinux संदर्भ हैं जो दोनों को वॉल्यूम का उपयोग करने की आवश्यकता है? क्या हम अलग-अलग कंटेनरों के अलग-अलग SELinux संदर्भों के लेबल से वॉल्यूम के लिए स्तरों को संश्लेषित कर सकते हैं जिनमें एक ही उपयोगकर्ता, भूमिका और प्रकार है, लेकिन विभिन्न स्तर हैं?

मुझे लगता है कि मैं शायद उस साधारण मामले पर ध्यान केंद्रित करना शुरू कर दूंगा जहां एक ही कंटेनर है। मैं पहले कंटेनर के सुरक्षा संदर्भ का उपयोग करूंगा जो पहले पॉड स्पेक में वॉल्यूम को मापता है और हम चर्चा के रूप में उपयोग करने के लिए संदर्भ निर्धारित करने के लिए रणनीति बदल सकते हैं।

@smarterclayton @thockin @erictune @pweil-

मुझे वास्तव में यहाँ के ह्युरिस्टिक्स पसंद नहीं हैं। मैं स्वीकार करता हूं कि मैंने सुझाव दिया था a
अनुमानी लेकिन वह आधा साल पहले था :)

Docker सपोर्ट के अलावा अभी तक नहीं किया जा रहा है, हम कुछ क्यों नहीं कर सकते?
पसंद:

1. सभी संस्करणों को एक अद्वितीय GID आवंटित किया जाता है (शायद मशीन-अद्वितीय या शायद
   मास्टर-आवंटित?)
2. सभी वॉल्यूम माउंटेड हैं g+srwx
3. पॉड के सभी कंटेनरों को उस पॉड के GID में सभी वॉल्यूम मिलते हैं
   पूरक समूह

शुद्ध परिणाम यह होना चाहिए कि पॉड के सभी कंटेनर सभी वॉल्यूम तक पहुंच सकें
पॉड में प्रतिबंध के बिना, भले ही प्रत्येक कंटेनर यूआईडी क्या हो
का उपयोग करना।

मैं SELinux लेबल के बारे में कुछ नहीं जानता, यह एक समस्या हो सकती है। मैं जोर देता हूँ
पॉड में सभी वॉल्यूम सभी कंटेनरों के लिए उपलब्ध होने चाहिए

आगे हमें "सभी वॉल्यूम" को परिभाषित करना होगा। खालीडिर बहुत स्पष्ट है। क्या
होस्टपाथ माउंट के साथ होता है जो अस्तित्व में नहीं था और इसके लिए बनाए गए थे
उपयोग? वाजिब लगता है। पहले मौजूद होस्टपाथ माउंट के बारे में क्या?
यह प्रयोग - हम उन्हें किसी भी तरह से बदल नहीं सकते। पीडी जैसी चीजों के बारे में क्या? क्या हम
एक पुनरावर्ती chown/chgrp/chmod Blech चलाएँ।

@mrunalp पूरक समूहों पर डोकर समर्थन की स्थिति के लिए।

https://github.com/docker/libcontainer/pull/603 के विलय की प्रतीक्षा की जा रही है।

मैं जोर देकर कहता हूं कि पॉड में सभी वॉल्यूम सभी कंटेनरों के लिए उपलब्ध होने चाहिए

कल रात इस बारे में सोचने में बहुत समय बिताया, और मैं इस बिंदु पर आपसे सहमत हूं।

मुझे नहीं पता कि इसका मतलब है कि हमें पॉड-स्तरीय सुरक्षा संदर्भ की आवश्यकता है या
कुछ, हालांकि :)

गुरु, 4 जून, 2015 को सुबह 8:40 बजे, पॉल मोरी ने नोटिफिकेशन @github.com लिखा:

मैं जोर देकर कहता हूं कि पॉड में सभी वॉल्यूम सभी कंटेनरों के लिए उपलब्ध होने चाहिए

पिछली रात के बारे में सोचने में बहुत समय बिताया, और मैं आपसे सहमत हूं
इस बिंदु पर।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108939442
.

हालांकि - मैं दो कंटेनरों को मिला सकता हूं और नहीं चाहता कि वे सामग्री (डीबी और वेब लॉग) साझा करें लेकिन इसके लिए एक काम साझा करें।

4 जून 2015 को दोपहर 12:22 बजे टिम होकिन नोटिफिकेशन @github.com ने लिखा:

मुझे नहीं पता कि इसका मतलब है कि हमें पॉड-स्तरीय सुरक्षा संदर्भ की आवश्यकता है या
कुछ, हालांकि :)

गुरु, 4 जून, 2015 को सुबह 8:40 बजे, पॉल मोरी ने नोटिफिकेशन @github.com लिखा:

मैं जोर देकर कहता हूं कि पॉड में सभी वॉल्यूम सभी कंटेनरों के लिए उपलब्ध होने चाहिए

पिछली रात के बारे में सोचने में बहुत समय बिताया, और मैं आपसे सहमत हूं
इस बिंदु पर।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108939442
.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

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

गुरु, 4 जून 2015 को सुबह 9:30 बजे, क्लेटन कोलमैन नोटिफिकेशन @github.com
लिखा था:

हालाँकि - मैं दो कंटेनरों को मिला सकता हूँ और नहीं चाहता कि वे साझा करें
सामग्री (डीबी और वेब लॉग) लेकिन के लिए एक काम साझा करें।

4 जून 2015 को दोपहर 12:22 बजे टिम होकिन नोटिफिकेशन @github.com
लिखा था:

मुझे नहीं पता कि इसका मतलब है कि हमें पॉड-स्तरीय सुरक्षा संदर्भ की आवश्यकता है या
कुछ, हालांकि :)

गुरु, 4 जून 2015 को सुबह 8:40 बजे, पॉल मोरी नोटिफिकेशन @github.com
लिखा था:

मैं जोर देकर कहता हूं कि पॉड में सभी वॉल्यूम सभी के लिए उपलब्ध होने चाहिए
कंटेनरों

पिछली रात के बारे में सोचने में बहुत समय बिताया, और मैं इससे सहमत हूं
आप
इस बिंदु पर।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-108939442>

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108957878
.

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

----- वास्तविक सन्देश -----

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

गुरु, 4 जून 2015 को सुबह 9:30 बजे, क्लेटन कोलमैन नोटिफिकेशन @github.com
लिखा था:

हालाँकि - मैं दो कंटेनरों को मिला सकता हूँ और नहीं चाहता कि वे साझा करें
सामग्री (डीबी और वेब लॉग) लेकिन के लिए एक काम साझा करें।

4 जून 2015 को दोपहर 12:22 बजे टिम होकिन नोटिफिकेशन @github.com
लिखा था:

मुझे नहीं पता कि इसका मतलब है कि हमें पॉड-स्तरीय सुरक्षा संदर्भ की आवश्यकता है या
कुछ, हालांकि :)

गुरु, 4 जून 2015 को सुबह 8:40 बजे, पॉल मोरी नोटिफिकेशन @github.com
लिखा था:

मैं जोर देकर कहता हूं कि पॉड में सभी वॉल्यूम सभी के लिए उपलब्ध होने चाहिए
कंटेनरों

पिछली रात के बारे में सोचने में बहुत समय बिताया, और मैं इससे सहमत हूं
आप
इस बिंदु पर।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-108939442>

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108957878
.

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108959938

एचआरएम।

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

----- वास्तविक सन्देश -----

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

----- वास्तविक सन्देश -----

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

गुरु, 4 जून 2015 को सुबह 9:30 बजे, क्लेटन कोलमैन नोटिफिकेशन @github.com
लिखा था:

हालाँकि - मैं दो कंटेनरों को मिला सकता हूँ और नहीं चाहता कि वे साझा करें
सामग्री (डीबी और वेब लॉग) लेकिन के लिए एक काम साझा करें।

4 जून 2015 को दोपहर 12:22 बजे टिम होकिन नोटिफिकेशन @github.com
लिखा था:

मुझे नहीं पता कि इसका मतलब है कि हमें पॉड-स्तरीय सुरक्षा संदर्भ की आवश्यकता है या
कुछ, हालांकि :)

गुरु, 4 जून 2015 को सुबह 8:40 बजे, पॉल मोरी नोटिफिकेशन @github.com
लिखा था:

मैं जोर देकर कहता हूं कि पॉड में सभी वॉल्यूम सभी के लिए उपलब्ध होने चाहिए
कंटेनरों

पिछली रात के बारे में सोचने में बहुत समय बिताया, और मैं इससे सहमत हूं
आप
इस बिंदु पर।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-108939442>

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108957878
.

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108959938

हमें पॉड में यूजर नेमस्पेस शेयर करना चाहिए।

गुरु, 4 जून 2015 को सुबह 10:32 बजे, क्लेटन कोलमैन नोटिफिकेशन @github.com
लिखा था:

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

----- वास्तविक सन्देश -----

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

----- वास्तविक सन्देश -----

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

गुरु, 4 जून 2015 को सुबह 9:30 बजे, क्लेटन कोलमैन <
सूचनाएं@github.com>
लिखा था:

हालाँकि - मैं दो कंटेनरों को मिला सकता हूँ और नहीं चाहता कि वे साझा करें
सामग्री (डीबी और वेब लॉग) लेकिन के लिए एक काम साझा करें।

4 जून 2015 को दोपहर 12:22 बजे टिम होकिन नोटिफिकेशन @github.com
लिखा था:

मुझे नहीं पता कि इसका मतलब है कि हमें पॉड-स्तरीय सुरक्षा संदर्भ की आवश्यकता है या
कुछ, हालांकि :)

गुरु, 4 जून 2015 को सुबह 8:40 बजे, पॉल मोरी <
सूचनाएं@github.com>
लिखा था:

मैं जोर देकर कहता हूं कि पॉड में सभी वॉल्यूम सभी के लिए उपलब्ध होने चाहिए
कंटेनरों

पिछली रात के बारे में सोचने में बहुत समय बिताया, और मैं सहमत हूं
साथ
आप
इस बिंदु पर।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108939442

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108957878

.

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108959938

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108983917
.

दो कंटेनरों का उपयोगकर्ता नाम स्थान संभवतः एक ही श्रेणी में होना चाहिए। लेकिन कंटेनर ए और बी के यूआईडी को == होने की आवश्यकता नहीं है, और कई मामलों में आप उन्हें तुच्छ रूप से == नहीं चाहते हैं, क्योंकि आप वॉल्यूम को "पढ़ना" चाहते हैं लेकिन इसे लिखना नहीं चाहते हैं।

----- वास्तविक सन्देश -----

हमें पॉड में यूजर नेमस्पेस शेयर करना चाहिए।

गुरु, 4 जून 2015 को सुबह 10:32 बजे, क्लेटन कोलमैन नोटिफिकेशन @github.com
लिखा था:

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

----- वास्तविक सन्देश -----

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

----- वास्तविक सन्देश -----

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

गुरु, 4 जून 2015 को सुबह 9:30 बजे, क्लेटन कोलमैन <
सूचनाएं@github.com>
लिखा था:

हालाँकि - मैं दो कंटेनरों को मिला सकता हूँ और नहीं चाहता कि वे साझा करें
सामग्री (डीबी और वेब लॉग) लेकिन के लिए एक काम साझा करें।

4 जून 2015 को दोपहर 12:22 बजे टिम होकिन नोटिफिकेशन @github.com
लिखा था:

मुझे नहीं पता कि इसका मतलब है कि हमें पॉड-स्तरीय सुरक्षा संदर्भ की आवश्यकता है या
कुछ, हालांकि :)

गुरु, 4 जून 2015 को सुबह 8:40 बजे, पॉल मोरी <
सूचनाएं@github.com>
लिखा था:

मैं जोर देकर कहता हूं कि पॉड में सभी वॉल्यूम सभी के लिए उपलब्ध होने चाहिए
कंटेनरों

पिछली रात के बारे में सोचने में बहुत समय बिताया, और मैं सहमत हूं
साथ
आप
इस बिंदु पर।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108939442

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108957878

.

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108959938

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108983917
.

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108987165

@smarterclayton

दो कंटेनरों का उपयोगकर्ता नाम स्थान संभवतः एक ही श्रेणी में होना चाहिए। लेकिन कंटेनर ए और बी के यूआईडी को == होने की आवश्यकता नहीं है, और कई मामलों में आप उन्हें तुच्छ रूप से == नहीं चाहते हैं, क्योंकि आप वॉल्यूम को "पढ़ना" चाहते हैं लेकिन इसे लिखना नहीं चाहते हैं।

क्या आपको लगता है कि हम इसका अनुमान इस बात से लगा सकते हैं कि क्या केवल पढ़ने के लिए ध्वज वॉल्यूममाउंट पर सेट है?

कुछ विचार...

1. एक कंटेनर के लिए वॉल्यूम बढ़ते समय यह कंटेनर के एससी को प्राप्त कर सकता है यदि इसमें कुछ भी सेट नहीं है।
2. एक जटिल मामले के लिए हम पहले बताए अनुसार SELinux लेबल की श्रेणियों का समर्थन करने के लिए वॉल्यूम के लिए SC को निर्दिष्ट कर सकते हैं और इस मामले में यह वॉल्यूम के SC को इनहेरिट नहीं करेगा
3. पूर्वनिर्धारित मात्रा एससी के लिए कंटेनर के एससी को वांछित सुरक्षा के अनुरूप तरीके से आवंटित करने की आवश्यकता होगी (यानी वॉल्यूम की सीमा s0:c1.c10 और कंटेनर में s0:c1,c2 , GID है जो केवल पढ़ा है, आदि ) परिष्कृत पहुंच के साथ कस्टम, जटिल दृष्टिकोण को सुविधाजनक बनाने के लिए

----- वास्तविक सन्देश -----

कुछ विचार...

1. एक कंटेनर के लिए वॉल्यूम बढ़ते समय यह एससी का उत्तराधिकारी हो सकता है
   कंटेनर अगर इसमें कुछ भी सेट नहीं है।

एचआरएम - इसका मतलब है कि एक कंटेनर वाला पॉड दो कंटेनर वाले पॉड से अलग व्यवहार करेगा?

1. एक जटिल मामले के लिए हम वॉल्यूम के समर्थन के लिए एससी का अनुमान लगा सकते हैं
   SELinux लेबल की श्रेणियां जैसा कि पहले उल्लेख किया गया है और इस मामले में यह नहीं होगा
   वॉल्यूम के एससी को इनहेरिट करें
2. पूर्वनिर्धारित मात्रा एससी के लिए कंटेनर के एससी को आवंटित करने की आवश्यकता होगी
   वांछित सुरक्षा के अनुरूप तरीके से (अर्थात मात्रा की सीमा होती है
   s0:c1.c10 और कंटेनर में s0:c1,c2 , GID जिसने केवल पढ़ा है, आदि) को
   परिष्कृत पहुंच के साथ कस्टम, जटिल दृष्टिकोण को सुविधाजनक बनाना

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108991796

एचआरएम - इसका मतलब है कि एक कंटेनर वाला पॉड दो कंटेनर वाले पॉड से अलग व्यवहार करेगा?

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

दीवार के खिलाफ फेंकने का एक और विचार - एक पूर्व-परिभाषित एससी से वॉल्यूम (विरासत या नहीं) पर एक रनइनरेंज नीति पर जाने में सक्षम होना और यह सत्यापित करना कि वॉल्यूम का अनुरोध करने वाले सभी कंटेनर एससी में किसी प्रकार की पहुंच होगी।

सुरक्षा एक तरफ - क्या हम इस बात से सहमत हो सकते हैं कि एक पीआर जो मोड को आराम देता है वह एक अच्छी बात है? मैं इसे पसंद करूंगा यदि गैर-रूट यूआईडी वॉल्यूम और जंक का उपयोग कर सके।

@thockin @smarterclayton

मुझे नहीं पता कि "रिलैक्स मोड" का क्या अर्थ है - क्या आप अधिक ठोस हो सकते हैं?

शुक्र, जून ५, २०१५ अपराह्न २:४१ बजे, पॉल मोरी नोटिफिकेशन @github.com ने लिखा:

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

@thockin https://github.com/thockin @smarterclayton
https://github.com/smarterclayton

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109447608
.

मेरा बुरा। मेरा मतलब था, 0700 के बजाय खाली डीआईआर 0777 बनाएं।

कम से कम हमारे लिए (पॉल) हम पहले कंटेनर के sc का उपयोग कर सकते हैं जो वॉल्यूम को तब तक मापता है जब तक हमें एक व्यापक समाधान नहीं मिलता। उपयोगकर्ता तब ऑर्डरिंग को नियंत्रित कर सकते हैं और हम कम से कम अखंड रहेंगे।

५ जून २०१५ को शाम ६:०१ बजे, पॉल मोरी ने नोटिफिकेशन @github.com लिखा:

मेरा बुरा। मेरा मतलब था, 0700 के बजाय खाली डीआईआर 0777 बनाएं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

@smarterclayton यही मैं आगे जा रहा था। हमें अभी भी इसे ठीक करने की आवश्यकता है
गैर-रूट यूआईडी मामला जब SELinux चलन में नहीं है - जो मुझे लगता है कि हमें इसकी आवश्यकता है
0777 मोड तब तक करना है जब तक हमारे पास डॉकर में पूरक समूह न हों।

शुक्र, जून ५, २०१५ को शाम ६:१३ बजे, क्लेटन कोलमैन नोटिफिकेशन @github.com
लिखा था:

कम से कम हमारे लिए (पॉल) हम पहले कंटेनर के sc का उपयोग कर सकते हैं कि
वॉल्यूम को तब तक माउंट करता है जब तक हमें एक व्यापक समाधान नहीं मिल जाता। उपयोगकर्ता तब नियंत्रित कर सकते हैं
आदेश देना और हम कम से कम अखंड रहेंगे।

५ जून २०१५ को शाम ६:०१ बजे, पॉल मोरी नोटिफिकेशन @github.com
लिखा था:

मेरा बुरा। मेरा मतलब था, 0700 के बजाय खाली डीआईआर 0777 बनाएं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109457218
.

मैं सहमत हूं कि पॉड वॉल्यूम (व्यक्तिगत या समूह) के लिए एक अलग सुरक्षा संदर्भ शायद आवश्यक है।

५ जून २०१५ को शाम ६:३९ बजे, पॉल मोरी ने नोटिफिकेशन @github.com लिखा:

@smarterclayton यही मैं आगे जा रहा था। हमें अभी भी इसे ठीक करने की आवश्यकता है
गैर-रूट यूआईडी मामला जब SELinux चलन में नहीं है - जो मुझे लगता है कि हमें इसकी आवश्यकता है
0777 मोड तब तक करना है जब तक हमारे पास डॉकर में पूरक समूह न हों।

शुक्र, जून ५, २०१५ को शाम ६:१३ बजे, क्लेटन कोलमैन नोटिफिकेशन @github.com
लिखा था:

कम से कम हमारे लिए (पॉल) हम पहले कंटेनर के sc का उपयोग कर सकते हैं कि
वॉल्यूम को तब तक माउंट करता है जब तक हमें एक व्यापक समाधान नहीं मिल जाता। उपयोगकर्ता तब नियंत्रित कर सकते हैं
आदेश देना और हम कम से कम अखंड रहेंगे।

५ जून २०१५ को शाम ६:०१ बजे, पॉल मोरी नोटिफिकेशन @github.com
लिखा था:

मेरा बुरा। मेरा मतलब था, 0700 के बजाय खाली डीआईआर 0777 बनाएं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109457218
.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

मैं सहमत हूं कि पॉड वॉल्यूम (व्यक्तिगत या समूह) के लिए एक अलग सुरक्षा संदर्भ शायद आवश्यक है।

मुझे ऐसा लगता है कि मेरे दिमाग को पूरी तरह से प्रेट्ज़ेलाइज़ करने के बाद सभी क्रमपरिवर्तनों के माध्यम से सोचते हुए कि आपको बिना किसी के संभालना होगा। :curly_loop: :curly_loop: :curly_loop:

तुलना के लिए, हम जानबूझकर इस तरह की चीजों के लिए लचीले नहीं हैं
RestartPolicy - इस तरह के किनारे के मामले के लिए समझदार अर्थशास्त्र को परिभाषित करना उचित है
प्रयास के लायक नहीं। क्या यह वास्तव में सुरक्षा के संदर्भ में प्रयास के लायक है?
जून 4, 2015 11:27 पूर्वाह्न पर, "पॉल वेइल" सूचनाएं @github.com ने लिखा:

एचआरएम - इसका मतलब है कि एक कंटेनर वाला पॉड ए . से अलग व्यवहार करेगा
दो कंटेनरों के साथ फली?

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

दीवार के खिलाफ फेंकने का एक और विचार - ए से जाने में सक्षम होना
एक RunInRange नीति के लिए वॉल्यूम (विरासत में मिली या नहीं) पर पूर्व-निर्धारित SC और
यह पुष्टि करते हुए कि वॉल्यूम का अनुरोध करने वाले सभी कंटेनर एससी में कुछ होगा
पहुंच का प्रकार।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -108999035
.

क्या हम इसे 0770 नहीं बना सकते हैं और इसके और प्रत्येक कंटेनर के लिए समूह आईडी सेट नहीं कर सकते हैं
फली? यह मोटा है लेकिन 0777 से बेहतर है और हमें जहां जाना चाहिए उसके करीब है
(आईएमओ पूरक जीआईडी)। जहाँ तक मैं देखता हूँ, सुरक्षा प्रसंग अभी तक नहीं है
एक कंटेनर को GID सेट करने दें...
5 जून 2015 को अपराह्न 3:01 बजे, "पॉल मोरी" नोटिफिकेशन @github.com ने लिखा:

मेरा बुरा। मेरा मतलब था, 0700 के बजाय खाली डीआईआर 0777 बनाएं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109452834
.

मैं इसके साथ रह सकता हूं अगर यह एक विशाल TODO और दाईं ओर डॉक्स के साथ आता है
स्थान।
5 जून 2015 को अपराह्न 3:13 बजे, "क्लेटन कोलमैन" नोटिफिकेशन @github.com ने लिखा:

कम से कम हमारे लिए (पॉल) हम पहले कंटेनर के sc का उपयोग कर सकते हैं कि
वॉल्यूम को तब तक माउंट करता है जब तक हमें एक व्यापक समाधान नहीं मिल जाता। उपयोगकर्ता तब नियंत्रित कर सकते हैं
आदेश देना और हम कम से कम अखंड रहेंगे।

५ जून २०१५ को शाम ६:०१ बजे, पॉल मोरी नोटिफिकेशन @github.com
लिखा था:

मेरा बुरा। मेरा मतलब था, 0700 के बजाय खाली डीआईआर 0777 बनाएं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109457218
.

मैं वास्तव में सरल धारणाओं इंट्रा-पॉड पर झुकना चाहता हूं। एससी को जोड़ा जा रहा है
वॉल्यूम आसान नहीं है।
5 जून 2015 को अपराह्न 3:44 बजे, "पॉल मोरी" नोटिफिकेशन @github.com ने लिखा:

मैं सहमत हूं कि पॉड वॉल्यूम के लिए एक अलग सुरक्षा संदर्भ
(व्यक्तिगत या समूह) शायद आवश्यक है।

मुझे भी ऐसा ही लगता है जब सोचते समय मेरा दिमाग पूरी तरह से प्रेट्ज़ेल हो गया
एक के बिना आपको क्या संभालना होगा, इसके सभी क्रमपरिवर्तन के माध्यम से। [छवि:
:curly_loop:] [इमेज: :curly_loop:] [इमेज: :curly_loop:]

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109468896
.

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

तो दो विकल्प प्रतीत होते हैं:

1. वॉल्यूम का उपयोग करने वाले पहले कंटेनर पर आधारित नियम (पॉड कंटेनर सूची में पहला)
2. स्पष्ट पॉड स्तर सेटिंग

पॉड स्तर डिफ़ॉल्ट एससी प्रकार का अर्थ है, जबकि पहला विकल्प भी समझ में आता है लेकिन ऑर्डर निर्भर और कुछ हद तक निहित है।

७ जून २०१५ को दोपहर १:५५ बजे टिम हॉकिन नोटिफिकेशन @github.com ने लिखा:

मैं वास्तव में सरल धारणाओं इंट्रा-पॉड पर झुकना चाहता हूं। एससी को जोड़ा जा रहा है
वॉल्यूम आसान नहीं है।
5 जून 2015 को अपराह्न 3:44 बजे, "पॉल मोरी" नोटिफिकेशन @github.com ने लिखा:

मैं सहमत हूं कि पॉड वॉल्यूम के लिए एक अलग सुरक्षा संदर्भ
(व्यक्तिगत या समूह) शायद आवश्यक है।

मुझे भी ऐसा ही लगता है जब सोचते समय मेरा दिमाग पूरी तरह से प्रेट्ज़ेल हो गया
एक के बिना आपको क्या संभालना होगा, इसके सभी क्रमपरिवर्तन के माध्यम से। [छवि:
:curly_loop:] [इमेज: :curly_loop:] [इमेज: :curly_loop:]

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109468896
.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

मैं सहमत हूं कि समूह आम तौर पर उपयोगी होता है। हालांकि यह लेबल के लिए काम नहीं करेगा।

७ जून २०१५ को दोपहर १:५० बजे टिम हॉकिन नोटिफिकेशन @github.com ने लिखा:

क्या हम इसे 0770 नहीं बना सकते हैं और इसके और प्रत्येक कंटेनर के लिए समूह आईडी सेट नहीं कर सकते हैं
फली? यह मोटा है लेकिन 0777 से बेहतर है और हमें जहां जाना चाहिए उसके करीब है
(आईएमओ पूरक जीआईडी)। जहाँ तक मैं देखता हूँ, सुरक्षा प्रसंग अभी तक नहीं है
एक कंटेनर को GID सेट करने दें...
5 जून 2015 को अपराह्न 3:01 बजे, "पॉल मोरी" नोटिफिकेशन @github.com ने लिखा:

मेरा बुरा। मेरा मतलब था, 0700 के बजाय खाली डीआईआर 0777 बनाएं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109452834
.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

हाँ, मैं सेलिनक्स को बिल्कुल नहीं जानता (इसने मुझे केवल कभी समस्याएँ दी हैं)
मुझे नहीं पता कि कैसे हल करना है - यहां जैसा ही है)।
7 जून 2015 को 11:05 पूर्वाह्न पर, "क्लेटन कोलमैन" नोटिफिकेशन @github.com ने लिखा:

मैं सहमत हूं कि समूह आम तौर पर उपयोगी होता है। हालांकि यह लेबल के लिए काम नहीं करेगा।

७ जून २०१५ को दोपहर १:५० बजे, टिम हॉकिन नोटिफिकेशन @github.com
लिखा था:

क्या हम इसे 0770 नहीं बना सकते हैं और इसके और प्रत्येक कंटेनर के लिए समूह आईडी सेट नहीं कर सकते हैं
फली? यह मोटा है लेकिन 0777 से बेहतर है और हमें जहां होना चाहिए, उसके करीब है
जाओ
(आईएमओ पूरक जीआईडी)। जहाँ तक मैं देखता हूँ, सुरक्षा प्रसंग अभी तक नहीं है
एक कंटेनर को GID सेट करने दें...
5 जून 2015 को अपराह्न 3:01 बजे, "पॉल मोरी" नोटिफिकेशन @github.com ने लिखा:

मेरा बुरा। मेरा मतलब था, 0700 के बजाय खाली डीआईआर 0777 बनाएं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-109452834>

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109784566
.

इसे 700 की तरह मानें - यदि लेबल अलग हैं तो आप इसे नहीं देख सकते हैं, यदि वे हैं तो आप कर सकते हैं।

इस संदर्भ में हम शायद सरल रहने जा रहे हैं और कहते हैं कि प्रत्येक वॉल्यूम में एक ही लेबल होता है, और प्रत्येक कंटेनर में एक ही लेबल होता है, और हम चाहते हैं कि पॉड में सब कुछ 99% मामलों में समान लेबल हो। अंततः हम चाहते हैं कि एक कंटेनर में एक अलग लेबल हो (जिसका अर्थ है कि वह अपने लेबल, अवधि के बाहर किसी भी चीज़ तक पहुँच सकता है)।

जून 7, 2015, पर 2:21 pm पर, thockin-सीसी [email protected] लिखा है:

हाँ, मैं सेलिनक्स को बिल्कुल नहीं जानता (इसने मुझे केवल कभी समस्याएँ दी हैं)
मुझे नहीं पता कि कैसे हल करना है - यहां जैसा ही है)।
7 जून 2015 को 11:05 पूर्वाह्न पर, "क्लेटन कोलमैन" नोटिफिकेशन @github.com ने लिखा:

मैं सहमत हूं कि समूह आम तौर पर उपयोगी होता है। हालांकि यह लेबल के लिए काम नहीं करेगा।

७ जून २०१५ को दोपहर १:५० बजे, टिम हॉकिन नोटिफिकेशन @github.com
लिखा था:

क्या हम इसे 0770 नहीं बना सकते हैं और इसके और प्रत्येक कंटेनर के लिए समूह आईडी सेट नहीं कर सकते हैं
फली? यह मोटा है लेकिन 0777 से बेहतर है और हमें जहां होना चाहिए, उसके करीब है
जाओ
(आईएमओ पूरक जीआईडी)। जहाँ तक मैं देखता हूँ, सुरक्षा प्रसंग अभी तक नहीं है
एक कंटेनर को GID सेट करने दें...
5 जून 2015 को अपराह्न 3:01 बजे, "पॉल मोरी" नोटिफिकेशन @github.com ने लिखा:

मेरा बुरा। मेरा मतलब था, 0700 के बजाय खाली डीआईआर 0777 बनाएं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-109452834>

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109784566
.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

मानव संसाधन विकास मंत्री
सूर्य, 7 जून, 2015 दोपहर 2:25 बजे क्लेटन कोलमैन नोटिफिकेशन @github.com
लिखा था:

इसे 700 की तरह मानें - यदि लेबल अलग हैं तो आप इसे नहीं देख सकते हैं, यदि वे हैं
आप ऐसा कर सकते हैं।

इस संदर्भ में हम शायद सरल रहेंगे और प्रत्येक खंड को कहेंगे
एक ही लेबल है, और हर कंटेनर में एक ही लेबल है, और हम चाहते हैं
पॉड में 99% मामलों में एक ही लेबल होने के लिए सब कुछ। आखिरकार हम
एक कंटेनर में एक अलग लेबल हो सकता है (जिसका अर्थ है कि यह एक्सेस कर सकता है
इसके लेबल, अवधि के बाहर कुछ भी)।

जून 7, 2015, पर 2:21 pm पर, thockin-सीसी [email protected]
लिखा था:

हाँ, मैं सेलिनक्स को बिल्कुल नहीं जानता (इसने मुझे केवल कभी समस्याएँ दी हैं
वह
मुझे नहीं पता कि कैसे हल करना है - यहां जैसा ही है)।
7 जून 2015 को सुबह 11:05 बजे, "क्लेटन कोलमैन" नोटिफिकेशन @github.com
लिखा था:

मैं सहमत हूं कि समूह आम तौर पर उपयोगी होता है। हालांकि यह लेबल के लिए काम नहीं करेगा।

७ जून २०१५ को दोपहर १:५० बजे, टिम हॉकिन नोटिफिकेशन @github.com
लिखा था:

क्या हम इसे 0770 नहीं बना सकते हैं और इसके लिए समूह आईडी सेट नहीं कर सकते हैं?
कंटेनर में
फली? यह मोटा है लेकिन 0777 से बेहतर है और हम जहां के करीब हैं
चाहिए
जाओ
(आईएमओ पूरक जीआईडी)। जहाँ तक मैं देखता हूँ, सुरक्षा प्रसंग नहीं है
अभी तक
एक कंटेनर को GID सेट करने दें...
५ जून २०१५ अपराह्न ३:०१ बजे, "पॉल मोरी" नोटिफिकेशन @github.com
लिखा था:

मेरा बुरा। मेरा मतलब था, 0700 के बजाय खाली डीआईआर 0777 बनाएं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-109452834>

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-109784566>

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109785941
.

ऐसा नहीं लगता कि docker ने अभी तक समूह का नियंत्रण उजागर किया है। क्या मैं हूँ
कुछ याद आ रहा है, @thockin? क्या क्यूबलेट को सेट करना होगा
कंटेनर प्रक्रिया? मुझे रसिक लगता है।
सूर्य को, 7 जून, 2015 को अपराह्न 3:22 बजे पॉल मोरी [email protected] ने लिखा:

मानव संसाधन विकास मंत्री
सूर्य, 7 जून, 2015 दोपहर 2:25 बजे क्लेटन कोलमैन नोटिफिकेशन @github.com
लिखा था:

इसे 700 की तरह मानें - यदि लेबल अलग हैं तो आप इसे नहीं देख सकते हैं, यदि वे हैं
आप ऐसा कर सकते हैं।

इस संदर्भ में हम शायद सरल रहेंगे और प्रत्येक खंड को कहेंगे
एक ही लेबल है, और हर कंटेनर में एक ही लेबल है, और हम चाहते हैं
पॉड में 99% मामलों में एक ही लेबल होने के लिए सब कुछ। आखिरकार हम
एक कंटेनर में एक अलग लेबल हो सकता है (जिसका अर्थ है कि यह एक्सेस कर सकता है
इसके लेबल, अवधि के बाहर कुछ भी)।

जून 7, 2015, पर 2:21 pm पर, thockin-सीसी [email protected]
लिखा था:

हाँ, मैं सेलिनक्स को बिल्कुल नहीं जानता (इसने मुझे केवल कभी समस्याएँ दी हैं
वह
मुझे नहीं पता कि कैसे हल करना है - यहां जैसा ही है)।
7 जून 2015 को सुबह 11:05 बजे, "क्लेटन कोलमैन" नोटिफिकेशन @github.com
लिखा था:

मैं सहमत हूं कि समूह आम तौर पर उपयोगी होता है। यह लेबल के लिए काम नहीं करेगा
हालांकि।

७ जून २०१५ को दोपहर १:५० बजे, टिम हॉकिन नोटिफिकेशन @github.com
लिखा था:

क्या हम इसे 0770 नहीं बना सकते हैं और इसके लिए समूह आईडी सेट नहीं कर सकते हैं?
कंटेनर में
फली? यह मोटा है लेकिन 0777 से बेहतर है और हम जहां के करीब हैं
चाहिए
जाओ
(आईएमओ पूरक जीआईडी)। जहाँ तक मैं देखता हूँ, सुरक्षा प्रसंग नहीं है
अभी तक
एक कंटेनर को GID सेट करने दें...
५ जून २०१५ अपराह्न ३:०१ बजे, "पॉल मोरी" नोटिफिकेशन @github.com
लिखा था:

मेरा बुरा। मेरा मतलब था, 0700 के बजाय खाली डीआईआर 0777 बनाएं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-109452834>

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment-109784566>

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109785941
.

एकाधिक जीएच विफल, मेरा बुरा!

हम्म, मैंने सोचा कि डॉकर ने जीआईडी ​​​​सेट करने की अनुमति दी है। लानत है।
7 जून 2015 को दोपहर 1:23 बजे, "पॉल मोरी" नोटिफिकेशन @github.com ने लिखा:

ऐसा नहीं लगता कि docker ने अभी तक समूह का नियंत्रण उजागर किया है। क्या मैं हूँ
कुछ याद आ रहा है, @thockin? क्या क्यूबलेट को सेट करना होगा
कंटेनर प्रक्रिया? मुझे रसिक लगता है।
सूर्य को, 7 जून, 2015 को अपराह्न 3:22 बजे पॉल मोरी [email protected] ने लिखा:

मानव संसाधन विकास मंत्री
रविवार, जून ७, २०१५ अपराह्न २:२५ पर क्लेटन कोलमैन < सूचनाएं @github.com

लिखा था:

इसे 700 की तरह मानें - यदि लेबल अलग हैं तो आप इसे नहीं देख सकते हैं, यदि वे हैं
हैं
आप ऐसा कर सकते हैं।

इस संदर्भ में हम शायद सरल रहेंगे और प्रत्येक खंड को कहेंगे
एक ही लेबल है, और हर कंटेनर में एक ही लेबल है, और हम चाहते हैं
पॉड में 99% मामलों में एक ही लेबल होने के लिए सब कुछ।
आखिरकार हम
एक कंटेनर में एक अलग लेबल हो सकता है (जिसका अर्थ है कि यह कर सकता है
अभिगम
इसके लेबल, अवधि के बाहर कुछ भी)।

जून 7, 2015, पर 2:21 pm पर, thockin-सीसी [email protected]
लिखा था:

हाँ, मैं सेलिनक्स को बिल्कुल नहीं जानता (इसने मुझे केवल कभी समस्याएँ दी हैं
वह
मुझे नहीं पता कि कैसे हल करना है - यहां जैसा ही है)।
7 जून 2015 को सुबह 11:05 बजे, "क्लेटन कोलमैन" नोटिफिकेशन @github.com
लिखा था:

मैं सहमत हूं कि समूह आम तौर पर उपयोगी होता है। यह लेबल के लिए काम नहीं करेगा
हालांकि।

७ जून २०१५ को दोपहर १:५० बजे, टिम हॉकिन नोटिफिकेशन @github.com
लिखा था:

क्या हम इसे 0770 नहीं बना सकते हैं और इसके लिए समूह आईडी सेट नहीं कर सकते हैं?
कंटेनर में
फली? यह मोटा है लेकिन 0777 से बेहतर है और हम जहां के करीब हैं
चाहिए
जाओ
(आईएमओ पूरक जीआईडी)। जहाँ तक मैं देखता हूँ, सुरक्षा प्रसंग करता है
नहीं
अभी तक
एक कंटेनर को GID सेट करने दें...
५ जून २०१५ अपराह्न ३:०१ बजे, "पॉल मोरी" नोटिफिकेशन @github.com
लिखा था:

मेरा बुरा। मेरा मतलब था, 0700 के बजाय खाली डीआईआर 0777 बनाएं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109452834

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109784566

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109785941

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109797284
.

@थोकिन :'-/

सूर्य पर, 7 जून, 2015 को रात 8:54 बजे, टिम हॉकिन नोटिफिकेशन @github.com ने लिखा:

हम्म, मैंने सोचा कि डॉकर ने जीआईडी ​​​​सेट करने की अनुमति दी है। लानत है।

7 जून 2015 को दोपहर 1:23 बजे, "पॉल मोरी" नोटिफिकेशन @github.com ने लिखा:

ऐसा नहीं लगता कि docker ने अभी तक समूह का नियंत्रण उजागर किया है। क्या मैं हूँ
कुछ याद आ रहा है, @thockin? क्या क्यूबलेट को सेट करना होगा
कंटेनर प्रक्रिया? मुझे रसिक लगता है।
सूर्य को, 7 जून, 2015 को अपराह्न 3:22 बजे पॉल मोरी [email protected] ने लिखा:

मानव संसाधन विकास मंत्री
सूर्य पर, जून ७, २०१५ अपराह्न २:२५ क्लेटन कोलमैन <
सूचनाएं@github.com

लिखा था:

इसे 700 की तरह मानें - यदि लेबल अलग हैं तो आप इसे नहीं देख सकते हैं, यदि वे हैं
हैं
आप ऐसा कर सकते हैं।

इस संदर्भ में हम शायद सरल रहने जा रहे हैं और हर बात कह सकते हैं
आयतन
एक ही लेबल है, और हर कंटेनर में एक ही लेबल है, और हम
चाहते हैं
पॉड में 99% मामलों में एक ही लेबल होने के लिए सब कुछ।
आखिरकार हम
एक कंटेनर में एक अलग लेबल हो सकता है (जिसका अर्थ है कि यह कर सकता है
अभिगम
इसके लेबल, अवधि के बाहर कुछ भी)।

जून 7, 2015, पर 2:21 pm पर, thockin-सीसी [email protected]
लिखा था:

हाँ, मैं सेलिनक्स को बिल्कुल नहीं जानता (इसने केवल मुझे दिया है
समस्या
वह
मुझे नहीं पता कि कैसे हल करना है - यहां जैसा ही है)।
7 जून 2015 को 11:05 पूर्वाह्न, "क्लेटन कोलमैन" <
सूचनाएं@github.com>
लिखा था:

मैं सहमत हूं कि समूह आम तौर पर उपयोगी होता है। यह लेबल के लिए काम नहीं करेगा
हालांकि।

7 जून 2015 को दोपहर 1:50 बजे टिम होकिन <
सूचनाएं@github.com>
लिखा था:

क्या हम इसे 0770 नहीं बना सकते हैं और इसके लिए समूह आईडी सेट नहीं कर सकते हैं?
कंटेनर में
फली? यह मोटा है लेकिन 0777 से बेहतर है और हम जहां के करीब हैं
चाहिए
जाओ
(आईएमओ पूरक जीआईडी)। जहाँ तक मैं देखता हूँ, सुरक्षा प्रसंग करता है
नहीं
अभी तक
एक कंटेनर को GID सेट करने दें...
५ जून २०१५ अपराह्न ३:०१ बजे, "पॉल मोरी" नोटिफिकेशन @github.com
लिखा था:

मेरा बुरा। मेरा मतलब था, 0700 के बजाय खाली डीआईआर 0777 बनाएं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109452834

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109784566

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109785941

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109797284

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -109819177
.

@thockin @pmorie gid सेट करने का सिंटैक्स है --user " uid:gid "। उदाहरण के लिए

docker run -it --rm --user "1:777" busybox sh

@thockin @pmorie gid सेट करने का सिंटैक्स है --user " uid:gid "। उदाहरण के लिए

@pmorie @smarterclayton - हम शायद इसे एससी और एससीसी में पैच करना चाहते हैं।

हाँ हम करते हैं।

----- वास्तविक सन्देश -----

@thockin @pmorie gid सेट करने का सिंटैक्स है --user " uid:gid "। उदाहरण के लिए

@pmorie @smarterclayton - हम शायद इसे एससी और एससीसी में पैच करना चाहते हैं
फिर।

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110031779

@pweil-

सोम, जून 8, 2015 पूर्वाह्न 11:25 बजे, क्लेटन कोलमैन नोटिफिकेशन @github.com
लिखा था:

हाँ हम करते हैं।

----- वास्तविक सन्देश -----

@thockin @pmorie gid सेट करने का सिंटैक्स है --user " uid:gid "। के लिये
जैसे

@pmorie @smarterclayton - हम शायद इसे एससी में पैच करना चाहते हैं और
एससीसी
फिर।

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110031779

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110039834
.

डॉकर का वाक्य-विन्यास अत्याचारी है, कृपया इसे कॉपी न करें।
8 जून 2015 को सुबह 8:45 बजे, "पॉल मोरी" नोटिफिकेशन @github.com ने लिखा:

@pweil-

सोम, 8 जून, 2015 पूर्वाह्न 11:25 बजे, क्लेटन कोलमैन < सूचनाएं @github.com

लिखा था:

हाँ हम करते हैं।

----- वास्तविक सन्देश -----

@thockin @pmorie gid सेट करने का सिंटैक्स है --user " uid:gid "। के लिये
जैसे

@pmorie @smarterclayton - हम शायद इसे एससी में पैच करना चाहते हैं और
एससीसी
फिर।

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110031779

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110039834

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110049481
.

@thockin सहमत हैं, हमें सुरक्षा संदर्भ में एक विशिष्ट gid फ़ील्ड की आवश्यकता है

सोम, जून 8, 2015 पर 12:29 pm पर, thockin-सीसी [email protected]
लिखा था:

डॉकर का वाक्य-विन्यास अत्याचारी है, कृपया इसे कॉपी न करें।

8 जून 2015 को सुबह 8:45 बजे, "पॉल मोरी" नोटिफिकेशन @github.com ने लिखा:

@pweil-

सोम, जून 8, 2015 पूर्वाह्न 11:25 बजे, क्लेटन कोलमैन <
सूचनाएं@github.com

लिखा था:

हाँ हम करते हैं।

----- वास्तविक सन्देश -----

@thockin @pmorie gid सेट करने का सिंटैक्स है --user " uid:gid "।
के लिये
जैसे

@pmorie @smarterclayton - हम शायद इसे एससी में पैच करना चाहते हैं
तथा
एससीसी
फिर।

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110031779

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110039834

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110049481

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -110065270
.

डॉकर का वाक्य-विन्यास अत्याचारी है, कृपया इसे कॉपी न करें।

निश्चित रूप से नहीं, हम एक RunAsGroup int64 फ़ील्ड जोड़ेंगे।

आवश्यकताओं के आधार पर, आप उपयोगकर्ता और समूह को स्ट्रिंग के रूप में संग्रहीत करना चाह सकते हैं। उन्हें डिफ़ॉल्ट रूप से पासवार्ड और समूह फ़ाइलों में देखा जाता है। यदि वे नहीं मिले हैं और संख्यात्मक हैं तो उन्हें uid/gid में बदल दिया जाता है।

तो मुझे पता है कि यह एक जंगली अनुचित विचार है, लेकिन पूरी तरह से शुद्धता तकनीकी और लेयरिंग पीओवी से मुझे ऐसा लगता है कि सही समाधान किसी भी डॉकर फ़ाइल में उपयोगकर्ता लाइन को मना/अनदेखा करना होगा और लोगों को कहीं कंटेनर का यूआईडी सेट करना होगा क्यूब पॉड/कंटेनर घोषणा में। (हालांकि यह अभी भी स्पष्ट रूप से कंटेनर के अंदर /etc/passwd को देखने के पागलपन से ग्रस्त है, अगर हम इसे एक स्ट्रिंग बनाते हैं तो कंटेनर के बाहर किसी चीज के यूआईडी की व्याख्या करें)

हालांकि अधिक गंभीरता से, जब तक हम उपयोगकर्ता नामस्थान तक नहीं पहुंच जाते, तब तक कोई अच्छा समाधान प्रतीत नहीं होता है। फिर हम बाहर एक यादृच्छिक यूआईडी/जीआईडी ​​उत्पन्न कर सकते हैं, खाली डीआईआर निर्देशिका को यूआईडी/जीआईडी ​​​​के लिए चुन सकते हैं और कंटेनर को अंदर की तरफ चलने दें जैसा कि यूआईडी/जीआईडी ​​​​चाहता है। जब तक हम उस बिंदु तक नहीं पहुंच जाते तब तक कुछ भी नहीं बल्कि एक बदसूरत हैक है।

एक संबंधित बिंदु, केवल एफवाईआई, आज (सादा) डॉकर प्रत्येक कंटेनर के लिए यादृच्छिक सेलिनक्स संदर्भ चुन रहा है। डॉकर ने हाल ही में एक नया विकल्प -v /source:/dest:rw,z स्वीकार किया है। z भाग नया है। इसका मतलब chown -R के बराबर करना है, सिवाय इसके कि यह वॉल्यूम में सभी फाइलों पर सेलिनक्स लेबल को बेतरतीब ढंग से उत्पन्न लेबल पर सेट करता है। उनके पास वास्तव में chown -R और uid/gid सेट करने का विकल्प नहीं है, लेकिन मुझे पता है कि कुछ लोग इसे भी चाहते हैं ...

व्यक्तिगत रूप से, मुझे लगता है कि वॉल्यूम पर सुरक्षा संदर्भ डालना और उपयोगकर्ता पर जटिलता को लागू करना एकमात्र 'साफ' विकल्प है जब तक कि हम इसे पूरी तरह से अनदेखा न करें जब तक कि उपयोगकर्ता नामस्थान वास्तविकता न हो। एक बड़ा कारण मुझे लगता है कि @thockin पूरक जीआईडी ​​​​समाधान पर कूदने के बजाय यह है क्योंकि कोई सेलिनक्स एनालॉग नहीं है। सेलिनक्स का उपयोग यूआईडी के समान ही किया जाता है। आपको एक मिलता है। और या तो यह बिल्कुल मेल खाता है या नहीं। यह समूहों की तरह नहीं है। आपके पास 1 से अधिक लेबल नहीं हो सकते। उपयोगकर्ता नाम स्थान के साथ भी, यह हिस्सा अभी भी एक पिटा होने जा रहा है...

८ जून २०१५ को शाम ६:४५ बजे, एरिक पेरिस नोटिफिकेशन @github.com ने लिखा:

तो मुझे पता है कि यह एक जंगली अनुचित विचार है, लेकिन पूरी तरह से शुद्धता तकनीकी और लेयरिंग पीओवी से मुझे ऐसा लगता है कि सही समाधान किसी भी डॉकर फ़ाइल में उपयोगकर्ता लाइन को मना/अनदेखा करना होगा और लोगों को कहीं कंटेनर का यूआईडी सेट करना होगा क्यूब पॉड/कंटेनर घोषणा में। (हालांकि यह अभी भी स्पष्ट रूप से कंटेनर के अंदर /etc/passwd को देखने के पागलपन से ग्रस्त है, अगर हम इसे एक स्ट्रिंग बनाते हैं तो कंटेनर के बाहर किसी चीज के यूआईडी की व्याख्या करें)

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

लोगों को किसी ज्ञात uid पर चित्र लिखने या किसी uid पर कार्य करने की आवश्यकता होती है। लेकिन यूजर नेमस्पेस तक पहुंचने के लिए सभी तैयारी का काम अब किया जा सकता है। और उपयोगकर्ता नामस्थान स्वामित्व की समस्या का समाधान नहीं करते हैं क्योंकि कंटेनरों में एकाधिक उपयोगकर्ता हो सकते हैं, इसलिए आप अभी भी नहीं जानते कि कौन सा यूआईडी मैप करना है जब तक कि छवि आपको संख्यात्मक यूआईडी के साथ न बताए।
एक संबंधित बिंदु, केवल एफवाईआई, आज (सादा) डॉकर प्रत्येक कंटेनर के लिए यादृच्छिक सेलिनक्स संदर्भ चुन रहा है। डॉकर ने हाल ही में एक नया विकल्प -v /source:/ dest:rw ,z स्वीकार किया है। Z भाग नया है। इसका मतलब chown -R के बराबर करना है, सिवाय इसके कि यह वॉल्यूम में सभी फाइलों पर सेलिनक्स लेबल को बेतरतीब ढंग से जेनरेट किए गए लेबल पर सेट करता है। उनके पास वास्तव में chown -R और uid/gid सेट करने का विकल्प नहीं है, लेकिन मुझे पता है कि कुछ लोग इसे भी चाहते हैं ...

व्यक्तिगत रूप से, मुझे लगता है कि वॉल्यूम पर सुरक्षा संदर्भ डालना और उपयोगकर्ता पर जटिलता को लागू करना एकमात्र 'साफ' विकल्प है जब तक कि हम इसे पूरी तरह से अनदेखा न करें जब तक कि उपयोगकर्ता नामस्थान वास्तविकता न हो। एक बड़ा कारण मुझे लगता है कि @thockin पूरक जीआईडी ​​​​समाधान पर कूदने के बजाय यह है क्योंकि कोई सेलिनक्स एनालॉग नहीं है। सेलिनक्स का उपयोग यूआईडी के समान ही किया जाता है। आपको एक मिलता है। और या तो यह बिल्कुल मेल खाता है या नहीं। यह समूहों की तरह नहीं है। आपके पास 1 से अधिक लेबल नहीं हो सकते। उपयोगकर्ता नाम स्थान के साथ भी, यह हिस्सा अभी भी एक पिटा होने जा रहा है...

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

यह विषय @jmccormick2001 के हितों के लिए प्रासंगिक है

@thockin @eparis NFS और अन्य !emptyDir संस्करणों के लिए इस समस्या पर चर्चा करने के लिए एक अलग मुद्दे को

हां

थू, जुलाई ९, २०१५ को रात ८:३४ बजे, पॉल मोरी नोटिफिकेशन @github.com ने लिखा:

@thockin https://github.com/thockin @eparis https://github.com/eparis
क्या इस समस्या पर चर्चा करने के लिए एक अलग मुद्दे को छीलने में योग्यता है
एनएफएस और अन्य !खाली डीआईआर वॉल्यूम?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/2630#issuecomment -120213150
.

कुबेरनेट्स टीम ने इसके लिए फिलहाल क्या सुझाव दिया है? मुझे जो विकल्प दिखाई दे रहे हैं वे इस प्रकार हैं:

• रूट के रूप में चलाएं
• प्रारंभ में रूट के रूप में चलाएं और एक एंट्रीपॉइंट रैपर है जो अनुमतियों को छोड़ने से पहले निर्दिष्ट निर्देशिकाओं को दिखाता है (?? क्या यह भी काम करेगा?)

उनमें से कोई भी विशेष रूप से स्वादिष्ट नहीं लगता।

मैं देख रहा हूँ कि ७७७ तक chmod खालीडिर्स में एक सुधार किया गया था, लेकिन यह १.०.x में नहीं है (जो कि Google कंटेनर इंजन, मेरा पसंदीदा परिनियोजन लक्ष्य, उपयोग कर रहा है।) तो ऐसा लगता है कि मुझे खुदाई करनी है और एक का उपयोग करना है अभी के लिए उपरोक्त समाधानों में से।

Kubernetes v1.1 जल्द ही इस मामले के लिए बेहतर समर्थन के साथ बाहर होगा!

@pmorie

सोम, 2 नवंबर, 2015 को सुबह 9:03 बजे, जोशुआ क्वान सूचनाएं @github.com
लिखा था:

कुबेरनेट्स टीम ने इसके लिए कुछ समय के लिए क्या समाधान सुझाया है
हो रहा? मुझे जो विकल्प दिखाई दे रहे हैं वे इस प्रकार हैं:

• रूट के रूप में चलाएं
• प्रारंभ में रूट के रूप में चलाएं और एक एंट्रीपॉइंट रैपर है जो चाउन करता है
  अनुमतियाँ छोड़ने से पहले निर्दिष्ट निर्देशिकाएँ (?? क्या यह भी काम करेगी?)

उनमें से कोई भी विशेष रूप से स्वादिष्ट नहीं लगता।

मैं देख रहा हूँ कि एक फिक्स chmod emptyDirs को ७७७ में किया गया था, लेकिन यह इसमें नहीं है
1.0.x (जो कि Google कंटेनर इंजन है, मेरी पसंदीदा तैनाती है
लक्ष्य, उपयोग कर रहा है।) तो ऐसा लगता है कि मुझे इसमें से किसी एक को खोदना है और उसका उपयोग करना है
अभी के लिए उपरोक्त समाधान।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/2630#issuecomment -153083650
.

@ joshk0 हम कंटेनरों के प्रवेश बिंदु (एक बैश स्क्रिप्ट) से एक चाउन करते हैं और रनर या गोसु का उपयोग करके एक सामान्य उपयोगकर्ता का उपयोग करके अपनी मुख्य प्रक्रिया को चलाने के लिए वापस आते हैं।

आदर्श नहीं है, लेकिन इसे v1.0 पर करने का यही एकमात्र तरीका है।

@ joshk0 @antoineco हमने अभी-अभी एपीआई परिवर्तन पेश किए हैं जो आपको एक पूरक समूह निर्दिष्ट करने की अनुमति देंगे जो कि खाली डीआईआर और इसके डेरिवेटिव और कुछ ब्लॉक डिवाइस वॉल्यूम का मालिक है: # 15352

पॉल,

क्या हमारे पास इसके विकास के लिए कोई रोडमैप दस्तावेज़ है? हमने बात की
FSGid को प्रवेश पर स्वतः आवंटित किया जा रहा है, फिर शायद PVs के साथ जोड़ा जा रहा है
अंततः। यह देखना अच्छा होगा कि उस योजना को पूरी तरह से तैयार किया गया है।

मंगलवार, 3 नवंबर, 2015 को सुबह 7:01 बजे, पॉल मोरी नोटिफिकेशन @github.com ने लिखा:

@joshk0 https://github.com/joshk0 @antoineco
https://github.com/antoineco हमने अभी-अभी API परिवर्तन पेश किए हैं जो
आपको एक पूरक समूह निर्दिष्ट करने की अनुमति देगा जो कि खाली डीआईआर और उसके का मालिक है
डेरिवेटिव और कुछ ब्लॉक डिवाइस वॉल्यूम: #15352
https://github.com/kubernetes/kubernetes/pull/15352

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/2630#issuecomment -153381097
.

@thockin 3.1 के लिए परिष्करण सामग्री से मुक्त होने के बाद मुझे एक लिखना अच्छा लगेगा ... मैं इसके लिए एक मुद्दा

@pmorie प्रयोज्यता के मामले में अच्छा लग रहा है! इस पर काम करने के लिए धन्यवाद।
क्या माउंटपॉइंट पर अधिक बारीक मोड सेट करना भी संभव होगा? दाहिनी पंक्ति RW वॉल्यूम 0777 (1.1-बीटा.1) के साथ माउंट किए गए हैं। मेरे पास एक उपयोग का मामला है जहां यह मामूली मुद्दों का कारण बनता है:

❯ kubectl exec mypod -c logrotate -- ls -ld /var/log/containers/rails/
drwxrwxrwx    2 9999     root          4096 Nov  6 14:35 /var/log/containers/rails/

❯ kubectl exec mypod -c logrotate -- logrotate /etc/logrotate.conf  
error: skipping "/var/log/containers/rails/production.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.

@antoineco क्या आप उस वॉल्यूम के लिए खाली डीआईआर का उपयोग कर रहे हैं? मुझे लगता है कि मैं व्यवहार को बदलने के लिए एक मुद्दा बनाउंगा ताकि खालीडिर्स chmod a-rwx यदि FSGroup निर्दिष्ट किया गया हो।

हाँ, यह एक खाली डीआईआर वॉल्यूम है।

@antoineco ठीक है, मैं आज अगले सप्ताह एक यात्रा के लिए पैकिंग कर रहा हूं, लेकिन मैं इसके लिए एक मुद्दा

(क्या मैंने "क्यूबकॉन" सुना? )
आपने जो सुझाव दिया वह काम करेगा, लेकिन शायद आपका मतलब ओ -आरडब्ल्यूएक्स था, जो मोड और मालिक को निम्नानुसार सेट करेगा: 0770 root : FSGroup । या क्या मुझे सब कुछ गलत लगा?

@antoineco आपने किया :)

मुझे लगता है कि इसने चीजों को गलत तरीके से व्यक्त किया - मेरा मतलब था कि खालीडिर 0770 root:fsgroup g+s होना चाहिए।

@antoineco आपने कंटेनर के प्रवेश बिंदु से एक chown प्रदर्शन करने के लिए 1.0.X के लिए वर्कअराउंड के रूप में सुझाव दिया। क्या आपके पास इसका उदाहरण है?

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

@marcolenzo कुछ भी फैंसी नहीं है, मैं अपने प्रवेश बिंदु के रूप में एक छोटी बैश स्क्रिप्ट का उपयोग करता हूं: ENTRYPOINT ["/run.sh"]
यह स्क्रिप्ट साझा वॉल्यूम पर सही अनुमतियाँ सेट करती है और फिर मेरी सेवा शुरू करती है। उदाहरण:

#!/bin/sh

# reset permissions on log volumes
vol=/var/log/nginx
if [ -d "$vol" -a "$(stat -c '%U' "$vol" 2>/dev/null)" = "root" ]; then
    chown app "$vol"
    chmod o-rwx "$vol"
fi

# startup
echo "+-- starting nginx..."
exec nginx "$@"

मैंने देखा कि docker/docker#9360 के लिए PR को मर्ज कर दिया गया था: docker/docker#10717

क्या इसका मतलब यह है कि इस समस्या का समूह आईडी समाधान अब लागू किया जा सकता है? मेरे पास कई मामले हैं जहां मुझे वह करना पड़ा जो @antoineco को करना था, यानी छोटी मिनी स्टार्टअप स्क्रिप्ट बनाएं जो मुझे कई तृतीय पक्ष डॉकर छवियों का उपयोग करने में सक्षम होने से

@ charles-crain अब आप दो तरीकों से एपीआई के माध्यम से पूरक समूहों के साथ काम कर सकते हैं:

1. एक pod.spec.securityContext.supplementalGroups सूची है जो आपको सीधे पूरक समूह निर्दिष्ट करने देती है
2. एक pod.spec.securityContext.fsGroup फ़ील्ड है जो एक विशेष पूरक समूह है - यदि आप इसे निर्दिष्ट करते हैं, तो ब्लॉक डिवाइस और सिस्टम-जनरेटेड वॉल्यूम इस समूह के स्वामित्व में होंगे और प्रत्येक कंटेनर इस समूह के साथ पूरक समूहों की सूची में चलेगा।

क्या उससे मदद हुई? कृपया मुझे बताएं कि क्या आपको और अधिक जानकारी चाहिये?

@pmorie किस संस्करण से pod.spec.securityContext.supplementalGroups और pod.spec.securityContext.fsGroup समर्थित हैं? क्या यह गैर-मौजूदा होस्टपाथ पर भी लागू होता है जो पीओडी के पहली बार शुरू होने पर बनाए जाते हैं?

@pmorie प्रतिबद्ध लॉग के माध्यम से ऐसा लगता है कि fsGroup 1.2.0-alpha3 हाँ तक समर्थित नहीं है?

मुझे ऐसा लगता है कि यह समस्या केवल कुबेरनेट्स द्वारा बाइंड माउंट पर निर्भर होने के कारण होती है। डॉकर वॉल्यूम का उपयोग करते समय (यानी वॉल्यूम ड्राइवर का उपयोग करके बनाया गया, docker volume कमांड, या डॉकरफाइल से निहित VOLUME ) वॉल्यूम को डॉकर छवि से सामग्री के साथ प्रारंभ किया जाता है, और chwon छवि आवश्यकताओं से मेल खाने के लिए

@thockin , इस मुद्दे का अंतिम निर्णय क्या है? जेनकिंस और ग्लस्टरफ्स का उपयोग करते समय मैं उसी से मिलता हूं: जेनकींस यूआईडी का उपयोग कर रहा है यूआईडी द्वारा माउंट किया गया है

[root<strong i="9">@cdemo01</strong> jenkins]# kc logs jenkins-3tozq
touch: cannot touch ‘/var/jenkins_home/copy_reference_file.log’: Permission denied
Can not write to /var/jenkins_home/copy_reference_file.log. Wrong volume permissions?

@andrejvanderzee @ charles-crain मेरी ईमानदारी से क्षमा याचना, मैं किसी तरह इस धागे पर गीथब अलर्ट की धार में टैग से चूक गया। FSGroup 1.2.0 तक समर्थित है।

क्या यह गैर-मौजूदा होस्टपाथ पर भी लागू होता है जो पीओडी के पहली बार शुरू होने पर बनाए जाते हैं?

होस्ट पथ FSGroup या SELinux रीलेबलिंग का समर्थन नहीं करते हैं, क्योंकि वे पॉड को होस्ट पर कब्जा करने के लिए एक एस्केलेशन पथ प्रदान कर सकते हैं। हालांकि, उन्होंने कहा, यदि वे मौजूद नहीं हैं तो मेजबान पथ नहीं बनाए जाते हैं। क्या आप खाली डीआईआर के बारे में सोच रहे होंगे? खाली डीआईआर वॉल्यूम FSGroup और SELinux रिलेबेल दोनों का समर्थन करते हैं।

@ k82 glusterfs प्लगइन इस समय FSGroup का समर्थन नहीं करता है।

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

IIUC खाली डिर वॉल्यूम पॉड के लिए बनाए जाते हैं, लेकिन पॉड के हटाए जाने पर भी नष्ट हो जाते हैं, इसलिए उनका उपयोग लगातार डेटा के लिए नहीं किया जा सकता है (आमतौर पर, jenkins_home @ k82 परिदृश्य पर विचार करते हुए)।

वर्तमान में, मैं डेमो वातावरण के लिए वर्कअराउंड के रूप में 0777 का उपयोग कर रहा हूं; लेकिन उत्पादन के लिए एक बेहतर समाधान जरूरी है :)।

इसलिए मेरा इस मुद्दे को पढ़ना काफी हद तक कम हो गया है, हालांकि कुछ प्लगइन्स, विशेष रूप से जिन्हें ग्लस्टरफ्स की तरह साझा किया जाता है, वे इसका अच्छी तरह से समर्थन नहीं करते हैं। पॉल क्या FSGroup का उपयोग करने का एक राइटअप / वॉकथ्रू है?

प्रस्ताव के रूप में दस्तावेज़ है, और सुरक्षा संदर्भ के लिए कुछ दस्तावेज़ हैं, लेकिन यह शायद बेहतर उदाहरणों का उपयोग कर सकता है।

यहाँ fsgroup निर्देश का उपयोग करने का एक उदाहरण दिया गया है:

https://github.com/robustirc/robustirc/blob/master/Dockerfile (जो RUN echo 'nobody:x:99:99:nobody:/:/bin/sh' >> /etc/passwd और USER nobody निर्दिष्ट करता है) में परिभाषित डॉकर कंटेनर के लिए, मेरे कुबेरनेट्स प्रतिकृति नियंत्रक कॉन्फ़िगरेशन में निम्नलिखित संशोधन था ज़रूरी:

--- a/robustirc-node-1.rc.yaml  2016-07-11 22:04:31.795710444 +0200
+++ b/robustirc-node-1.rc.yaml  2016-07-11 22:04:37.815678489 +0200
@@ -14,6 +14,10 @@
     spec:
       restartPolicy: Always
       dnsPolicy: ClusterFirst
+      securityContext:
+        # Specify fsGroup so that the persistent volume is writable for the
+        # non-privileged uid/gid 99, which is used in robustirc’s Dockerfile.
+        fsGroup: 99
       containers:
       - name: robustirc
         image: robustirc/robustirc

1.4 के लिए वर्तमान सर्वोत्तम समाधान क्या है?

@stapelberg मैंने ठीक वैसे ही कोशिश की है जैसे आपने होस्टपाथ वॉल्यूम पर k8s 1.4.6 के साथ समझाया है, लेकिन मैं अभी भी देखता हूं कि रूट 755 अनुमतियों के साथ माउंटेड निर्देशिका का मालिक है। इसे कैसे डिबग करें इस पर कोई अतिरिक्त संकेत?

साथ ही, क्या यह वास्तविक नोड/होस्ट पर दिए गए उपयोगकर्ता/समूह के अस्तित्व पर निर्भर करता है जहां कंटेनर निर्धारित है?

आह .. सुनिश्चित नहीं है कि मैं सही कोड देख रहा हूं लेकिन ऐसा लगता है कि सेटअप विधि होस्टपाथ वॉल्यूम ड्राइवर के लिए कुछ भी नहीं करती है। देखें https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/host_path/host_path.go#L198

@thockin @saad-ali क्या आप कृपया पुष्टि कर सकते हैं? ऐसा लगता है कि आप लोग होस्टपाथ वॉल्यूम ड्राइवर बनाए हुए हैं।

चूंकि fsGroup Gluster के लिए अभी तक उपलब्ध नहीं है, क्या कंटेनर को रूट के रूप में चलाने के अलावा कोई अन्य अनुशंसित समाधान है?

FsGroup होस्टपाथ द्वारा समर्थित नहीं है, आप नहीं चाहते कि क्यूबलेट होस्ट पर इस तरह की अनुमति में बदलाव करे।

@pmorie क्यूबलेट की अनुमति क्यों नहीं देते? अन्यथा, जो हाथ मजबूर है वह मेजबान पर कुछ भी करने के लिए कंटेनर को root रूप में पूर्ण पहुंच प्रदान करना है ? आखिरकार, इसे मैनिफेस्ट में fsGroup द्वारा निर्दिष्ट करना होगा।

मैं @haf से उनकी "हाथ मजबूर" टिप्पणी के बारे में सहमत हूं।

उदाहरण के तौर पर, kube-aws टूल उपयोगकर्ताओं को क्लस्टर प्रोविज़निंग के दौरान सभी कर्मचारियों के लिए एक ऑटो-संलग्न NFS ड्राइव को कॉन्फ़िगर करने की अनुमति देता है। इसलिए, डिफ़ॉल्ट रूप से, हर एक कार्यकर्ता के पास एक AWS EFS ड्राइव होता है जो ऑनलाइन आने पर /efs पर आरोहित होता है (इसे पूरा करने के लिए हुड के नीचे क्लाउड-इनिट का उपयोग करता है)। फिर व्यवस्थापक उस NFS माउंट पर hostPath विकल्प को इंगित करके साझा संग्रहण PV बना सकते हैं।

इस प्रकार का हाइब्रिड सेटअप स्थापित करना बहुत आसान है, अच्छी तरह से काम करता है, और मुझे लगता है कि उन कारणों से बहुत से लोग इसका लाभ उठाना चाहेंगे। क्या यह hostPath लिए FsGroup विकल्प का समर्थन करने का एक अच्छा कारण नहीं है?

@ joan38 @rushtehrani मैं init-containers से chown वॉल्यूम का उपयोग करता हूं:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: jenkins
  name: jenkins
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: jenkins
      annotations:
        pod.alpha.kubernetes.io/init-containers: '[
        {
            "name": "jenkins-init",
            "image": "busybox",
            "imagePullPolicy": "IfNotPresent",
            "command": ["sh", "-c", "chown -R 1234:1234 /jenkins"],
            "volumeMounts": [
                {
                  "name": "jenkins-home",
                  "mountPath": "/jenkins"
                }
            ]
        }
    ]'
    spec:
      containers:
      - name: jenkins
        image: 'amarruedo/jenkins:v2.32.1'
             ..........
     volumes:
      - name: jenkins-home
        vsphereVolume:
          volumePath: "[FAS03_IDVMS] volumes/jenkins"
          fsType: ext4

मैं अपने कंटेनरों में यूआईडी और जीआईडी ​​​​को एक ज्ञात के रूप में परिभाषित करता हूं ताकि मैं chown में init-container । मैंने इस दृष्टिकोण का उपयोग hostPath संस्करणों के साथ-साथ बिना किसी समस्या के किया है। जब FSGroup बनाम क्षेत्र में उपलब्ध हो जाता है तो मैं इसका उपयोग करूंगा।

उम्मीद है ये मदद करेगा।

जैसा कि https://github.com/kubernetes/kubernetes/pull/39438#issuecomment -275459427 के साथ है, शायद हम केवल FSGroup सेट कर सकते हैं यदि होस्टपाथ बनाया जा रहा है?

इस पूरे सूत्र को पढ़ने के बाद मुझे नहीं पता कि संकल्प क्या था। मुझे एक समान समस्या हो रही है जहां मैं वर्चुअलबॉक्स का उपयोग कर मैक पर हूं और वॉल्यूम माउंट के साथ एक MySQL पॉड शुरू करने की कोशिश कर रहा हूं (मैंने भी कोशिश की है/उपयोगकर्ता लेकिन इसका एक ही व्यवहार है)। जब मिनीक्यूब निर्देशिका बनाता है तो वे मूल स्वामित्व और प्रतिबंधात्मक लेखन अनुमतियों के साथ बनाए जाते हैं। मैसकल उन्हें लिखने में सक्षम नहीं है और इसलिए मेरे पॉड्स क्रैश हो जाते हैं। अगर मैं minikube ssh और chmod -R 777 /data तो पॉड्स शुरू हो जाते हैं और सही तरीके से काम करते हैं। मुझे अलग क्या करना चाहिए ताकि मैं डेटा निर्देशिका की अनुमति को संशोधित किए बिना इस पॉड को शुरू कर सकूं?

@justechn आप https://kubernetes.io/docs/concepts/policy/security-context/ और https://kubernetes.io/docs/api-reference/v1.6/#podsecuritycontext -v1-core देखना चाहेंगे और fsGroup का मान सेट करें जो भी आपके MySQL डीमन के साथ चल रहा है।

एफएसग्रुप
स्वामित्व प्रबंधन का समर्थन करने वाले वॉल्यूम को fsGroup में निर्दिष्ट GID द्वारा स्वामित्व और लिखने योग्य होने के लिए संशोधित किया गया है।

@antoineco टिप के लिए धन्यवाद। मैं कुछ गलत कर रहा होगा क्योंकि यह मेरे लिए काम नहीं कर रहा है। मैंने पॉड में लॉग इन किया और भागा id mysql और वापस मिल गया uid=999(mysql) gid=999(mysql) groups=999(mysql) । इसलिए मैंने अपनी कल्पना में 999 के साथ fsGroup जोड़ा और पुनः आरंभ किया, लेकिन कुछ भी नहीं बदला। निर्देशिका अभी भी रूट के स्वामित्व में हैं।

spec: {
          containers: [
            {
              name: 'percona',
              image: 'percona:5.6',
              imagePullPolicy: 'Always',
              env: [
                {
                  name: 'MYSQL_ROOT_PASSWORD',
                  value: secrets['system-mysql-root-password'],
                },
                {
                  name: 'MYSQL_OPS_USER',
                  value: variables['system-mysql-ops-user'],
                },
                {
                  name: 'MYSQL_OPS_PASSWORD',
                  value: secrets['system-mysql-ops-password'],
                },
                {
                  name: 'MYSQL_APP_USER',
                  value: variables['system-mysql-app-user'],
                },
                {
                  name: 'MYSQL_APP_PASSWORD',
                  value: secrets['system-mysql-app-password'],
                },
              ],
              ports: [
                {
                  containerPort: 3306,
                  protocol: 'TCP',
                },
              ],
              volumeMounts: [
                { name: 'data', mountPath: '/var/lib/mysql' },
                { name: 'conf', mountPath: '/etc/mysql/conf.d' },
              ],
            },
          ],
          securityContext: {
            fsGroup: 999,
          },
          volumes: [
            { name: 'data', hostPath: { path: '/data/db/db' } },
            { name: 'conf', hostPath: { path: '/data/db/db-conf' } },
          ],
        },

drwxr-xr-x 2 root root 4096 May  9 18:14 db
drwxr-xr-x 2 root root 4096 May  9 18:14 db-conf
drwxr-xr-x 2 root root 4096 May  9 18:14 shared
drwxr-xr-x 2 root root 4096 May  9 18:14 shared-conf
drwxr-xr-x 2 root root 4096 May  9 18:14 shard-1
drwxr-xr-x 2 root root 4096 May  9 18:14 shard-1-conf

आपको पॉड सुरक्षा नीति को भी समायोजित करना पड़ सकता है:
https://kubernetes.io/docs/concepts/policy/pod-security-policy/

इस पर क्या प्रगति है?
यदि गैर-रूट उपयोगकर्ताओं का उपयोग कर रहे हैं तो हम पीवी तक कैसे पहुंच सकते हैं?

इस वजह से ZK मिनीक्यूब पर नहीं चलता है: https://github.com/kubernetes/charts/issues/976

FYI करें - इसमें आने वालों और @amaruedo द्वारा वर्कअराउंड का उपयोग करने वालों के लिए इसे नए v1.6+ सिंटैक्स में अपडेट करने की आवश्यकता होगी। और निम्न की तरह दिखता है:

      initContainers:
      - name: volume-mount-hack
        image: busybox
        command: ["sh", "-c", "chown -R 1000:100 /usr/share/elasticsearch/data"]
        volumeMounts:
        - name: data
          mountPath: /usr/share/elasticsearch/data

भले ही चाल चल रही हो, लेकिन अच्छा होगा जब यह मूल रूप से समर्थित हो।

कई घंटों की खोज को समाप्त करने वाले सुझावों के लिए @antoineco का धन्यवाद। ऐसा लगता है कि इस मुद्दे को मेजबान निर्देशिका पर ध्यान केंद्रित है, लेकिन वहाँ किसी भी संकेत लगातार खंड के भीतर "गैर-रूट उपयोगकर्ता के रूप में लगातार खंड का उपयोग करना" के लिए नहीं थे का उपयोग करना अनुभाग।

मैं एक स्टेटफुलसेट के लिए v1.7 और एक गतिशील रूप से प्रावधानित एडब्ल्यूएस पर्सिस्टेंट वॉल्यूम का उपयोग करके पॉड.स्पेक में एक साधारण जोड़ के साथ सफल रहा। मुझे पॉड सुरक्षा नीति की आवश्यकता नहीं थी:

      # Allow non-root user to access PersistentVolume
      securityContext:
        fsGroup: 1000

क्या हमारे पास एपीआई संदर्भ में संक्षिप्त उल्लेख की तुलना में अधिक दस्तावेज हो सकते हैं? यह जानना अस्पष्ट है कि कुछ वॉल्यूम प्रकार कौन से लोगों को जाने बिना काम करेंगे।

fsGroup: एक विशेष पूरक समूह जो पॉड के सभी कंटेनरों पर लागू होता है। कुछ वॉल्यूम प्रकार क्यूबलेट को उस वॉल्यूम के स्वामित्व को पॉड के स्वामित्व में बदलने की अनुमति देते हैं: 1. मालिकाना जीआईडी ​​FSGroup 2 होगा। सेटगिड बिट सेट है (वॉल्यूम में बनाई गई नई फाइलें FSGroup के स्वामित्व में होंगी) 3 अनुमति बिट्स rw-rw के साथ OR'd हैं ---- यदि सेट नहीं किया गया है, तो क्यूबलेट किसी भी वॉल्यूम के स्वामित्व और अनुमतियों को संशोधित नहीं करेगा।

• @antoineco आपके द्वारा उल्लिखित सुरक्षा संदर्भ अवधारणा दस्तावेज़ 404, बीटीडब्ल्यू देता है।
• ऐसा लगता है कि पीवी पर अभिगम नियंत्रण गैर-रूट पहुंच के समान लक्ष्य को प्राप्त करेगा। क्या डायनेमिक प्रोविजनिंग के साथ पीवी एनोटेशन सेट करना संभव है?

मैंने जेनकिंस के लिए एक एज़्योरफाइल लगातार वॉल्यूम माउंट करने की कोशिश की और अनुमति से इनकार करने की समस्या थी, क्योंकि जेनकिंस_होम निर्देशिका रूट के लिए केवल rwx थी, जब जेनकिंस जेनकिंस उपयोगकर्ता के साथ काम करता है।
मैं सुरक्षा कॉन्टेक्स्ट/runAsUser: 0 का उपयोग करके कामकाज कर सकता हूं लेकिन मौजूदा डीआईआर अधिकारों को प्राप्त करना या chmod संपत्ति प्रदान करना बेहतर होगा।

cc @kubernetes/sig-storage-feature-requests @kubernetes/sig-node-feature-requests

@ गिलाउम-मेयर - फाइलों के काम को chmod करने के लिए postStart जीवनचक्र हुक नहीं होगा (वैकल्पिक रूप से एक init कंटेनर अगर निष्पादन को प्रवेश बिंदु से पहले पूरा करने की आवश्यकता है)?

@ so0k यह काम नहीं करेगा यदि runAsUser और allowPrivilegeEscalation root उपयोगकर्ता को उपयोग करने से रोकते हैं।

मेरे पास एक बहुत ही समान उपयोग का मामला है जहां मुझे एक फ़ाइल के मालिक को बदलने की आवश्यकता होगी जो घुड़सवार है (मेरे मामले में एक रहस्य से)।

मेरे पास k8s में एक मोंगोडब-क्लस्टर है जो क्लस्टर प्राधिकरण के लिए एक विशेष cluster.key फ़ाइल का उपयोग करता है। वह फ़ाइल गुप्त रूप से संग्रहीत है; हमारे पास एक क्लाइंट है जहां छवियों को रूट के रूप में चलाना प्रतिबंधित है। हमारे पॉड में runAsUser: 1000 निर्देश के साथ एक सुरक्षा कॉन्टेक्स्ट सेट है। मोंगोडब स्वयं इस मामले को मना करता है कि फ़ाइल किसी और के द्वारा ही स्वामी के लिए सुलभ है। यदि फ़ाइल group या other द्वारा पढ़ने योग्य है तो यह स्टार्टअप को अस्वीकार कर देगा।

चूंकि मालिक root , और मैं उस फ़ाइल पर गैर-रूट के रूप में chown नहीं चला सकता, न तो अनुमतियाँ बदलना काम करता है, न ही (क्योंकि कोई k8s समर्थन नहीं है) फ़ाइल के मालिक को बदलना करता है।

मैं वर्तमान में एक बिजीबॉक्स इनिट कंटेनर में एक पर्यावरण चर के रूप में इंजेक्शन लगाकर इसके आसपास काम कर रहा हूं जो बदले में emptyDir माउंट करता है और वहां लिखता है। तब रहस्य को अब फ़ाइल के रूप में माउंट नहीं किया जाता है। यह काफी बदसूरत है, और अगर इससे छुटकारा पाने का कोई मौका है' तो मैं अंदर आ जाऊंगा।

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

@साद-अली

बुधवार, 21 फरवरी, 2018 को सुबह 9:34 बजे, जॉर्डन विल्सन सूचनाएं @github.com
लिखा था:

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

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

नमस्ते!
मैंने नोड-रेड-डॉकर कंटेनर देने के लिए नीचे दिए गए initContainers कॉन्फ़िगरेशन के साथ समाप्त किया, जो एक गैर-विशेषाधिकार प्राप्त उपयोगकर्ता के रूप में चलता है, बाहरी रूप से बनाई गई डिस्क तक पहुंच। बहुत सी चीजों की कोशिश करने के बाद, ऐसा लग रहा था कि "runAsUser" 0 (रूट) ने चाल चली है।

चियर्स
-जो

  initContainers:
    - name: volume-mount-hack
      image: nodered/node-red-docker:slim
      command:
        - sh
        - -c
        - 'chmod -R a+rwx /data'
      volumeMounts:
        - name: picturl-persistent-storage
          mountPath: /data
      securityContext:
        runAsUser: 0

कई पुराने एप्लिकेशन जो कम (विशेषाधिकार प्राप्त) पोर्ट से जुड़ते हैं, पहले रूट के रूप में शुरू होते हैं, फिर तुरंत किसी अन्य उपयोगकर्ता को विशेषाधिकार छोड़ देते हैं। ऐसे परिदृश्य में, एप्लिकेशन को रूट के रूप में प्रारंभ करने के लिए कंटेनर को कॉन्फ़िगर किया जाना चाहिए, और इसलिए मूल उपयोगकर्ता (रूट) के पास वॉल्यूम तक पहुंच होगी। एक बार जब एप्लिकेशन setuid(2)/seteuid(2) को कॉल करता है, तो उसके पास अब और एक्सेस नहीं होगा।

@ ईटनंबर 1 क्या आप इस बारे में कुछ और विस्तार से हैं कि इस धागे में उल्लिखित setuid(2) / seteuid(2) कॉलिंग प्रक्रिया के पूरक समूह को नहीं बदलेगा, इसलिए जब तक एप्लिकेशन एक ऐसे समूह में है जिसके पास वॉल्यूम तक पहुंच है, तो उसे समस्या नहीं होनी चाहिए वॉल्यूम तक पहुंचें, है ना?

ऐसा लगता है कि मुझसे गलती हुई थी और setgid(2) को कॉल करने से पूरक समूह नहीं बदलते (जो मैंने सोचा था कि यह किया था)।

चारों ओर देखकर, ऐसा लगता है कि कम से कम nginx पूरक समूहों को स्पष्ट रूप से यहां छोड़ देता है (और अन्यथा मामूली सुरक्षा भेद्यता होगी)। मुझे आश्चर्य होगा अगर कोई अच्छी तरह से लिखित विशेषाधिकार-छोड़ने वाला एप्लिकेशन पूरक समूहों को नहीं छोड़ता है।

धन्यवाद @ ईटनंबर1! तो Nginx शुरू में रूट के साथ चलता है, और बाद में nginx.conf में कॉन्फ़िगर किए गए uid, gid और पूरक समूहों को रीसेट करता है। फिर मुझे लगता है कि पॉड सुरक्षा संदर्भ के साथ , हम fsGroup में कॉन्फ़िगर किए गए समूह में nginx.conf सेट कर सकते हैं, इस तरह, Nginx अपने पूरक समूहों को रीसेट करने के बाद भी, यह अभी भी वॉल्यूम तक पहुंच सकता है। सही?

पॉड सुरक्षा संदर्भों के बारे में सरसरी तौर पर पढ़ने से, ऐसा लगता है कि यह होगा।
हालांकि मैंने उनका उपयोग नहीं किया है (ध्यान दें कि इस बग पर मेरी मूल टिप्पणी है
कई साल पुराना)।
शुक्र, 6 अप्रैल, 2018 को 20:28 बजे कियान झांग नोटिफिकेशन @github.com ने लिखा:

धन्यवाद @eatnumber1 https://github.com/eatnumber1 ! तो शुरू में Nginx
रूट के साथ चलता है, और बाद में यूआईडी, जीआईडी ​​और पूरक समूहों को व्हाट के साथ रीसेट करता है
nginx.conf में कॉन्फ़िगर किया गया है। तब मुझे लगता है कि पॉड सुरक्षा संदर्भ के साथ
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ ,
हम fsGroup को nginx.conf में कॉन्फ़िगर किए गए समूह में इस तरह सेट कर सकते हैं,
Nginx अपने पूरक समूहों को रीसेट करने के बाद भी, यह अभी भी एक्सेस कर सकता है
आयतन। सही?

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

पूरक समूह के अलावा, मुझे लगता है कि इस मुद्दे को ठीक करने के लिए पॉज़िक्स एसीएल एक और समाधान हो सकता है, मेरा मतलब है कि हम वॉल्यूम पर पॉड/कंटेनर उपयोगकर्ता को rwx अनुमति देने के लिए एसीएल प्रविष्टि जोड़ सकते हैं। लेकिन मुझे नहीं लगता कि इस धागे में पॉज़िक्स एसीएल का उल्लेख नहीं किया गया है, इसमें कोई कमी है?

cc @thockin @saad-ali

मुझे नहीं पता कि nginx समाशोधन अनुपूरक समूह किसी को रोकता है
इस मामले में भेद्यता? यह विशेष रूप से एक अच्छी तरह से समझे जाने वाले को हरा रहा है
तंत्र। क्या हम nginx को ठीक कर सकते हैं?

एसीएल या अन्य तंत्र के लिए, मुझे उनसे कोई आपत्ति नहीं है, मेरे पास बस कम है
उन पर संदर्भ।

सूर्य पर, अप्रैल ८, २०१८ शाम ६:२६ बजे कियान झांग नोटिफिकेशन @github.com ने लिखा:

पूरक समूह के अलावा, मुझे लगता है कि POSIX ACL
http://man7.org/linux/man-pages/man5/acl.5.html एक और समाधान हो सकता है
इस समस्या को ठीक करने के लिए, मेरा मतलब है कि हम rwx अनुमति देने के लिए ACL प्रविष्टि जोड़ सकते हैं
वॉल्यूम पर पॉड/कंटेनर उपयोगकर्ता के लिए। लेकिन मुझे नहीं लगता कि पॉज़िक्स एसीएल नहीं है
इस सूत्र में उल्लेख किया गया है, इसमें कोई कमियां हैं?

cc @thockin https://github.com/thockin @saad-ali
https://github.com/saad-ali

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

यह विशेष रूप से एक सुविचारित तंत्र को हरा रहा है।

@thockin क्या आप कृपया इस पर थोड़ा विस्तार कर सकते हैं? और हमें Nginx को ठीक करने की आवश्यकता क्यों है?

हम स्पष्ट रूप से पूरक समूह स्थापित करते हैं ताकि हम वॉल्यूम जैसी चीजें कर सकें
और प्रति मात्रा लेखांकन। यह 100% जानबूझकर है और फिर nginx बूँदें
सुरक्षा के नाम पर पूरक गुट वैध उपयोग के मामलों को तोड़ना।

सोम, 9 अप्रैल, 2018 को शाम 5:59 बजे कियान झांग नोटिफिकेशन @github.com ने लिखा:

यह विशेष रूप से एक सुविचारित तंत्र को हरा रहा है।
@thockin https://github.com/thockin क्या आप कृपया थोड़ा विस्तार से बता सकते हैं
यह? और हमें Nginx को ठीक करने की आवश्यकता क्यों है?

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

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

इसके अलावा, भले ही आप इसके बजाय उपयोग करने के लिए एक और अस्पष्ट लिनक्स एक्सेस कंट्रोल मैकेनिज्म चुनते हैं (उदाहरण के लिए,

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

PodSecurityContext के लिए प्रलेखन को fsGroup :

एक विशेष पूरक समूह जो पॉड के सभी कंटेनरों पर लागू होता है। कुछ वॉल्यूम प्रकार क्यूबलेट को उस वॉल्यूम के स्वामित्व को पॉड के स्वामित्व में बदलने की अनुमति देते हैं:

1. GID का स्वामी FSGroup होगा
2. सेटगिड बिट सेट है (वॉल्यूम में बनाई गई नई फाइलें FSGroup के स्वामित्व में होंगी)
3. अनुमति बिट्स OR'd rw-rw के साथ हैं ---- यदि सेट नहीं है, तो क्यूबलेट किसी भी वॉल्यूम के स्वामित्व और अनुमतियों को संशोधित नहीं करेगा।

जहां तक ​​​​मुझे पता है, ये क्रियाएं परिणामी अनपेक्षित उपयोगकर्ता को विशेषाधिकार ड्रॉप के बाद वॉल्यूम को सफलतापूर्वक एक्सेस करने की अनुमति देने के लिए पर्याप्त होनी चाहिए। (चेतावनी, मैंने इसका परीक्षण नहीं किया है)

हां, इसलिए मुझे लगता है कि fsGroup को nginx.conf में कॉन्फ़िगर किए गए समूह में सेट करने से Nginx एक विशेषाधिकार ड्रॉप के बाद भी वॉल्यूम तक पहुंच सकता है और वॉल्यूम अकाउंटिंग कार्य भी कर सकता है।

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

@qianzhangxa यदि कई कंटेनरों को उस वॉल्यूम तक पहुंच की आवश्यकता है, तो आपको यह सुनिश्चित करने की आवश्यकता होगी कि सभी कंटेनर कंटेनर स्तर के सुरक्षा संदर्भ में समान फ़ग्रुप का अनुरोध करें या पॉड स्तर पर बेहतर सेट करें

@tallclair FYI करें मुझे विश्वास है कि हम इस मुद्दे को बंद कर सकते हैं

/ हस्ताक्षर प्रमाणीकरण

सुझाए गए समाधानों में से कोई भी मेरे लिए काम नहीं कर रहा है।

वाईएमएल:

apiVersion: apps/v1beta1 # for versions before 1.8.0 use apps/v1beta1
kind: Deployment
metadata:
  labels:
    tier: frontend
spec:
  selector:
    matchLabels:
      tier: frontend
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      securityContext:
        fsGroup: 1000
        runAsUser: 0
      initContainers:
      - image: some-sftp-container
        name: sftp-mount-permission-fix
        command: ["sh", "-c", "chown -R <user> /mnt/permission-fix"]
        volumeMounts:
        - name: azure
          mountPath: /mnt/permission-fix
      containers:
      - image: some-sftp-container
        name: sftp-container
        ports:
        - containerPort: 22
          name: port_22
        volumeMounts:
        - name: azure
          mountPath: /home/<user>/data
      volumes:
        - name: azure
          azureFile:
            secretName: azure-secret
            shareName: sftp-share
            readOnly: false

एक बार जब पॉड तैयार हो जाता है और मैं कंटेनर में चला जाता हूं और डीआईआर की जांच करता हूं, तो कुछ भी नहीं हुआ है:

root<strong i="10">@container</strong>:/# cd /home/<user>                                                                        
root<strong i="11">@container</strong>:/home/<user># ls -als
total 8
4 drwxr-xr-x 3 root root 4096 Apr 24 18:45 .
4 drwxr-xr-x 1 root root 4096 Apr 24 18:45 ..
0 drwxr-xr-x 2 root root    0 Apr 22 21:32 data
root<strong i="12">@container</strong>:/home/<user># cd data
root<strong i="13">@container</strong>:/home/<user>/data# ls -als
total 1
1 -rwxr-xr-x 1 root root 898 Apr 24 08:55 fix.sh
0 -rwxr-xr-x 1 root root   0 Apr 22 22:27 test.json
root<strong i="14">@container</strong>:/home/<user>/data# 

कुछ बिंदु पर मेरे पास कंटेनर पर ही runAsUser: 0 भी था। लेकिन वह भी काम नहीं आया। कोई भी सहायताकाफी प्रशंसनीय होगी

बाद में एक चाउन चलाने से भी काम नहीं चला

@eatnumber1 यदि कोई समूह आपके पूरक समूहों में है, तो क्या आपको यह नहीं मान लेना चाहिए कि इसका उद्देश्य उस समूह के संसाधनों तक आपकी पहुंच है? पूरक समूहों को छोड़ना कह रहा है "मुझे पता है कि आपने मुझसे कहा था कि मुझे इसकी आवश्यकता है, लेकिन मुझे यह नहीं चाहिए" और फिर बाद में शिकायत करना कि आपके पास यह नहीं है।

भले ही, मैं अब पूरी तरह से खो गया हूं कि इस बग का क्या अर्थ है - बहुत सारे फॉलोअप हैं जो बिल्कुल समान नहीं लगते हैं।

क्या कोई मेरे लिए संक्षेप में बता सकता है? या बेहतर, गैर-नाटक छवि नामों के साथ एक पूर्ण रेप्रो पोस्ट करें?

@thockin IIUC , Nginx केवल पूरक समूहों को नहीं छोड़ रहा है, यह वास्तव में initgroups कॉल करके nginx.conf में कॉन्फ़िगर किए गए कार्यों के साथ इसे रीसेट कर रहा है।

इसने मेरे लिए काम किया .. स्क्रिप्ट का हिस्सा।

```
कल्पना:
कंटेनर:
- नाम: जेनकिंस
छवि: जेनकींस/जेनकींस
बंदरगाह:
- कंटेनरपोर्ट: 50000
- कंटेनरपोर्ट: 8080
वॉल्यूम माउंट:
- माउंटपाथ: /var/jenkins_home
नाम: जेनकिंस-होम
सुरक्षा प्रसंग:
एफएसग्रुप: 1000
रनअसयूजर: 0

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

यह बहुत अच्छा होगा यदि निरंतर मात्रा securityContext को ध्यान में रखकर बनाई जा सकती है, अर्थात
apiVersion: v1 kind: PersistentVolume metadata: name: redis-data-pv namespace: data labels: app: redis spec: securityContext: runAsUser: 65534 fsGroup: 65534 capacity: storage: 1Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain claimRef: namespace: data name: redis-data hostPath: path: "/data"

वर्कअराउंड के रूप में, मैं वॉल्यूम डेटा को सही अनुमतियों में बदलने के लिए postStart जीवनचक्र हुक का उपयोग करता हूं। यह सभी अनुप्रयोगों के लिए काम नहीं कर सकता है, क्योंकि postStart जीवनचक्र हुक बहुत देर से चल सकता है, लेकिन यह कंटेनर को रूट के रूप में चलाने और फिर एंट्रीपॉइंट स्क्रिप्ट में अनुमतियों को ठीक करने और रूट छोड़ने (या गोसु का उपयोग करने) से अधिक सुरक्षित है।

@robbyt ने टिप्पणी की
वर्कअराउंड के रूप में, मैं वॉल्यूम डेटा को सही अनुमतियों में बदलने के लिए पोस्टस्टार्ट जीवनचक्र हुक का उपयोग करता हूं। यह सभी अनुप्रयोगों के लिए काम नहीं कर सकता है, क्योंकि पोस्टस्टार्ट जीवनचक्र हुक बहुत देर से चल सकता है, लेकिन यह कंटेनर को रूट के रूप में चलाने और फिर एंट्रीपॉइंट स्क्रिप्ट में अनुमतियों को ठीक करने और रूट छोड़ने (या गोसु का उपयोग करने) से अधिक सुरक्षित है।

हम initContainer , क्या जीवन चक्र हुक में कंटेनर की तुलना में एक अलग सुरक्षा कॉन्टेक्स्ट हो सकता है?

यह देखकर दुख होता है कि मुझे फिर से शोध करने के बाद @chicocvenancio का विकल्प (जिसे मैं भी उपयोग करता हूं) अभी भी स्पष्ट रूप से इसे प्राप्त करने का एकमात्र तरीका है।

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

यहाँ PostgreSQL दुनिया से एक उदाहरण दिया गया है: एक गुप्त वॉल्यूम के साथ अपने आवेदन के लिए एक TLS क्लाइंट प्रमाणपत्र माउंट करें। जैसा कि हर जगह अनुशंसित है, आप अपने कंटेनर को रूट के रूप में नहीं चलाते हैं। हालांकि, पोस्टग्रेज कनेक्शन लाइब्रेरी तुरंत शिकायत करेगी कि कुंजी विश्व पठनीय है। "कोई समस्या नहीं" आपको लगता है और आप _demanded_ 0600 से मेल खाने के लिए मोड/डिफ़ॉल्ट मोड बदलते हैं (जो क्लाइंट लाइब्रेरी के रूप में मांग करने के लिए बहुत ही उचित है)। हालाँकि, अब यह भी काम नहीं करेगा, क्योंकि अब रूट ही एकमात्र उपयोगकर्ता है जो इस फ़ाइल को पढ़ सकता है।

मैं इस उदाहरण के साथ जो बिंदु बनाने की कोशिश कर रहा हूं वह है: समूह यहां बचाव के लिए नहीं आते हैं।

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

तो कृपया, इस मुद्दे पर कोई बीच का रास्ता निकालें, न कि इसे बंद करें। :प्रार्थना:

मैं डिफ़ॉल्ट मोड 0400 के साथ उपयोगकर्ता की .ssh निर्देशिका में एसएसएच-कुंजी माउंट करने का प्रयास कर रहा हूं ताकि एप्लिकेशन पासवर्ड के बिना एसएसएच कर सके। लेकिन यह काम नहीं करता है अगर रहस्य को रूट के स्वामित्व के रूप में रखा गया है। क्या आप फिर से समझा सकते हैं कि इसे fsGroup या किसी अन्य तंत्र का उपयोग करके कैसे हल किया जा सकता है?
यदि PodSecurityPolicy सक्षम है तो मुझे कोई समाधान नहीं दिख रहा है, इसलिए एप्लिकेशन रूट के रूप में नहीं चल सकते हैं। कृपया सलाह दें।

मैं अभी भी इस बग के बारे में निराशाजनक रूप से भ्रमित हूं। ऐसा लगता है कि लगभग 6 चीजें बताई जा रही हैं कि सभी एक ही तरह से विफल होते हैं लेकिन अलग-अलग कारणों से भिन्न होते हैं।

• nginx पूरक समूहों को गिराता है
• ssh/postgres कुंजी के लिए एक विशेष मोड की मांग करता है (और समूह-पढ़ने को स्वीकार नहीं करता है)
• रूट के रूप में चलने के बारे में कुछ?

क्या कोई इस मुद्दे (या मुद्दों) को ऊपर-से-नीचे इस तरह से समझा सकता है कि मैं पूरे धागे को फिर से पढ़े बिना अनुसरण कर सकूं?

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

@साद-अली आपके रडार के लिए

@thockin मेरा उपयोग-मामला बहुत आसान है। मैं एक कंटेनर में एक गुप्त (ssh कुंजी) इंजेक्ट कर रहा हूं जो रूट के रूप में नहीं चल रहा है। /home/username/.ssh में ssh कुंजी में 400 अनुमति होनी चाहिए जो मैं कर सकता हूं, लेकिन यूआईडी के स्वामित्व में भी होनी चाहिए, या यह काम नहीं करेगी। मैं इस पॉड को किसी भी प्रकार का मूल विशेषाधिकार नहीं देना चाहता, इसलिए एक init कंटेनर जो फ़ाइल के UID को संशोधित करता है वह मेरे लिए काम नहीं करता है। छवि में ssh-कुंजी को शामिल करने के अलावा, मैं इसे कैसे करूँ?

सही। यह स्पष्ट लगता है। अगर हमने इसे ठीक कर दिया है, तो क्या यह हर उपयोग के मामले में लागू होता है?
यहाँ? या और भी है?

मैं विभिन्न स्थानों में user फ़ील्ड जोड़ना देख सकता था।

उदाहरण के लिए इसके साथ शुरू करें। इसे लागू करें और कुछ परीक्षण जोड़ें। मुझे एक स्वयंसेवक चाहिए
फुटबॉल ले जाने के लिए। यह एक टन का प्रयास नहीं है, ईमानदारी से, शायद कम
एक दिन से अधिक, लेकिन मेरे पास जल्द ही इसे खर्च करने का समय नहीं होगा।

कोई भी?

diff --git a/staging/src/k8s.io/api/core/v1/types.go b/staging/src/
k8s.io/api/core/v1/types.go
index 99159ee75a..e98c035528 100644
--- a/staging/src/k8s.io/api/core/v1/types.go
+++ b/staging/src/k8s.io/api/core/v1/types.go
@@ -1048,6 +1048,9 @@ type SecretVolumeSource struct {
        // mode, like fsGroup, and the result can be other mode bits set.
        // +optional
        DefaultMode *int32 `json:"defaultMode,omitempty"
protobuf:"bytes,3,opt,name=defaultMode"`
+       // Optional: user ID to use on created files by default.  Default
is implementation-defined.
+       // +optional
+       DefaultUser *int64 `json:"defaultUser,omitempty"
protobuf:"varint,4,opt,name=defaultUser"`
        // Specify whether the Secret or it's keys must be defined
        // +optional
        Optional *bool `json:"optional,omitempty"
protobuf:"varint,4,opt,name=optional"`
@@ -1474,6 +1477,9 @@ type ConfigMapVolumeSource struct {
        // mode, like fsGroup, and the result can be other mode bits set.
        // +optional
        DefaultMode *int32 `json:"defaultMode,omitempty"
protobuf:"varint,3,opt,name=defaultMode"`
+       // Optional: user ID to use on created files by default.  Default
is implementation-defined.
+       // +optional
+       DefaultUser *int64 `json:"defaultUser,omitempty"
protobuf:"varint,4,opt,name=defaultUser"`
        // Specify whether the ConfigMap or it's keys must be defined
        // +optional
        Optional *bool `json:"optional,omitempty"
protobuf:"varint,4,opt,name=optional"`
@@ -1541,6 +1547,9 @@ type ProjectedVolumeSource struct {
        // mode, like fsGroup, and the result can be other mode bits set.
        // +optional
        DefaultMode *int32 `json:"defaultMode,omitempty"
protobuf:"varint,2,opt,name=defaultMode"`
+       // Optional: user ID to use on created files by default.  Default
is implementation-defined.
+       // +optional
+       DefaultUser *int64 `json:"defaultUser,omitempty"
protobuf:"varint,4,opt,name=defaultUser"`
 }

 // Projection that may be projected along with other supported volume types
@@ -1581,6 +1590,9 @@ type KeyToPath struct {
        // mode, like fsGroup, and the result can be other mode bits set.
        // +optional
        Mode *int32 `json:"mode,omitempty"
protobuf:"varint,3,opt,name=mode"`
+       // Optional: user ID to use on this file.
+       // +optional
+       User *int64 `json:"User,omitempty"
protobuf:"varint,4,opt,name=User"`
 }

 // Local represents directly-attached storage with node affinity (Beta
feature)
@@ -5080,6 +5092,9 @@ type DownwardAPIVolumeSource struct {
        // mode, like fsGroup, and the result can be other mode bits set.
        // +optional
        DefaultMode *int32 `json:"defaultMode,omitempty"
protobuf:"varint,2,opt,name=defaultMode"`
+       // Optional: user ID to use on created files by default.  Default
is implementation-defined.
+       // +optional
+       DefaultUser *int64 `json:"defaultUser,omitempty"
protobuf:"varint,4,opt,name=defaultUser"`
 }

 const (
@@ -5103,6 +5118,9 @@ type DownwardAPIVolumeFile struct {
        // mode, like fsGroup, and the result can be other mode bits set.
        // +optional
        Mode *int32 `json:"mode,omitempty"
protobuf:"varint,4,opt,name=mode"`
+       // Optional: user ID to use on this file.
+       // +optional
+       User *int64 `json:"User,omitempty"
protobuf:"varint,5,opt,name=User"`
 }

 // Represents downward API info for projecting into a projected volume.

शुक्र, 6 जुलाई, 2018 को सुबह 8:00 बजे रेजा नोटिफिकेशन @github.com ने लिखा:

@thockin https://github.com/thockin मेरा उपयोग-मामला बहुत आसान है। मैं हूँ
एक गुप्त (ssh कुंजी) को एक कंटेनर में इंजेक्ट करना जो रूट के रूप में नहीं चल रहा है।
/home//.ssh में ssh कुंजी के पास 400 अनुमति होनी चाहिए जो मैं कर सकता हूं, लेकिन
यूआईडी के स्वामित्व में भी होना चाहिए, या यह काम नहीं करेगा। मैं यह नहीं देना चाहता
किसी भी प्रकार के किसी भी रूट विशेषाधिकार को पॉड करें, इसलिए एक init कंटेनर जो इसे संशोधित करता है
फ़ाइल का यूआईडी मेरे लिए काम नहीं करता है। मैं इसे शामिल करने के अलावा, इसे कैसे करूँ?
छवि में ssh-कुंजी?

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

@ vikaschoudhary16 @ derekwaynecarr इसमें यूजर-नेमस्पेस मैपिंग के लिए कुछ ओवरलैप/निहितार्थ हैं।

@rezro एक इनिट कंटेनर में ssh कुंजी की एक प्रति बनाने के लिए एक वर्कअराउंड हो सकता है, जिससे आप यह नियंत्रित कर पाएंगे कि फ़ाइल का मालिक कौन है? बशर्ते init कंटेनर उसी उपयोगकर्ता के रूप में चलता है जिसे बाद में ssh कुंजी को पढ़ने की आवश्यकता होती है। यह थोड़ा स्थूल है, लेकिन मुझे लगता है कि "काम" करना चाहिए।

@thockin एक और उपयोग-मामला: मैं एक

@pearj ठीक यही समाधान है जिसका हर कोई उपयोग करता है ... और जैसा कि नाम कहता है: यह एक समाधान है, और इसे संबोधित किया जाना चाहिए :) ... हालांकि, इस समाधान के साथ एक समस्या भी है: अद्यतन रहस्य अंततः माउंटेड में अपडेट हो जाएंगे वॉल्यूम जो चल रहे पॉड में फ़ाइल परिवर्तन पर कार्य करना संभव बनाता है; जब आप इसे एक init कंटेनर से कॉपी करेंगे तो आप इस अपडेट से चूक जाएंगे।

@pearj @mheese यह काम मेरे लिए वैसे भी काम नहीं करेगा - क्योंकि हमारी PodSecurityPolicy कंटेनरों को रूट के रूप में चलाने की अनुमति नहीं देती है - सामान्य या init कंटेनर - कोई फर्क नहीं पड़ता - कोई भी रूट के स्वामित्व वाले रहस्य तक नहीं पहुंच सकता है। मैं बता सकता है।

इसके लिए एक और उपयोग का मामला: मैं अल्पकालिक भंडारण के लिए एक्सएफएस कोटा (जाहिर है, अगर एक्सएफएस उपयोग में है) का उपयोग करने पर काम कर रहा हूं। अल्पकालिक भंडारण के लिए वर्तमान प्रवर्तन तंत्र को समय-समय पर चलाना है; धीमी और मोटे ग्रैन्युलैरिटी के अलावा, इसे पूरी तरह से नकली बनाया जा सकता है (एक फाइल बनाएं, उस पर फाइल डिस्क्रिप्टर खुला रखें, और इसे हटा दें)। मैं दो उद्देश्यों के लिए कोटा का उपयोग करने का इरादा रखता हूं:

1. पॉड के सभी कंटेनरों में हार्ड कैप का उपयोग।

2. डु चलाने के बिना प्रति-वॉल्यूम भंडारण खपत को पुनः प्राप्त करें (जो नीचे गिर सकता है)।

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

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

@robbyt कृपया बताएं कि आपने postStart कैसे चुना? मेरा कंटेनर नॉनरूट उपयोगकर्ता के रूप में चलता है, इसलिए पोस्टस्टार्ट अभी भी नॉनरूट अनुमतियों का उपयोग करता है और अनुमतियों को नहीं बदल सकता है:

chown: /home/user/: ऑपरेशन की अनुमति नहीं है
, संदेश: "chown: /home/user/: अनुमति अस्वीकृत\nchown: /home/user/: ऑपरेशन की अनुमति नहीं है

यहां एक ही समस्या है: हमारे पास वेब एप्लिकेशंस चलाने वाले सोमो डॉकराइज्ड टॉमकैट हैं और हम उन्हें मॉनिटर करने के लिए जेएमएक्स हैं, हम जेएमएक्स रिमोट उपयोगकर्ता और जेएमएक्स रिमोट पासवर्ड को रहस्यों के रूप में सेवा देना चाहते हैं, लेकिन टॉमकैट, जो स्पष्ट रूप से रूट के रूप में नहीं चलता है, वह जेएमएक्स फाइलें चाहते हैं केवल टॉमकैट चलाने वाले उपयोगकर्ता के लिए पठनीय हैं।

परिशिष्ट: wh में कई टॉमकैट हैं, और उनमें से प्रत्येक को अलग-अलग उपयोगकर्ताओं के रूप में चलाना चाहते हैं।

एक ही समस्या!

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

यदि आप एक गैर-रूट उपयोगकर्ता के रूप में चलाने के लिए पॉड्स को लागू करने के लिए लागू PodSecurityPolicies के साथ एक सुरक्षित कुबेरनेट क्लस्टर चलाना चाहते हैं तो वह हैक काम नहीं करता है।

सत्य। सभी हैक्स के अपने डाउनसाइड्स हैं। यह या तो वह है या वॉल्यूम बनने के बाद रूट के रूप में लॉग इन कर रहा है और निर्देशिका को मैन्युअल रूप से चुन रहा है। सुनिश्चित नहीं है कि वास्तव में कौन सा बदतर है :- डी। विश्वास नहीं हो रहा है कि यह एक बात भी है।

@thockin जो मैं इस मुद्दे के बाद अब लगभग 4 वर्षों से इकट्ठा कर रहा हूं, वह समाधान जो हर कोई चाहता है वह एक मात्रा के लिए एक यूआईडी और जीआईडी ​​​​सेट करने में सक्षम होना है - विशेष रूप से गुप्त संस्करणों में (लेकिन केवल वे ही नहीं)। 6 जुलाई को आपने इसके संभावित समाधान के लिए एक प्रारंभिक बिंदु पोस्ट किया। यदि यह अनुरक्षकों से समर्थित पथ है, तो मैं अंत में शुरू करूँगा और इस समस्या को हल करने का प्रयास करूँगा।

@mheese मैं कहूंगा कि इसके लिए जाओ।

@mheese अगर आप चाहें तो मैं एक पीआर पर

@mheese ऐसा लगता है कि gid SecurityContext से लिया गया है, इसलिए मुझे लगता है कि, तेजी से राहत के लिए, uid कार्यान्वयन पर्याप्त होगा। इसके अलावा क्योंकि चर्चा में gid दूसरे अनुमान थे।

यहाँ psql के साथ एक ही मुद्दा

@ michalpiasecki1 देखो मैंने इसे PostStart -हुक के साथ कैसे हल किया: https://github.com/xoe-labs/odoo-operator/blob/1be88b67d4ded5c4a0aea6e26b711241f0d09f89/pkg/controller/odoocluster/odoocluster_controller.go#L86579 -L5865

एक ही मुद्दे में चल रहा है। क्या इसके लिए कोई अनुशंसित समाधान है?

@blaggacao : संकेत के लिए धन्यवाद, हालांकि मुझे एक और कामकाज मिला
@debianmaster : मैं https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ में वर्णित सुरक्षा कॉन्टेक्स्ट और fsGroup की अनुशंसा करता हूं

मैंने रूट के स्वामित्व वाले प्रमाणपत्रों के साथ समाप्त किया, और समूह अनुमतियों के साथ पोस्टग्रेज 440

@ michalpiasecki1 क्या आप इस बारे में अधिक जानकारी दे सकते हैं कि आपने इसे पोस्टग्रेज के लिए कैसे हल किया?

मेरे पास server.crt और server.key फ़ाइलें k8s गुप्त pg-certs-secret में संग्रहीत हैं और मैं उन्हें postgres:9.6 चलाने वाले अपने कंटेनर में माउंट करना चाहता हूं। मैंने इसे इसके साथ स्थापित किया है:

      containers:
      - name: pg
         image: postgres:9.6
         ...
         volumeMounts:
         - name: pg-certs
            mountPath: "/etc/certs/"
            readOnly: true
            args: ["-c", "ssl=on", "-c", "ssl_cert_file=/etc/certs/server.crt", "-c", "ssl_key_file=/etc/certs/server.key"]
      volumes:
        - name: pg-certs
           secret:
           secretName: pg-certs-secret
           defaultMode: 384

लेकिन इसे तैनात करते हुए, कंटेनर FATAL: could not load server certificate file "/etc/certs/pg_server.crt": Permission denied . त्रुटि के साथ मर जाता है

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

यह भी ध्यान देने योग्य है: मैंने यह सुनिश्चित करने के लिए defaultMode: 384 जोड़ा कि फ़ाइलें 0600 फ़ाइल अनुमतियों के साथ जोड़ी गई हैं। इससे पहले कि मैं इसे जोड़ता, कंटेनर त्रुटि के साथ मर गया

FATAL:  private key file "/etc/certs/pg_server.key" has group or world access
DETAIL:  File must have permissions u=rw (0600) or less if owned by the database user, or permissions u=rw,g=r (0640) or less if owned by root.

संदर्भ के लिए, मैंने अभी इसे समझ लिया है और जब मैंने जोड़ा तो यह काम कर गया

     securityContext:
        fsGroup: 999

विशिष्टता के लिए।

मुझे भी यही समस्या है #72085
क्या कोई मेरी मदद कर सकता है

@izgeri मैंने लिंक की कोशिश की
लेकिन काम नहीं कर रहा, क्या आप मेरी मदद कर सकते हैं

क्या इस मुद्दे को ठीक करने का कोई मौका है? क्या कुबेरनेट्स लोग समाधान पर काम कर रहे हैं?

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

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

ध्यान दें कि डॉकर कंटेनर कैसे बनाया और चलाया जाता है, इसके आधार पर उचित समूह आईडी अलग-अलग होगी। मैं आमतौर पर इसे kubectl exec द्वारा एक शेल में पॉड में डालने और id -g टाइप करके पता लगाता हूं

@ चार्ल्स-क्रेन: आपका सुझाव ज्यादातर मामलों के लिए वास्तव में अच्छा काम करता है।

यहां एक और मामला है जो कवर नहीं किया गया है:

यदि कंटेनर रूट के रूप में शुरू होता है लेकिन एक अन्य उपयोगकर्ता बनने के लिए gosu जैसे टूल का उपयोग करता है (कुछ प्रक्रियाओं के लिए)।

फिर कंटेनर को fsGroup के साथ केवल एक समूह में लॉक करने से ऐसे मामलों को रोका जा सकेगा जैसे "मैं चाहता हूं कि मेरे गैर-रूट उपयोगकर्ता को एसएसएच कुंजी तक पहुंच हो, जो इसकी ~/.ssh निर्देशिका में घुड़सवार हो, जबकि मेरे रूट उपयोगकर्ता के पास अन्य माउंट तक पहुंच हो बहुत"।

इसका एक उदाहरण: "एक डीआईएनडी कंटेनर जहां dockerd रूट के रूप में शुरू होना चाहिए, लेकिन बाद के कंटेनर गैर-रूट उपयोगकर्ता द्वारा चलाए जाते हैं"।

हाय वहाँ @ चार्ल्स-क्रेन, मुझे बहुत ही रोचक समस्या का सामना करना पड़ रहा है जो इस धागे के विषय से मेल खाता है। लगता है fsGroup सभी मामलों के लिए काम नहीं करता है,
यहाँ परिनियोजन का उदाहरण है, यह परीक्षण nginx परिनियोजन है, मैं nfs माउंट करने की कोशिश कर रहा हूँ और इसके अतिरिक्त खाली निर्देशिका माउंट कर रहा हूँ - बस तुलना करने के लिए।
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-test labels: app: nginx-test spec: selector: matchLabels: app: nginx-test strategy: type: Recreate template: metadata: labels: app: nginx-test spec: securityContext: fsGroup: 2000 volumes: - name: nfs-volume nfs: server: # nfs with no_root_squash path: /nfs - name: test-fs-group emptyDir: {} containers: - image: nginx name: nginx-test imagePullPolicy: Always volumeMounts: - name: nfs-volume mountPath: /var/local/test5 - name: test-fs-group mountPath: /var/local/test6
जब मैं पॉड के nginx कंटेनर में बैश निष्पादित करता हूं GID केवल खाली dir के लिए लागू होता है, न कि nfs के लिए माउंट किए गए dir के लिए। परीक्षण उद्देश्यों में रूट स्क्वैश के साथ कॉन्फ़िगर किए गए एनएफएस, मेरे कंटेनर में प्रक्रिया में गैर-रूट उपयोगकर्ता है, इसलिए यह समस्या है, इसे चाउन के माध्यम से हल किया जा सकता है, हालांकि मैं इसे मूल समाधान के साथ प्राप्त करने की कोशिश कर रहा हूं

मैं भी ऊपर वर्णित ठीक उसी मुद्दे का सामना करता हूं।

यह मुद्दा 5 साल की तरह खुला है। कुबेरनेट्स में से कोई भी इसमें रूचि नहीं रखता है और यह किसी कारण से मान्य हो सकता है या नहीं। साधारण समस्या के कई वैध समाधान थे लेकिन उनमें से कोई भी लागू नहीं किया गया था।

निश्चित नहीं है कि यह मुद्दा अभी बंद क्यों नहीं हुआ

बात करने में मदद करें।

सोम को, फरवरी १८, २०१९, दोपहर १२:४४ बजे एर्किन खयदारोव < सूचनाएं @github.com
लिखा था:

यह मुद्दा 5 साल की तरह खुला है। कुबेरनेट्स से कोई नहीं है
इसमें रुचि रखते हैं और यह किसी कारण से वैध हो सकता है या नहीं। वहाँ कई थे
साधारण समस्या के वैध समाधानों की संख्या लेकिन उनमें से कोई भी नहीं था
क्रियान्वित किया।

निश्चित नहीं है कि यह मुद्दा अभी बंद क्यों नहीं हुआ

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

@mheese जैसा कि आपने यहां टिप्पणी की https://github.com/kubernetes/kubernetes/issues/2630#issuecomment -424876108 वॉल्यूम के लिए एक यूआईडी और जीआईडी ​​​​सेट करने के लिए, क्या आप अभी भी इस पर काम करने की कोशिश कर रहे हैं? धन्यवाद!

मुझे भी इस मुद्दे का सामना करना पड़ा। क्‍या इसके लिए व्‍यवहार्य समाधान तैयार करने की कोई योजना है? स्थानीय स्थायी वॉल्यूम होस्टपाथ वॉल्यूम के सभी उपयोग-मामलों को प्रतिस्थापित नहीं कर सकते हैं

मेरा भी यही विचार है।

@ jingxu97 मैंने इसे अभी तक

मुझे एक विस्तृत प्रस्ताव के साथ आने दें और तैयार होने पर इसे यहां पोस्ट करें।

ठीक

संदर्भ के लिए, मैंने अभी इसे समझ लिया है और जब मैंने जोड़ा तो यह काम कर गया

     securityContext:
        fsGroup: 999

विशिष्टता के लिए।

postgres:11.1-alpine लिए इसका उपयोग करें:

securityContext:
  fsGroup: 70

मैं बस उम्मीद कर सकता हूं कि कुबेरनेट्स के सदस्य इस मुद्दे को प्राथमिकता दें। आईएमओ, यह वास्तव में सुरक्षा के दृष्टिकोण से एक अवरोधक है और कमजोरियों का जोखिम बन रहा है :'(

दीर्घकालिक मुद्दा (स्वयं को नोट)

मैं इसे प्रमाणपत्र-प्रबंधक प्रबंधित रहस्यों के संदर्भ में मार रहा हूं। मैं कर्ट को सही जगह पर कॉपी करने और अनुमतियों को अपडेट करने के लिए एक initContainer का उपयोग कर रहा था। Cert-manager को अपने रहस्यों को अपडेट करने की आवश्यकता है ताकि ट्रिक काम न करे। मैं fsGroup वर्कअराउंड का पता लगाऊंगा।

@incubus8
मैं इस मुद्दे पर काम करने की कोशिश कर रहा हूं। क्या आप कृपया अपने उपयोग के मामले का वर्णन कर सकते हैं और आप किस प्रकार के व्यवहार की अपेक्षा करेंगे? धन्यवाद!

@ jingxu97 मैं दो उदाहरण पेश कर सकता हूं। प्रोमेथियस डॉकर छवि उपयोगकर्ता nobody (यूआईडी 65534) के रूप में प्रोमेथियस सेवा शुरू करती है और ग्राफाना डॉकर छवि यूआईडी = 472 (https://grafana.com/docs/installation/docker/) के रूप में ग्राफाना शुरू करती है।

इन अनुमतियों के कारण पहली बार शुरू होने पर ये दोनों निर्देशिका बनाने में विफल रहते हैं। मैंने अपने सेटअप में इसके चारों ओर एक initContainer साथ काम किया है जो आवश्यक निर्देशिका बनाता है और chown उन्हें उचित रूप से बनाता है।

@ फोर्ड-प्रीफेक्ट यदि आप PodSecurityContext में fsGroup सेट करते हैं, और रनअसयूसर, क्या उन सेवाओं को लिखने की अनुमति नहीं होगी?

नहीं, क्योंकि अनुमतियाँ पॉड के लिए सेट की गई हैं, न कि उस वॉल्यूम के लिए जो स्वतंत्र रूप से बनाई गई थी। यह बहुत अच्छा होगा यदि PodSecurityContext वॉल्यूम की अनुमतियों को बदल सकता है, या कम से कम माउंट करने और त्रुटि फेंकने में विफल हो सकता है

@ekhaydarov , वर्तमान setVolumeOwnerhsip फ़ंक्शन में, यदि fsGroup प्रदान किया जाता है, तो उसके पास rw-rw ---- अनुमति होगी, ताकि समूह के पास rw अनुमति हो। और जब कंटेनर शुरू किया जाता है, तो यह पूरक समूह स्थापित करेगा ताकि वह वॉल्यूम को पढ़ और लिख सके। मुझे कुछ याद आ रहा है?

@ jingxu97 थी हमेशा एक समाधान नहीं है, उदाहरण के लिए: हम jmxremote.password और jmxremote.user के लिए सीक्रेट का उपयोग करते हैं जो जावा अनुप्रयोगों के jmxmonitoring के लिए आवश्यक हैं, जावा के लिए आवश्यक है कि वे फ़ाइलें उस उपयोगकर्ता से संबंधित हों जो ते एप्लिकेशन चलाते हैं जिनकी अनुमति 400 है , इसलिए अब तक Rancher 2.x . में इस तरह से रहस्यों का उपयोग करने का कोई तरीका नहीं है

मैं यह देखकर हैरान था कि fsGroup एक विकल्प था और fsUser नहीं था।
साथ ही, इसका अनुमति/मोड भाग भ्रमित करने वाला है। हमें यह स्पष्ट करना चाहिए कि कैसे EmptyDir जैसे वॉल्यूम अपना डिफ़ॉल्ट मोड प्राप्त करते हैं या उपयोगकर्ता को इसे स्पष्ट रूप से सेट करने की अनुमति देते हैं, क्योंकि यह एक बहुत ही सामान्य यूनिक्स व्यवस्थापक कार्य है।

यदि रूट एकमात्र ऐसा उपयोगकर्ता है जो कभी भी आपके वॉल्यूम का स्वामी हो सकता है (रनटाइम पर इसे chmod करने के लिए initContainer का उपयोग करने के अलावा), API किसी एप्लिकेशन के उपयोगकर्ता के लिए रूट के उपयोग को प्रोत्साहित करता है जो एक कमजोर सुरक्षा अभ्यास है।

@jingxu97 आपको क्या लगता है?

@sealthybox , प्रतिक्रिया के लिए धन्यवाद। मैं वर्तमान में वॉल्यूम स्वामित्व और अनुमति पर एपीआई के प्रस्ताव पर काम कर रहा हूं और जल्द ही समुदाय के साथ साझा करूंगा। तब प्रतिक्रिया/टिप्पणियों का स्वागत है।

नमस्ते।

इस मुद्दे के बारे में कुछ खबरें हैं?

pv.beta.kubernetes.io/gid स्थानीय होस्ट पथ प्रोविज़नर के लिए काम क्यों नहीं करता है?

अरे,

मैं भी इसका सामना कर रहा हूं, मैं कुछ खबरों की सराहना करता हूं :)।

यह अब तक मेरा कामकाज रहा है:
initContainers: - name: init image: busybox:latest command: ['/bin/chown', 'nobody:nogroup', '/<my dir>'] volumeMounts: - name: data mountPath: /<my dir>

यह अब तक मेरा कामकाज रहा है:

      - name: init
        image: busybox:latest
        command: ['/bin/chown', 'nobody:nogroup', '/<my dir>']
        volumeMounts:
        - name: data
          mountPath: /<my dir>

chown आईएनजी के साथ समाधान केवल-पढ़ने के लिए काम नहीं करते हैं, जैसे कि गुप्त माउंट, दुर्भाग्य से।

मुझे इसकी भी आवश्यकता होगी (बहुत तत्काल), क्योंकि हमारे पास सॉफ़्टवेयर शुरू नहीं होने के कारण अनुमतियाँ अलग नहीं होने के कारण 0600 । यदि हम एक विशिष्ट यूआईडी के तहत वॉल्यूम माउंट कर सकते हैं तो मेरी (और अन्य की) समस्या हल हो जाएगी।

आप वॉल्यूम अनुमतियों को अद्यतन करने के लिए अपने परिनियोजन के भाग के रूप में कार्य चला सकते हैं और वर्कअराउंड के रूप में लिखने की अनुमति की जाँच करने के लिए तैयार स्थिति का उपयोग कर सकते हैं। या आप वॉल्यूम के लिए समूह निर्दिष्ट करने के लिए fsGroup का उपयोग कर सकते हैं और एप्लिकेशन उपयोगकर्ता को उस समूह में जोड़ सकते हैं जिसके पास वॉल्यूम है। विकल्प 2 मेरे लिए क्लीनर लगता है। मैं विकल्प 1 का उपयोग करता था लेकिन अब मैं विकल्प 2 का उपयोग करता हूं।

ध्यान दें कि यदि कुबेरनेट्स ने fsUser विकल्प का समर्थन किया है, तो आप https://github.com/kubernetes/kubernetes/issues/57923 पर यात्रा करेंगे, जहां माउंटेड सीक्रेट की सभी फाइलों को 0440 दिया जाएगा। 0660 ) और किसी भी अन्य कॉन्फ़िगरेशन को अनदेखा कर देगा।

@woodcockjosh fsGroup सुरक्षा-संवेदनशील सॉफ़्टवेयर के उपयोग के मामले को कवर नहीं करता है जैसे वॉल्ट vault:vault रूप में चलाने की कोशिश कर रहा है और एक निजी कुंजी फ़ाइल लोड कर रहा है जिसके लिए 0600 बराबर या उससे कम अनुमति की आवश्यकता है @wjam fsUser आदर्श होगा यदि हमें 0400 अनुमतियाँ भी मिल सकें (निजी कुंजी फ़ाइलों जैसी चीज़ों के लिए)।

हमने प्रमाणपत्रों के साथ PostgreSQL डीबी को प्रमाणित करने के लिए वॉल्ट को कॉन्फ़िगर करने का प्रयास करने के लिए इसे मारा। अनुमति बिट्स भिन्न होने पर अंतर्निहित गो लाइब्रेरी हार्ड विफल हो जाती है (https://github.com/lib/pq/blob/90697d60dd844d5ef6ff15135d0203f65d2f53b8/ssl_permissions.go#L17)।

@jingxu97 : क्या इस पर कोई खबर है। सख्त सुरक्षा नीतियों के साथ हमारे क्लस्टर में अभी भी pv स्वामित्व की समस्या है।

यह लेख काम करने जैसा लगता है मैं इसका परीक्षण नहीं करता लेकिन मैं सोमवार को इसका परीक्षण करूंगा, अगर कोई इसे b4 कर सकता है तो कृपया हमें बताएं।
विवरण यहाँ है
डेटा दृढ़ता को लगातार वॉल्यूम का उपयोग करके कॉन्फ़िगर किया गया है। इस तथ्य के कारण कि कुबेरनेट्स इन संस्करणों को रूट उपयोगकर्ता के साथ मालिक के रूप में माउंट करता है, गैर-रूट कंटेनरों को लगातार निर्देशिका में लिखने की अनुमति नहीं है।

इन अनुमति समस्याओं को हल करने के लिए हम निम्नलिखित कुछ चीज़ें कर सकते हैं:

गैर-रूट कंटेनर में इसे माउंट करने से पहले वॉल्यूम की अनुमतियों को बदलने के लिए एक init-container का उपयोग करें। उदाहरण:
```
कल्पना:
initकंटेनर:
- नाम: वॉल्यूम-अनुमतियां
छवि: बिजीबॉक्स
कमांड: ['sh', '-c', 'chmod -R g+rwX /bitnami']
वॉल्यूम माउंट:
- माउंटपाथ: / बिटनामी
नाम: nginx-डेटा
कंटेनर:
- छवि: बिटनामी / nginx: नवीनतम
नाम: nginx
वॉल्यूम माउंट:
- माउंटपाथ: / बिटनामी
नाम: nginx-डेटा

Use Pod Security Policies to specify the user ID and the FSGroup that will own the pod volumes. (Recommended)
  ```
    spec:
        securityContext:
          runAsUser: 1001
          fsGroup: 1001
        containers:
        - image: bitnami/nginx:latest
          name: nginx
          volumeMounts:
          - mountPath: /bitnami
            name: nginx-data

नमस्ते,
मैंने इंटरनेट के चारों ओर उस कमजोर initContainer के साथ वर्कअराउंड देखा है जो रूट के रूप में चल रहा है।
मैं fsGroup के साथ भी संघर्ष कर रहा हूं, जो केवल पॉड के दायरे पर लागू होता है, न कि पॉड में प्रत्येक कंटेनर पर, जो [भी] शर्म की बात है।
अल्पाइन के आधार पर बस एक कस्टम छवि (नॉनरूट-इनिटकॉन्टेनर) बनाएं, जिसमें सुडो स्थापित और कस्टम /etc/sudoers मेरे गैर-रूट उपयोगकर्ता को chmod क्रियाओं को लागू करने की पूरी शक्ति दे। दुर्भाग्य से, मैं इसके साथ एक और दीवार मार रहा हूं:

sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' \
option set or an NFS file system without root privileges?

चूंकि मैं उस परिनियोजन के लिए एक कम सुरक्षित PodSecurityPolicy बनाने के लिए तैयार नहीं हूं, इसलिए सुरक्षा सर्वोत्तम प्रथाओं का अनुपालन करने वाले लोगों के लिए उस मुद्दे से कोई भी समाचार बहुत स्वागत योग्य होगा।

अग्रिम में धन्यवाद !

क्या कुबेरनेट्स परिनियोजन फ़ाइलों के लिए fsGroup ?

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

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

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

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

मैं

क्या यह अभी भी एक मुद्दा है? मैंने कुछ परीक्षण किए हैं (मिनिक्यूब १.१४, १.१५, १.१९ और ईकेएस १.१४) और emptyDir वॉल्यूम पर अनुमतियाँ इरादा के अनुसार ७७७ हैं:

apiVersion: v1
kind: Pod
metadata:
  name: debug
  namespace: default
spec:
  containers:
  - image: python:2.7.18-slim
    command: [ "tail", "-f" ]
    imagePullPolicy: Always
    name: debug
    volumeMounts:
    - mountPath: /var/log/test-dir
      name: sample-volume
  volumes:
  - emptyDir:
      sizeLimit: 10M
    name: sample-volume

डीआईआर में फाइलें लिखना, अपेक्षित रूप से किसी भी उपयोगकर्ता के साथ काम करता है।