Enhancements: पॉड सुरक्षा नीति

को निर्मित 9 मई 2016 · 93टिप्पणियाँ · स्रोत: kubernetes/enhancements

फ़ीचर विवरण

पॉड और कंटेनर द्वारा उपयोग की जाने वाली सुरक्षा-संबंधी सुविधाओं को सीमित करने वाली नीतिगत वस्तुओं को परिभाषित करें
प्राथमिक संपर्क (असाइनी): @tallclair
जिम्मेदार SIGs: @kubernetes/sig-auth-feature-requests @kubernetes/sig-node-feature-requests
डिजाइन प्रस्ताव लिंक (सामुदायिक रेपो): https://github.com/kubernetes/community/blob/master/contributors/design-proposals/auth/pod-security-policy.md
e2e और/या इकाई परीक्षणों के लिए लिंक: https://github.com/kubernetes/kubernetes/blob/master/test/e2e/auth/pod_security_policy.go
समीक्षक (ओं) - (एलजीटीएम के लिए): @liggitt @tallclair
अनुमोदनकर्ता: @liggitt @tallclair
फ़ीचर लक्ष्य (कौन सा लक्ष्य किस मील के पत्थर के बराबर है):
- बीटा रिलीज़ लक्ष्य (एक्सटेंशन/v1beta1) - 1.8
- बीटा रिलीज़ लक्ष्य (नीति/v1beta1) - 1.10
- स्थिर रिलीज लक्ष्य - टीबीडी

संबंधित मुद्दों

https://github.com/kubernetes/kubernetes/issues/43214 - एक्सटेंशन/v1beta1 API समूह से बाहर निकलें:
- 1.10
- [x] अतिरिक्त रूप से use क्रिया के माध्यम से policy API समूह में अधिकृत करने की अनुमति दें (कुछ समय अवधि के लिए किसी भी समूह के माध्यम से अनुमति देने की आवश्यकता होगी)
- [x] e2e परीक्षण अपडेट करें (दोनों का परीक्षण कुछ समय के लिए करें)
- 1.11
- [] आंतरिक प्रकारों को नीति पैकेज में ले जाएं (सफाई)
- [ ] रजिस्ट्री को पॉलिसी पैकेज में ले जाएं (क्लीनअप)
- [ ] नीति/v1beta1 का उपयोग करने के लिए एडऑन मैनिफ़ेस्ट को अपडेट करें, नीति API समूह में अनुमतियां प्रदान करें
- [] नीति समूह मुखबिर का उपयोग करने के लिए प्रवेश प्लगइन स्विच करें
- [] पसंदीदा भंडारण संस्करण को नीति समूह में बदलें
https://github.com/kubernetes/kubernetes/issues/56174
https://github.com/kubernetes/kubernetes/issues/55435
https://github.com/kubernetes/kubernetes/issues/56173

kinfeature siauth sinode stagbeta trackeno

स्रोत

erictune

👍2

सबसे उपयोगी टिप्पणी

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

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

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

आईएमओ, पीएसपी बीटा को मेनलाइन कुबेरनेट्स कोर में मर्ज किया जाना चाहिए। मेरे कारण हैं:

जबकि पीएसपी में खामियां हैं, वे कार्य करते हैं, और 10 रिलीज के लिए कार्य करते हैं।
एक परियोजना के रूप में कुबेरनेट्स को कार्यभार रनटाइम सुरक्षा की परवाह करनी चाहिए। कंटेनर से बच निकलना बहुत आसान है। PSP उन कुछ उपकरणों में से एक है जो हमलावरों के लिए इसे कठिन बनाते हैं।
पूर्ण हो गया का दुश्मन है। PSP को यथावत मर्ज करें, और "बेहतर" कार्यान्वयन को नीति/v2.
अंत में, और सबसे महत्वपूर्ण, यह ओएसएस डेवलपर्स को उच्च सुरक्षा क्लस्टर चलाने की अनुमति देता है, न कि केवल उन कंपनियों को जो स्टायरा जैसे विक्रेताओं को वहन कर सकती हैं।

zapman449 17 नव॰ 2020

👍13

सभी 93 टिप्पणियाँ

प्रवेश नियंत्रक कोड की समीक्षा की जा रही है: https://github.com/kubernetes/kubernetes/pull/24600

erictune 9 मई 2016

यह सुविधा सीधे बीटा में जा रही है क्योंकि ओपनशिफ्ट में इसका प्रारंभिक प्रदर्शन हुआ है।

erictune 9 मई 2016

यह Kubernetes/kubernetes#24600 में डिफ़ॉल्ट रूप से अक्षम हो जाएगा। उसके बाद, हमें पीएसपी को उपयोगकर्ताओं से जोड़ने के लिए प्रवेश नियंत्रक में बदलाव की आवश्यकता है।

erictune 9 मई 2016

पीएसपी (विषय स्तरीय पहुंच) पर अगले चरण के लिए निर्भरता के रूप में https://github.com/kubernetes/kubernetes/pull/20573 को नोट करना

pweil- 11 मई 2016

इसकी स्थिति क्या है? क्या पहली टिप्पणी में विवरण अप टू डेट है?

bryk 12 जुल॰ 2016

क्या पहली टिप्पणी में विवरण अद्यतित है

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

आईएमओ बीटा/1.4 के लिए शेष कार्य अनुमतियों के लिए प्रमाणीकरण एकीकरण है, नए क्षेत्रों के लिए अद्यतन करना हम बाधा डालना चाहते हैं (seccomp - प्रगति पर, sysctl), और कोई भी आवश्यक दस्तावेज़/ट्यूटोरियल।

pweil- 12 जुल॰ 2016

और एक e2e परीक्षण।

मंगलवार, 12 जुलाई, 2016 को सुबह 6:23 बजे, पॉल वेइल सूचनाएं @github.com ने लिखा:

क्या पहली टिप्पणी में विवरण अद्यतित है
नहीं (मेरे पास अपडेट करने की अनुमति नहीं है)। मुझे विश्वास है कि सभी अल्फा
आवश्यकताओं को पूरा किया गया है। प्रारंभिक प्रकार, एपीआई, और परीक्षण किए गए हैं
विलय होना। प्रवेश नियंत्रक डिफ़ॉल्ट रूप से सक्षम नहीं है।
आईएमओ बीटा/1.4 के लिए शेष कार्य अनुमतियों के लिए प्रमाणीकरण एकीकरण है,
नए क्षेत्रों के लिए अद्यतन करना हम बाधा डालना चाहते हैं (seccomp - प्रगति पर है,
sysctl), और कोई भी आवश्यक दस्तावेज़/ट्यूटोरियल।
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने सूत्र को लिखा है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/features/issues/5#issuecomment -232045429,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe/AHuudqFwephlYk0Y1PS77y0xxA5QW0_-ks5qU5U7gaJpZM4IaU8n
.

erictune 12 जुल॰ 2016

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

therc 16 जुल॰ 2016

👍1

@therc जो ServiceAccount के माध्यम से किया जाना चाहिए।

erictune 16 जुल॰ 2016

@goltermann मैंने देखा कि इसे अल्फा के साथ चिह्नित किया गया था, लेकिन मेरा मानना है कि इसे शायद https://github.com/kubernetes/features/issues/5#issuecomment -217939650 पर आधारित बीटा टैग की आवश्यकता है

pweil- 22 अग॰ 2016

@erictune @pweil- टिप्पणी के आधार पर बीटा ध्वनि सही करता है?

goltermann 22 अग॰ 2016

@goltermann मुझे लगता है कि तकनीकी रूप से यह 1.3 में बीटा होता, यह 1.4 के लिए नया नहीं है, हालांकि विकास जारी है।

pweil- 22 अग॰ 2016

हाँ, बीटा सही है। जब मैंने आज पहले अल्फा कहा तो मैं गलत था।

erictune 23 अग॰ 2016

बढ़िया, इसे ठीक किया

goltermann 23 अग॰ 2016

@ pweil- क्या दस्तावेज़ तैयार हैं? कृपया डॉक्स को https://github.com/kubernetes/kubernetes.github.io पर अपडेट करें, और फिर पीआर नंबर जोड़ें और समस्या विवरण में डॉक्स बॉक्स चेक करें।

janetkuo 2 सित॰ 2016

@janetkuo डॉक्स पीआर https://github.com/kubernetes/kubernetes.github.io/pull/1150

संपादित करें: https://github.com/kubernetes/kubernetes.github.io/pull/1206 सही 1.4 पीआर है

cc @kubernetes/feature-reviewers

pweil- 2 सित॰ 2016

@ pweil- मुझे लगता है, यह पीआर वास्तविक है - https://github.com/kubernetes/kubernetes.github.io/pull/1206?

idvoretskyi 22 सित॰ 2016

सही

pweil- 22 सित॰ 2016

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

/lifecycle frozen टिप्पणी के साथ समस्याओं को स्वतः बंद होने से रोकें।

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

सिग-टेस्टिंग, कुबेरनेट्स/टेस्ट-इन्फ्रा और/या @fejta को फीडबैक भेजें।
/जीवनचक्र बासी

fejta-bot 3 जन॰ 2018

PSP को उसके गैर-एक्सटेंशन API समूह में स्थानांतरित करने के लिए 1.10 में काम हो रहा है
सीसी @ पीएचपी-कोडर

liggitt 22 जन॰ 2018

@erictune डॉक्टर अपडेट, कृपया? [1.10 फ़ीचर ट्रैकिंग स्प्रेडशीट[(https://docs.google.com/spreadsheets/d/17bZrKTk8dOx5nomLrD1-93uBfajK5JS-v1o-nCLJmzE/edit#gid=0) भी देखें। एलएमके यदि आपके कोई प्रश्न हैं। हमें एक डॉक्स पीआर की समीक्षा करने और 3/9 तक विलय करने की आवश्यकता है। धन्यवाद!

Bradamant3 2 मार्च 2018

@ पीएचपी-कोडर ^

liggitt 2 मार्च 2018

@ Bradamant3 @liggitt कौन से दस्तावेज़ अपडेट की आवश्यकता है?

एपीआई समूह संक्रमण से संबंधित परिवर्तनों के लिए, मैंने सबमिट किया है: https://github.com/kubernetes/website/pull/7562 , https://github.com/kubernetes/examples/pull/206 , और https:/ /github.com/kubernetes/examples/pull/208

php-coder 2 मार्च 2018

मैं PSP Doc अपडेट के लिए सही स्वामी नहीं हूं।

शुक्र, 2 मार्च, 2018 पूर्वाह्न 11:26 बजे, व्याचेस्लाव सेमुशिन <
सूचनाएं@github.com> ने लिखा:

@ Bradamant3 https://github.com/bradamant3 @liggitt
https://github.com/liggitt कौन से दस्तावेज़ अपडेट की आवश्यकता है?
एपीआई समूह संक्रमण से संबंधित परिवर्तनों के लिए, मैंने सबमिट किया है:
कुबेरनेट्स/वेबसाइट#7562 https://github.com/kubernetes/website/pull/7562 ,
Kubernetes/examples#206 https://github.com/kubernetes/examples/pull/206 ,
और कुबेरनेट्स/उदाहरण#208
https://github.com/kubernetes/examples/pull/208
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/features/issues/5#issuecomment-370026485 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AHuudtBCup17Kt91pqJzBRpKWStoXUt-ks5taZzcgaJpZM4IaU8n
.

erictune 2 मार्च 2018

हमें बस इतना ही चाहिए। मैंने पीआर को ट्रैकिंग स्प्रेडशीट में जोड़ा है। धन्यवाद!

Bradamant3 2 मार्च 2018

@php- coder @liggitt @tallclair
1.11 में इसके लिए कोई योजना?

यदि हां, तो क्या आप कृपया सुनिश्चित कर सकते हैं कि यह सुविधा उपयुक्त के साथ अप-टू-डेट है:

विवरण
माइलस्टोन
समनुदेशिती
लेबल:
- stage/{alpha,beta,stable}
- sig/*
- kind/feature

cc @idvoretskyi

justaugustus 17 अप्रैल 2018

@ php- coder क्या आप

tallclair 17 अप्रैल 2018

क्या नीति समूह की चाल के अलावा कोई अन्य परिवर्तन हैं?

नहीं, मैंने सिर्फ इसी पर काम किया है।

मुझे उम्मीद है कि @liggitt समय होने पर विवरण को अपडेट कर देगा (क्योंकि मेरे पास उचित अनुमति नहीं है)।

php-coder 17 अप्रैल 2018

किया हुआ।

tallclair 17 अप्रैल 2018

@tallclair सिर्फ स्पष्ट करने के लिए, हम 1.11 के लक्ष्य के रूप में स्थिर ट्रैकिंग कर रहे हैं, सही?
मैंने लेबल को अपडेट कर दिया है, हालांकि मैं यह सुनिश्चित करना चाहता हूं।

justaugustus 17 अप्रैल 2018

नहीं, यह अभी भी बीटा होगा। मुझे यकीन नहीं है कि PodSecurityPolicy कभी भी स्थिर हो जाएगा (यानी किसी और चीज से आगे निकल जाएगा), लेकिन अन्य लोग इस पर मुझसे असहमत हो सकते हैं।

tallclair 17 अप्रैल 2018

समझ लिया। अपडेट के लिए धन्यवाद, @tallclair!

justaugustus 17 अप्रैल 2018

@justaugustus मैं इसे 1.11 मील के पत्थर से हटा दूंगा, क्योंकि वर्तमान रिलीज में कोई महत्वपूर्ण प्रगति नहीं होने वाली है।

idvoretskyi 24 मई 2018

1.12 . के लिए कोई अपडेट की योजना नहीं है

tallclair 31 जुल॰ 2018

👍1

@tallclair मैं 1.12 . में RunAsGroup PSP नॉब्स प्राप्त करने में सक्षम हो सकता हूं

krmayankk 1 अग॰ 2018

एके। हालांकि यह अभी भी बीटा में होगा। फिलहाल पीएसपी के जीए में जाने की कोई योजना नहीं है। कुछ प्रमुख उपयोगिता मुद्दे हैं जिन्हें आगे बढ़ने से पहले संबोधित करने की आवश्यकता है। (देखें https://github.com/kubernetes/kubernetes/issues/60001 और https://github.com/kubernetes/kubernetes/issues/56174)

tallclair 1 अग॰ 2018

/ अनअसाइन

php-coder 15 अग॰ 2018

/असाइन @tallclair

justaugustus 15 अग॰ 2018

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

दस्तावेज़ (ओपन प्लेसहोल्डर पीआर): 11/8
कोड स्लश: 11/9
कोड फ्रीज शुरू होता है: 11/15
डॉक्स पूर्ण और समीक्षित: 11/27

कृपया भविष्य की ट्रैकिंग के लिए अपनी मूल पोस्ट पर मील के पत्थर को अपडेट करने के लिए कुछ समय दें और अगर इसे 1.13 एन्हांसमेंट ट्रैकिंग शीट में शामिल करने की आवश्यकता है तो @ kacole2 पिंग करें

धन्यवाद!

kacole2 8 अक्तू॰ 2018

1.13 में कोई बदलाव की योजना नहीं है।

tallclair 8 अक्तू॰ 2018

👍1

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

सिग-टेस्टिंग, कुबेरनेट्स/टेस्ट-इंफ्रा और/या फेजटा को फीडबैक भेजें।
/जीवनचक्र बासी

fejta-bot 6 जन॰ 2019

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

krmayankk 7 जन॰ 2019

@tallclair हैलो - मैं 1.14 के लिए एन्हांसमेंट का नेतृत्व कर रहा हूं और मैं इस मुद्दे पर जांच कर रहा हूं कि 1.14 रिलीज के लिए क्या काम (यदि कोई हो) की योजना बनाई जा रही है। एन्हांसमेंट फ़्रीज़ 29 जनवरी है और मैं याद दिलाना चाहता हूँ कि सभी एन्हांसमेंट में KEP होना चाहिए

claurence 16 जन॰ 2019

1.14 के लिए कुछ भी योजनाबद्ध नहीं है।

tallclair 16 जन॰ 2019

इसके GA होने के लिए क्या अंतराल हैं? मैं कुछ के बारे में सोच सकता हूं, लेकिन मुझे विवरण में कोई मानदंड नहीं दिख रहा है।

zhouhaibing089 25 मार्च 2019

इससे पहले कि हम GA में जा सकें, हमें इन समस्याओं को ठीक करना होगा:

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

@liggitt और मेरे पास इस बारे में कुछ विचार हैं कि इसे कैसे संबोधित किया जाए, लेकिन इस बारे में एक खुला प्रश्न है कि क्या यह कोर कुबेरनेट्स में है। मैं अगले महीने एक रोडमैप बनाना चाहता हूं, या तो जीए में जाने की योजना या बहिष्करण की योजना।

tallclair 25 मार्च 2019

👍5

जानकारी साझा करने के लिए धन्यवाद!

क्योंकि पॉड्स डिफ़ॉल्ट रूप से अस्वीकार कर दिए जाते हैं, हम PSP को बिना तोड़े सभी क्लस्टर में रोल आउट नहीं कर सकते।

मुझे लगता है कि वास्तव में ऐसा नहीं है। हमने एक PodSecurityPolicy बनाकर ऐसा किया है जो पहले पर्याप्त खुला है (या यहां तक कि सभी को खोलें), और फिर इसे धीरे-धीरे परिष्कृत करें।

zhouhaibing089 26 मार्च 2019

@ zuhaibing089 एक Kubrenetes उपयोगकर्ता उस पद्धति का उपयोग कर सकता है जो काम करती है क्योंकि वे नीतियों को नियंत्रित करते हैं। हालाँकि, हम इसे कुबेरनेट्स डिफ़ॉल्ट के रूप में रोल आउट नहीं कर सकते क्योंकि PodSecurityPolicy केवल क्लस्टर को खोलता है, जिसका अर्थ है कि सिस्टम नियंत्रित अनुमति-सभी PSP को प्रबंधित करना बहुत मुश्किल है।

tallclair 26 मार्च 2019

हैलो @liggitt @tallclair , मैं 1.15 के लिए एन्हांसमेंट लीड हूं। क्या यह सुविधा 1.15 में अल्फा/बीटा/स्थिर चरणों में स्नातक होने जा रही है? कृपया मुझे बताएं ताकि इसे ठीक से ट्रैक किया जा सके और स्प्रेडशीट में जोड़ा जा सके। 1.15 में शामिल करने के लिए सामुदायिक प्रस्ताव को केईपी में स्थानांतरित करने की आवश्यकता होगी।

एक बार कोडिंग शुरू हो जाने पर, कृपया इस मुद्दे में सभी प्रासंगिक k/k PRs को सूचीबद्ध करें ताकि उन्हें ठीक से ट्रैक किया जा सके।

kacole2 12 अप्रैल 2019

1.15 . के लिए कोई बदलाव की योजना नहीं है

tallclair 12 अप्रैल 2019

@tallclair वास्तव में इस भूमि को 1.16 में GA के रूप में देखना पसंद करेंगे। क्या यह संभव है?

lachie83 19 जून 2019

@lachie83 नहीं, हमें यकीन नहीं है कि हम चाहते हैं कि PodSecurityPolicy GA में जाए। यह स्पष्ट नहीं है कि यह एक उपयोग का मामला है जिसे कुबेरनेट्स कोर द्वारा हल किया जाना चाहिए, और हम आउट-ऑफ-कोर विकल्पों की तलाश कर रहे हैं। यदि आप इस पर अधिक विस्तार से चर्चा करना चाहते हैं, तो यह SIG-Auth के लिए एक अच्छा विषय है।

tallclair 19 जून 2019

👍2

@tallclair क्या ओपन पॉलिसी एजेंट के द्वारपाल की तरह सामान नीचे जाने के लिए एक बेहतर रास्ता होगा?

SEJeff 19 जून 2019

हाँ बिल्कुल। वह प्रमुख दावेदार हो सकता है, और मैं यह सुनिश्चित करने के लिए उस टीम के साथ मिलकर काम कर रहा हूं कि यह इन उपयोग मामलों को कवर करेगा।

tallclair 19 जून 2019

❤3 👍2

जिस एक चीज का मैं इंतजार कर रहा था, वह एक ऐसा उपकरण है जो संभावित रूप से PodSecurityPolicy -> OPA rego नीति का अनुवाद कर सकता है। इससे उन्हें आपके दृष्टिकोण से बहिष्कृत करना बहुत आसान हो जाएगा।

SEJeff 19 जून 2019

@tallclair त्वरित प्रतिक्रिया की सराहना करता है

lachie83 19 जून 2019

@SEJeff सहमत हुए। हम PodSecurityPolicy को तब तक नहीं हटाएंगे जब तक कि फीचर समता और माइग्रेशन पथ के साथ स्पष्ट प्रतिस्थापन न हो।

tallclair 19 जून 2019

अरे @tallclair , आपने GA के रोडमैप या बहिष्करण की योजना का उल्लेख किया है। ऐसा लगता है कि हम बाद की ओर झुक रहे हैं।

क्या हमारे पास उन लोगों की मदद करने के लिए कुछ लिखा है जो पीएसपी को एक समाधान के रूप में देख रहे हैं?

justaugustus 19 जून 2019

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

tallclair 19 जून 2019

👍3

डब्ल्यूटीएफ

angelbarrera92 4 जुल॰ 2019

👎7

नमस्ते @tallclair ऐसा लगता है कि 1.16 के लिए भी यहां कुछ नहीं हो रहा है इसलिए मैं इसे वही रखूंगा।

kacole2 9 जुल॰ 2019

👍1

अरे वहाँ @tallclair -- 1.17 एन्हांसमेंट लीड यहाँ -- ऐसा लगता है कि यह 1.17 के लिए यथावत है। यदि वह बदलता है, तो कृपया मुझे एक प्रहार देने में संकोच न करें और मैं इसे ट्रैकिंग शीट में जोड़ सकता हूं

mrbobbytables 26 सित॰ 2019

क्या पीएसपी के भविष्य के लिए एक स्पष्ट मार्ग पर कोई और चर्चा हुई है?

dstrebel 10 अक्तू॰ 2019

हाँ बिल्कुल। वह प्रमुख दावेदार हो सकता है, और मैं यह सुनिश्चित करने के लिए उस टीम के साथ मिलकर काम कर रहा हूं कि यह इन उपयोग मामलों को कवर करेगा।

@tallclair - हमने Kyverno में अधिकांश PSP जाँचों को लागू किया है। क्या आप एक नज़र डालने में मदद कर सकते हैं? विचारों और विवरणों पर चर्चा करना पसंद करेंगे।

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

JimBugwadia 28 अक्तू॰ 2019

गेटकीपर परियोजना यह भी देख रही है कि पीएसपी के बाद की दुनिया कैसी दिखेगी। हमारा प्रारंभिक दृष्टिकोण व्यक्तिगत बाधाओं में पीएसपी संसाधन को तोड़ने का रहा है। हम सोच रहे थे कि इस दृष्टिकोण पर समुदाय के विचार क्या थे। शायद यह फिर से कल्पना करने का एक अच्छा समय होगा कि ये नीतियां कैसी हैं? नए यूजर्स और मौजूदा PSP यूजर्स दोनों के लिए माइग्रेशन भी महत्वपूर्ण होगा।

cc @maxsmythe @sozercan @tsandall

ritazh 29 अक्तू॰ 2019

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

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

tallclair 29 अक्तू॰ 2019

@tallclair हम जिन उपयोग मामलों का अनुसरण कर रहे हैं उनमें से एक नामस्थान आधारित बहु-किरायेदारी से संबंधित है। इरादा प्रतिबंधों को लागू करने के लिए नीतियों का उपयोग करना और यह सुनिश्चित करना है कि नामस्थान ठीक से कॉन्फ़िगर किए गए हैं।

JimBugwadia 31 अक्तू॰ 2019

इससे पहले कि हम GA में जा सकें, हमें इन समस्याओं को ठीक करना होगा:
त्रुटिपूर्ण प्राधिकरण मॉडल - पीएसपी उपयोग आरबीएसी के माध्यम से प्रदान किया जाता है, और या तो उपयोगकर्ता को या निर्मित पॉड को दिया जा सकता है। उपयोगकर्ता को इसे प्रदान करना सहज दृष्टिकोण है, लेकिन समस्याग्रस्त है (स्पष्टीकरण देखें)। इस दृष्टिकोण में कुछ सुरक्षा मुद्दे भी हैं।

@tallclair , मैं उपरोक्त के बारे में सोच रहा हूं - क्या आप इस बारे में विस्तार से बता सकते हैं कि यह दृष्टिकोण कैसे समस्याग्रस्त है और/या सुरक्षा समस्याएं हैं?

jleadford 19 नव॰ 2019

क्या कोई और जानकारी दे सकता है कृपया इस ट्वीट की पुष्टि करें:

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

और अगर यह सच है, तो आज लिनक्स क्षमताओं को सीमित करने के लिए PSP का उपयोग करने वाले लोगों को आगे क्या करना चाहिए?

bjhaid 22 नव॰ 2019

नमस्ते,
यह एक बहुत ही रोचक चर्चा है और हम वर्तमान में कुबेरनेट्स क्लस्टर में पॉड निर्माण को सुरक्षित करने के लिए समाधान ढूंढ रहे हैं।

हमने OPA गेटकीपर और PodSecurityPolicies दोनों के साथ-साथ OPA बाधाओं में PSP को फिर से लागू करने के प्रयास पर एक नज़र डाली है।
इस तुलना के साथ हमें जो मूलभूत समस्या मिली, वह यह है कि हम दो विपरीत मॉडलों के साथ काम कर रहे हैं।

OPA गेटकीपर ओपन-बाय-डिफॉल्ट मॉडल का अनुसरण करता है, जिसमें हर चीज की अनुमति होती है और एडमिन कुछ चीजों को बाधाओं के साथ मना करता है।
PSP क्लोज-बाय-डिफॉल्ट मॉडल का अनुसरण करता है, जिसमें सब कुछ निषिद्ध है और व्यवस्थापक नीतियों के साथ कुछ चीजों की अनुमति देता है।

सुरक्षा के दृष्टिकोण से, मैं तर्क दूंगा कि पीएसपी मॉडल बेहतर है, हालांकि मौजूदा क्लस्टर में लाना अधिक कठिन है क्योंकि सभी कार्यभार इसके अनुरूप होने चाहिए।

आप पीएसपी और बाधा ढांचे के बीच वास्तुकला में इस मूलभूत अंतर को कैसे पाटने की योजना बना रहे हैं?

/cc @ritazh मुझे इस पर आपकी राय जानना अच्छा लगेगा, क्योंकि आपने PSP कार्यक्षमता को OPA में पोर्ट करने पर काम किया है।

yanniszark 2 दिस॰ 2019

विभिन्न दृष्टिकोण निश्चित रूप से प्रवासन को और अधिक जटिल बनाते हैं। हम ट्रांज़िशन को आसान बनाने के लिए अलग-अलग तरीके तलाश रहे हैं।

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

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

tallclair 5 दिस॰ 2019

👍1

@tallclair क्या आप 1.18 में इस पर कोई प्रगति की उम्मीद करते हैं? मैं रिलीज के लिए एक एन्हांसमेंट शैडो हूं और जानना चाहूंगा कि क्या हमें इसे ट्रैक करना चाहिए।

johnbelamaric 14 जन॰ 2020

1.18 . के लिए कोई बदलाव की योजना नहीं है

tallclair 17 जन॰ 2020

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

fejta-bot 16 अप्रैल 2020

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

palnabarun 17 अप्रैल 2020

@tallclair हाय टिम। 1.19 में इसके लिए कोई योजना?

johnbelamaric 4 मई 2020

v1.19 के लिए कोई योजना नहीं है, हालांकि मैं v1.20 समय सीमा में कुछ हलचल देखने की उम्मीद कर रहा हूं।

tallclair 4 मई 2020

ओपन पॉलिसी एजेंट के साथ कुबेरनेट्स पॉड सुरक्षा नीतियों पर बस ठोकर खाई। @tallclair क्या आप साझा कर सकते हैं कि हमें क्या रोक रहा है और जहां सहायता की आवश्यकता है, साथ ही योगदान करने में प्रसन्नता हो रही है।

mhausenblas 28 मई 2020

क्या आप साझा कर सकते हैं जो हमें रोक रहा है

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

कोई प्रतिस्थापन नहीं - प्रवेश वेबहुक के साथ किसी तृतीय पक्ष विकल्प से चुनने की अनुशंसा करें। हाल ही में प्रकाशित पॉड सुरक्षा मानक डॉक समान कार्यक्षमता को बढ़ावा देकर इसे आसान बनाने की कोशिश कर रहा है।
नियंत्रण में निर्मित विकल्प
1. @ deads2k ने अपस्ट्रीमिंग ओपनशिफ्ट्स का प्रस्ताव दिया है SecurityContextConstraints
2. मैंने एक न्यूनतम विन्यास योग्य सुविधा का प्रस्ताव दिया है जो केवल ऊपर से जुड़ी मानक नीतियों को लागू करती है (और अधिक विन्यास की आवश्यकता होने पर तीसरे पक्ष के समाधान की सिफारिश करती है)
पॉड सुरक्षा नीति को ठीक करें - हालांकि कुछ मुद्दे डिजाइन के लिए पर्याप्त हैं, कि इसे गैर-पिछड़े संगत होने की आवश्यकता होगी, जिस बिंदु पर यह एक नया विकल्प भी हो सकता है (2)

tallclair 1 जून 2020

👍4

क्या मैं https://github.com/kubernetes/kubernetes/pull/90603 सही ढंग से पढ़ रहा हूं क्योंकि पॉड सुरक्षा मानकों को प्रकाशित किया गया है, एपीआई सर्वर में पीएसपी के लिए कोई नियोजित प्रतिस्थापन नहीं है और किसी भी प्रतिस्थापन को बाहरी सिस्टम के रूप में लागू करने की आवश्यकता होगी?

mlbiam 9 जुल॰ 2020

देखें https://github.com/kubernetes/enhancements/issues/5#issuecomment -637066475

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

liggitt 9 जुल॰ 2020

👍1

धन्यवाद @liggitt पुष्टि कर रहा था कि कुछ भी सेट नहीं किया गया था। सोचा था कि मूल रूप से प्रतिस्थापन उपलब्ध होने तक कुछ भी बहिष्कृत नहीं किया जाएगा। यह स्पष्ट नहीं था कि निर्णय एक तरह से या किसी अन्य तरीके से किया गया था।

mlbiam 9 जुल॰ 2020

बहिष्करण समयरेखा PSP के लिए विशिष्ट नहीं है और इसे https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1635-prevent-permabeta के भाग के रूप में जोड़ा गया था।

liggitt 9 जुल॰ 2020

अगर मैं इसे सही ढंग से पढ़ रहा हूं, तो बहिष्करण को धक्का दे रहा है कि कोई एपीआई एक ही बीटा संस्करण में 9 महीने से अधिक समय तक नहीं होना चाहिए, इसलिए पीएसपी को पदोन्नत या बहिष्कृत करने की आवश्यकता है और चूंकि कोई नया बीटा या पीएसपी का जीए नहीं होगा भले ही प्रतिस्थापन का निर्णय नहीं लिया गया हो, फिर भी इसे पदावनति के लिए ट्रैक पर आने की आवश्यकता है?

mlbiam 9 जुल॰ 2020

अगर मैं इसे सही ढंग से पढ़ रहा हूं, तो बहिष्करण को धक्का दे रहा है कि कोई भी एपीआई एक ही बीटा संस्करण में 9 महीने से अधिक समय तक नहीं होना चाहिए

बिल्कुल। सभी बिल्ट इन एपीआई के सभी भावी बीटा संस्करण पहले से पेश किए जाने पर प्रीबेक्ड डेप्रिसिएशन और रिमूवल टारगेट के साथ आएंगे

liggitt 9 जुल॰ 2020

👍3

नमस्ते @tallclair

संवर्द्धन यहां लीड। 1.20 में इसके लिए कोई योजना?

धन्यवाद,
कर्स्टन

kikisdeliveryservice 12 सित॰ 2020

v1.20 के लिए कोई योजना नहीं है।

tallclair 17 सित॰ 2020

👍2

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

जबकि पीएसपी में खामियां हैं, वे कार्य करते हैं, और 10 रिलीज के लिए कार्य करते हैं।
एक परियोजना के रूप में कुबेरनेट्स को कार्यभार रनटाइम सुरक्षा की परवाह करनी चाहिए। कंटेनर से बच निकलना बहुत आसान है। PSP उन कुछ उपकरणों में से एक है जो हमलावरों के लिए इसे कठिन बनाते हैं।
पूर्ण हो गया का दुश्मन है। PSP को यथावत मर्ज करें, और "बेहतर" कार्यान्वयन को नीति/v2.
अंत में, और सबसे महत्वपूर्ण, यह ओएसएस डेवलपर्स को उच्च सुरक्षा क्लस्टर चलाने की अनुमति देता है, न कि केवल उन कंपनियों को जो स्टायरा जैसे विक्रेताओं को वहन कर सकती हैं।

zapman449 17 नव॰ 2020

👍13

@ zapman449 क्या आप स्पष्ट कर सकते हैं कि "पूरी तरह से प्रतिबंधात्मक PSP प्रतिस्थापन" से आपका क्या मतलब है?

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

maxsmythe 17 नव॰ 2020

👍2

@ zapman449 क्या आपके पास उस ब्लॉगपोस्ट का लिंक होगा?

christianhuening 17 नव॰ 2020

👍1

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

zapman449 17 नव॰ 2020

@maxsmythe मैंने गेटकीपर पीएसपी क्या कर रहा है, इसकी समीक्षा नहीं की है।

हालांकि, मेरा मतलब यह है:

NET_BIND_SERVICE, SYS_ADMIN, आदि जैसी प्रक्रिया क्षमताओं पर पूर्ण नियंत्रण
UID/GID/FSGroup को गैर-शून्य मानों तक सीमित करें
मेजबान पथों की स्पष्ट सूची जिसे आरोहित किया जा सकता है
वॉल्यूम माउंट के प्रकारों की स्पष्ट सूची की अनुमति है
ब्लॉक प्रिविलेज्ड, ब्लॉक प्रिविलेज एस्केलेशन
मेजबान स्तर के इंटरप्रोसेस संचार आदिम तक पहुंच को अवरुद्ध करें
मेजबान नेटवर्किंग तक पहुंच को अवरुद्ध करें
प्रतिबंधित करें कि कौन से होस्ट पोर्ट की अनुमति है
केवल पढ़ने के लिए रूटफाइल सिस्टम लागू करें
SELinux के लिए कनेक्शन बिंदु

ये आज पीएसपी के साथ प्रदान किए जाते हैं।

अगर हम एक इच्छा सूची मांग रहे हैं, तो मुझे अच्छा लगेगा:

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

zapman449 17 नव॰ 2020

@ zapman449 - यदि आपने इसे नहीं देखा है, तो हमने पिछली सिग-ऑथ मीटिंग (https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/view#heading=h.h.zsgtsqg पर चर्चा की थी। ) यदि आप इसे करने में सक्षम हैं तो हम 9 दिसंबर की बैठक में चर्चा जारी रखेंगे, लेकिन हम मेलिंग सूची में प्रस्ताव भेजे बिना कोई अंतिम निर्णय भी नहीं लेंगे।

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

tallclair 18 नव॰ 2020

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स