पॉड सुरक्षा नीतियों से माइग्रेट करना: एक व्यापक मार्गदर्शिका (भाग 1: पीएसए में परिवर्तन)

परिचय जैसे-जैसे कुबेरनेट्स अग्रणी कंटेनर ऑर्केस्ट्रेशन प्लेटफ़ॉर्म के रूप में परिपक्व हो रहा है, कंटेनरीकृत अनुप्रयोगों को तैनात करने वाले संगठनों के लिए सुरक्षा एक सर्वोपरि चिंता बनी हुई है। कुबेरनेट्स के सुरक्षा शस्त्रागार में मूलभूत उपकरणों में से, एक बार महत्वपूर्ण भूमिका निभाई थी। पीएसपी ने प्रशासकों को पॉड्स पर सुरक्षा बाधाओं को सावधानीपूर्वक परिभाषित करने और लागू करने की अनुमति दी, यह सुनिश्चित करते हुए कि केवल विशिष्ट सुरक्षा मानकों को पूरा करने वाले कंटेनर ही क्लस्टर के भीतर काम कर सकते हैं। हालाँकि, कुबेरनेट्स सुरक्षा का परिदृश्य तेजी से विकसित हो रहा है, और यह ध्यान रखना महत्वपूर्ण है कि पीएसपी को अब कुबेरनेट्स 1.25 से शुरू करके हटा दिया गया है (कुबेरनेट्स 1.25 तत्काल रिलीज़ नोट्स का लिंक देखें)। यह परिवर्तन विभिन्न कारकों से उत्पन्न होता है, जिसमें पीएसपी नीतियों के प्रबंधन और रखरखाव की जटिलता भी शामिल है, जो अक्सर उपयोगकर्ताओं के लिए परिचालन चुनौतियों का कारण बनती है। बहिष्कार के जवाब में, संगठन अब पीएसपी के आधुनिक विकल्पों की तलाश कर रहे हैं, जो न केवल सुरक्षा आवश्यकताओं को संबोधित करते हैं बल्कि में वर्कलोड को सुरक्षित करने की प्रक्रिया को भी सुव्यवस्थित करते हैं। इस व्यापक गाइड में, हम कुबेरनेट्स सुरक्षा प्रथाओं में इस बदलाव को नेविगेट करने के लिए एक यात्रा शुरू करते हैं, जो पॉड सुरक्षा प्रवेश (पीएसए) में संक्रमण पर ध्यान केंद्रित करता है। पीएसए उपलब्ध सबसे मजबूत विकल्पों में से एक है, और यह लेख इसकी गहराई से पड़ताल करता है। हालाँकि, यह उल्लेखनीय है कि दो अन्य विकल्प, किवर्नो और ओपीए गेटकीपर, इस श्रृंखला के भीतर अलग-अलग लेखों में शामिल किए जाएंगे। इस पूरे लेख में, आपको पीएसए की स्थापना और स्थापना के लिए विस्तृत निर्देश, पीएसपी से पीएसए में आसानी से संक्रमण के लिए चरण-दर-चरण माइग्रेशन गाइड और मौजूदा पीएसपी नियमों को पीएसए में स्थानांतरित करने के लिए सटीक आदेश मिलेंगे। इसके अतिरिक्त, आप पीएसए के अनुरूप ड्राई-रन कमांड का उपयोग करके माइग्रेशन तैयारी के लिए नेमस्पेस का आकलन करने का ज्ञान प्राप्त करेंगे। इस गाइड के अंत तक, आप पीएसए की शक्तियों और सीमाओं की व्यापक समझ प्राप्त कर लेंगे, जो आपको आपके संगठन की विशिष्ट सुरक्षा आवश्यकताओं और कुबेरनेट्स पर्यावरण के आधार पर एक सूचित निर्णय लेने में सक्षम बनाएगी। इस गाइड के साथ, आप आत्मविश्वास से अपनी कुबेरनेट्स सुरक्षा प्रथाओं को आधुनिक बना सकते हैं, यह सुनिश्चित करते हुए कि पॉड सुरक्षा नीतियों के युग को अलविदा कहते समय आपका कार्यभार सुरक्षित रहे। पॉड सुरक्षा नीतियों (पीएसपी) ने कुबेरनेट्स पॉड सुरक्षा प्रवेश (पीएसए) पीएसए सुनिश्चित करता है कि कंटेनर कुबेरनेट्स के मूल सुरक्षा मानकों का पालन करें, जो पॉड सुरक्षा मानकों द्वारा परिभाषित हैं। ये मानक सुरक्षा नीतियों को तीन अलग-अलग प्रोफाइलों में वर्गीकृत करते हैं, जिनमें से प्रत्येक में प्रतिबंधात्मकता का एक अलग स्तर होता है: पीएसए कुबेरनेट्स सुरक्षा मानकों को लागू करता है: : विशेषाधिकार नीति जानबूझकर खुली और पूरी तरह से अप्रतिबंधित है। आमतौर पर, यह नीति विश्वसनीय उपयोगकर्ताओं द्वारा प्रबंधित सिस्टम- और बुनियादी ढांचे-स्तरीय वर्कलोड को लक्षित करती है। यह प्रतिबंधों की अनुपस्थिति की विशेषता है। जबकि गेटकीपर जैसे डिफ़ॉल्ट-अनुमति तंत्र को स्वाभाविक रूप से विशेषाधिकार प्राप्त हो सकता है, पॉड सुरक्षा नीति (पीएसपी) जैसे इनकार-दर-डिफ़ॉल्ट तंत्र के लिए, विशेषाधिकार प्राप्त नीति को सभी प्रतिबंधों को निष्क्रिय करना चाहिए। विशेषाधिकार प्राप्त : बेसलाइन नीति ज्ञात विशेषाधिकार वृद्धि को रोकते हुए सामान्य कंटेनरीकृत कार्यभार द्वारा आसानी से अपनाने के लिए डिज़ाइन की गई है। यह एप्लिकेशन ऑपरेटरों और गैर-महत्वपूर्ण एप्लिकेशन के डेवलपर्स को सेवाएं प्रदान करता है। बेसलाइन : प्रतिबंधित नीति कठोर पॉड सख्त सर्वोत्तम प्रथाओं को लागू करने पर केंद्रित है, भले ही कुछ अनुकूलता की संभावित कीमत पर। यह मुख्य रूप से सुरक्षा-महत्वपूर्ण अनुप्रयोगों के ऑपरेटरों और डेवलपर्स के साथ-साथ कम-भरोसेमंद उपयोगकर्ताओं को लक्षित करता है। प्रत्येक प्रोफ़ाइल के अंतर्गत लागू या अस्वीकृत किए जाने वाले नियंत्रणों की विस्तृत सूची के लिए, आप आधिकारिक दस्तावेज़ का संदर्भ ले सकते हैं। प्रतिबंधित कुछ अन्य समाधानों के विपरीत, पीएसए पॉड सुरक्षा नीति (पीएसपी) नियमों को सीधे स्थानांतरित करने या संशोधित करने के लिए एक सीधी विधि प्रदान नहीं करता है। पीएसए का प्राथमिक ध्यान ऊपर उल्लिखित प्रोफाइल सहित स्थापित के खिलाफ पॉड्स को मान्य करने पर है। कोई प्रत्यक्ष पीएसपी नियम स्थानांतरण नहीं: कुबेरनेट्स सुरक्षा मानकों : जबकि पीएसए सत्यापन में प्रभावी है, यह पीएसपी की तरह पॉड विनिर्देशों को संशोधित या अनुकूलित नहीं कर सकता है। पीएसए का मुख्य उद्देश्य पूर्वनिर्धारित कुबेरनेट्स सुरक्षा मानकों को लागू करना है और इसमें पॉड विनिर्देशों को बदलने या बदलने की सुविधाएँ शामिल नहीं हैं। यह मुख्य रूप से इन स्थापित मानकों के विरुद्ध पॉड्स को मान्य करने पर केंद्रित है। कोई उत्परिवर्तन नहीं सेटअप और इंस्टालेशन चूंकि पीएसए एक कुबेरनेट्स नेटिव घटक है, इसे काम करने के लिए, आपको बस यह सुनिश्चित करना होगा कि आपके कुबेरनेट्स क्लस्टर में पॉड सिक्योरिटी एडमिशन (पीएसए) नियंत्रक सक्षम है। आप निम्न आदेश चलाकर ऐसा कर सकते हैं: kubectl api-versions | grep admission प्रवास के लिए तैयारी के चरण नेमस्पेस अनुमतियों का आकलन करें पॉड सुरक्षा प्रवेश का नियंत्रण नेमस्पेस लेबल से प्रभावित होता है। इसका तात्पर्य यह है कि नामस्थानों को अद्यतन करने, पैच करने या बनाने की क्षमता रखने वाले व्यक्तियों के पास उन नामस्थानों के लिए पॉड सुरक्षा सेटिंग्स को संशोधित करने का अधिकार भी है। यह संशोधन संभावित रूप से कड़ी सुरक्षा नीतियों को दरकिनार कर सकता है। आगे बढ़ने से पहले, यह सत्यापित करना आवश्यक है कि नेमस्पेस अनुमतियाँ विशेष रूप से विश्वसनीय और विशेषाधिकार प्राप्त उपयोगकर्ताओं को सौंपी गई हैं। यह सलाह दी जाती है कि उन उपयोगकर्ताओं को ये उन्नत अनुमतियाँ देने से परहेज करें जिन्हें ऐसी पहुँच की आवश्यकता नहीं है। यदि नेमस्पेस ऑब्जेक्ट पर पॉड सुरक्षा लेबल को कॉन्फ़िगर करने के लिए अतिरिक्त बाधाओं की आवश्यकता है, तो उन प्रतिबंधों को लागू करने के लिए प्रवेश वेबहुक का उपयोग करने पर विचार करें। PodSecurityPolicies को सुव्यवस्थित और सामान्य करें पॉड सिक्योरिटी एडमिशन (पीएसए) में स्थानांतरित होने से पहले, अपनी पॉड सिक्योरिटी पॉलिसी (पीएसपी) को सामान्य बनाना फायदेमंद है: : पॉड सुरक्षा मानकों द्वारा कवर नहीं किए गए विकल्पों को हटा दें। इन विकल्पों में शामिल हैं: असमर्थित फ़ील्ड हटाएं .spec.allowedHostPaths .spec.allowedFlexVolumes .spec.allowedCSIDrivers .spec.forbiddenSysctls .spec.runtimeClass : उन फ़ील्ड को हटाकर प्रक्रिया शुरू करें जिनका केवल परिवर्तनशील प्रभाव होता है और जो सत्यापन नीति को प्रभावित नहीं करते हैं। इन फ़ील्ड्स में, जैसा कि "पॉड सिक्योरिटी पॉलिसियों को पॉड सुरक्षा मानकों से मैप करना" संदर्भ में भी उल्लेख किया गया है, इसमें शामिल हैं: पूरी तरह से परिवर्तनशील फ़ील्ड को हटा दें .spec.defaultAllowPrivilegeEscalation .spec.runtimeClass.defaultRuntimeClassName .metadata.annotations['seccomp.security.alpha.kubernetes.io/defaultProfileName'] .metadata.annotations['apparmor.security.beta.kubernetes.io/defaultProfileName'] .spec.defaultAddCapabilities महत्वपूर्ण लेख: इन फ़ील्ड्स को हटाने से कार्यभार में आवश्यक कॉन्फ़िगरेशन की कमी हो सकती है, जो संभावित रूप से परिचालन संबंधी समस्याएं पैदा कर सकती है। यह सुनिश्चित करना महत्वपूर्ण है कि कार्यभार सरलीकृत नीतियों के साथ सही ढंग से कार्य कर सके। उपयुक्त पॉड सुरक्षा स्तर निर्धारित करें अपने नेमस्पेस के लिए उचित पॉड सुरक्षा स्तर का निर्धारण करते समय, आपके पास विचार करने के लिए कई तरीके हैं: नेमस्पेस के लिए सुरक्षा आवश्यकताओं द्वारा यदि आप नेमस्पेस के लिए अपेक्षित पहुंच स्तर और सुरक्षा आवश्यकताओं से परिचित हैं, तो आप उन विशिष्ट आवश्यकताओं के आधार पर एक उपयुक्त पॉड सुरक्षा स्तर का चयन कर सकते हैं। यह दृष्टिकोण उसी के समान है कि आप किसी नए क्लस्टर में सुरक्षा सेटिंग्स तक कैसे पहुंचेंगे। मौजूदा PodSecurityPolicies द्वारा: अपनी प्रत्येक मौजूदा संदर्भ का उपयोग करें। यदि आपके पीएसपी मूल रूप से पॉड सुरक्षा मानकों पर आधारित नहीं हैं, तो आपको निर्णय लेने की आवश्यकता हो सकती है। ऐसा पॉड सुरक्षा स्तर चुनें जो कम से कम आपके पीएसपी जितना अनुमेय हो, या ऐसा स्तर चुनें जो कम से कम प्रतिबंधात्मक हो। यह पहचानने के लिए कि किसी विशिष्ट नामस्थान के भीतर पॉड्स के लिए कौन से पीएसपी उपयोग में हैं, निम्नलिखित कमांड का उपयोग करें: पॉड सुरक्षा नीतियों (पीएसपी) को संबंधित पॉड सुरक्षा मानक स्तर पर मैप करने के लिए "पॉड सुरक्षा नीतियों को पॉड सुरक्षा मानकों पर मैप करना" kubectl get pods -n $NAMESPACE -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u मौजूदा पॉड्स द्वारा: बेसलाइन और प्रतिबंधित पॉड सुरक्षा दोनों स्तरों का परीक्षण करने के लिए ड्राई रन करें और अगले अनुभाग से लेबल कमांड लागू करें। इससे आपको यह आकलन करने में मदद मिलती है कि क्या ये स्तर आपके मौजूदा कार्यभार के लिए पर्याप्त रूप से स्वीकार्य हैं। सबसे कम-विशेषाधिकार प्राप्त वैध स्तर चुनें जो आपके मौजूदा कार्यभार के साथ संरेखित हो। यह ध्यान रखना महत्वपूर्ण है कि उल्लिखित विकल्प मौजूदा पॉड्स पर आधारित हैं, जो वर्तमान में नहीं चल रहे वर्कलोड के लिए जिम्मेदार नहीं हो सकते हैं। इसमें क्रोनजॉब्स, स्केल-टू-ज़ीरो वर्कलोड, या अन्य वर्कलोड शामिल हैं जिन्हें अभी तक तैनात नहीं किया गया है। पॉड सुरक्षा स्तर का परीक्षण एक बार जब आप अपने नेमस्पेस के लिए पॉड सुरक्षा स्तर निर्धारित कर लेते हैं (विशेषाधिकार प्राप्त स्तर को छोड़कर), तो चुनी गई नीति को मान्य करना महत्वपूर्ण है। पॉड सिक्योरिटी सुचारू रोलआउट और सुरक्षा मानकों का अनुपालन सुनिश्चित करने के लिए परीक्षण विकल्प प्रदान करता है। ड्राई रन परीक्षण: तत्काल कार्यान्वयन के बिना चयनित नीति के प्रभाव का आकलन करने के लिए इस पद्धति का उपयोग करें। ड्राई रन करने के लिए, निम्नलिखित कमांड का उपयोग करें, जो किसी भी मौजूदा पॉड को हाइलाइट करेगा जो निर्दिष्ट नीति स्तर को पूरा नहीं करता है: kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL ऑडिट मोड परीक्षण: ऑडिट मोड आपको नीति उल्लंघनों को लागू किए बिना रिकॉर्ड करने की अनुमति देता है। उल्लंघन करने वाले पॉड्स को बाद में समीक्षा के लिए ऑडिट रिकॉर्ड में लॉग किया जाता है। कमांड के साथ ऑडिट मोड सक्षम करें: kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/audit=$LEVEL यदि परीक्षण के दौरान अप्रत्याशित नीति उल्लंघन उत्पन्न होता है, तो आप यह कर सकते हैं: नीति के अनुरूप होने के लिए गैर-अनुपालक कार्यभार को अद्यतन करें। यदि आपके कार्यभार की आवश्यकताओं को समायोजित करने के लिए आवश्यक हो तो नेमस्पेस के लिए पॉड सुरक्षा स्तर को समायोजित करें। पॉड सुरक्षा स्तर लागू करना एक बार जब आप आश्वस्त हो जाएं कि चयनित पॉड सुरक्षा स्तर आपके नेमस्पेस के लिए उपयुक्त है, तो आप इसे लागू करने के लिए आगे बढ़ सकते हैं। यह चरण सुनिश्चित करता है कि वांछित सुरक्षा मानक नामस्थान के भीतर आपके कार्यभार पर सक्रिय रूप से लागू होते हैं। नेमस्पेस पर वांछित पॉड सुरक्षा स्तर लागू करने के लिए, निम्नलिखित कमांड का उपयोग करें: kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL इस आदेश को निष्पादित करने से निर्दिष्ट पॉड सुरक्षा स्तर सक्रिय और लागू हो जाएगा, जिससे आपके नेमस्पेस की सुरक्षा स्थिति बढ़ जाएगी। पीएसपी को दरकिनार करना नेमस्पेस स्तर पर PodSecurityPolicy को प्रभावी ढंग से बायपास करने के लिए, आप नेमस्पेस में सभी सेवा खातों के लिए एक पूर्ण विशेषाधिकार प्राप्त पॉड सिक्योरिटी पॉलिसी (PSP) को बाइंड कर सकते हैं। यह प्रक्रिया सुनिश्चित करती है कि नेमस्पेस के भीतर पॉड्स अब PodSecurityPolicy द्वारा लगाए गए संशोधनों या प्रतिबंधों के अधीन नहीं हैं। आप इसे क्लस्टर स्तर पर या व्यक्तिगत नामस्थान स्तर पर कर सकते हैं। क्लस्टर-स्कोप्ड सेटअप (पूरे क्लस्टर के लिए केवल एक बार आवश्यक): YAML कॉन्फ़िगरेशन फ़ाइल, जैसे कि लागू करके एक पूर्ण विशेषाधिकार प्राप्त पॉड सुरक्षा नीति (PSP) बनाएं। इस पीएसपी को पॉड्स को सभी आवश्यक विशेषाधिकार प्रदान करने चाहिए और पॉड सुरक्षा नीतियों (पीएसपी) के उपयोग की अनुमति देने के लिए विशेषाधिकार प्राप्त-पीएसपी नामक एक क्लस्टर भूमिका बनानी चाहिए और इसे विशेषाधिकार प्राप्त पीएसपी के साथ जोड़ना चाहिए: विशेषाधिकार प्राप्त-psp.yaml kubectl apply -f privileged-psp.yaml kubectl create clusterrole privileged-psp --verb use --resource podsecuritypolicies.policy --resource-name privileged प्रति-नामस्थान अक्षमता: विशेषाधिकार प्राप्त-पीएसपी क्लस्टर भूमिका को समूह के साथ संबद्ध करने के लिए लक्ष्य नामस्थान में एक भूमिका बाइंडिंग बनाएं। यह बाइंडिंग प्रभावी रूप से नेमस्पेस के भीतर सभी सेवा खातों को PodSecurityPolicy को दरकिनार करते हुए पूरी तरह से विशेषाधिकार प्राप्त PSP तक पहुंच प्रदान करती है: system:serviceaccounts:$NAMESPACE kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole privileged-psp --group system:serviceaccounts:$NAMESPACE इस सेटअप के साथ, विशेषाधिकार प्राप्त PSP गैर-परिवर्तनशील है, और PodSecurityPolicy प्रवेश नियंत्रक हमेशा गैर-परिवर्तनशील PSP को प्राथमिकता देता है। परिणामस्वरूप, इस नेमस्पेस में पॉड्स को अब PodSecurityPolicy द्वारा संशोधित या प्रतिबंधित नहीं किया जाएगा। इस दृष्टिकोण का एक लाभ इसकी प्रतिवर्तीता है। यदि कोई समस्या आती है, तो आप PodSecurityPolicy को अक्षम करने से जुड़े रोलबाइंडिंग को हटाकर आसानी से परिवर्तन को वापस ले सकते हैं। सुनिश्चित करें कि इस प्रक्रिया के दौरान पहले से मौजूद पॉड सुरक्षा नीतियां लागू रहें। PodSecurityPolicy अक्षमता को पूर्ववत करें: नेमस्पेस के लिए PodSecurityPolicy अक्षमता को वापस लाने के लिए, बस पहले बनाई गई रोलबाइंडिंग को हटा दें: kubectl delete -n $NAMESPACE rolebinding disable-psp नेमस्पेस निर्माण प्रक्रियाओं पर दोबारा गौर करें पॉड सुरक्षा प्रवेश को लागू करने के लिए मौजूदा नेमस्पेस को अपडेट करने के साथ, नए नेमस्पेस बनाने के लिए अपनी प्रक्रियाओं और नीतियों की समीक्षा करना और उन्हें अपडेट करना आवश्यक है। यह सुनिश्चित करता है कि नए नेमस्पेस शुरू से ही उपयुक्त पॉड सुरक्षा प्रोफ़ाइल के साथ कॉन्फ़िगर किए गए हैं। नेमस्पेस निर्माण प्रक्रियाओं को बढ़ाने के लिए निम्नलिखित चरणों पर विचार करें: : वांछित पॉड सुरक्षा स्तर के चयन और अनुप्रयोग को शामिल करने के लिए नए नेमस्पेस बनाने के लिए अपने संगठन की नीतियों और प्रक्रियाओं को अपडेट करें। सुनिश्चित करें कि निर्माण चरण से ही सुरक्षा मानक स्थापित हो जाएं। नेमस्पेस निर्माण नीतियों को समायोजित करें आप बिना लेबल वाले नामस्थानों के लिए डिफ़ॉल्ट प्रवर्तन, ऑडिट और/या चेतावनी स्तरों को परिभाषित करने के लिए पॉड सुरक्षा प्रवेश नियंत्रक को स्थिर रूप से कॉन्फ़िगर कर सकते हैं। यह दृष्टिकोण सुनिश्चित करता है कि स्पष्ट पॉड सुरक्षा लेबल की कमी वाले नामस्थान अभी भी डिफ़ॉल्ट रूप से आपके निर्दिष्ट सुरक्षा मानकों का पालन करते हैं। स्थैतिक कॉन्फ़िगरेशन: अपने नेमस्पेस निर्माण प्रक्रियाओं पर दोबारा गौर करके, आप में पॉड सुरक्षा मानकों को निर्बाध रूप से एकीकृत कर सकते हैं और पुराने और नए सभी नेमस्पेस पर एक सुसंगत और सुरक्षित दृष्टिकोण बनाए रख सकते हैं। हमारे कुबेरनेट्स वातावरण PodSecurityPolicy अक्षम करें एक बार जब आप आश्वस्त हो जाते हैं कि पॉड सिक्योरिटी पॉलिसी (पीएसपी) प्रवेश नियंत्रक की अब आवश्यकता नहीं है और पॉड सुरक्षा प्रवेश (पीएसए) सफलतापूर्वक लागू और मान्य हो गया है, तो आप पीएसपी प्रवेश नियंत्रक को अक्षम करने के लिए आगे बढ़ सकते हैं। PSP प्रवेश नियंत्रक को अक्षम करने के चरण यहां दिए गए हैं: क्यूब-एपिसर्वर कॉन्फ़िगरेशन संशोधित करें: अपने क्यूब-एपिसर्वर के लिए कॉन्फ़िगरेशन फ़ाइल खोलें, जो आमतौर पर /etc/kubernetes/manifests/kube-apiserver.yaml. PSP प्रवेश नियंत्रक को अक्षम करने के लिए ध्वज जोड़ें। सुनिश्चित करें कि इसे सक्रिय प्रवेश प्लगइन्स की सूची से हटा दिया गया है। --disable-admission-plugins kube-apiserver --disable-admission-plugins=PodSecurityPolicy कॉन्फ़िगरेशन फ़ाइल सहेजें. क्यूब-एपिसर्वर पुनः प्रारंभ करें: परिवर्तनों को लागू करने के लिए क्यूब-एपिसर्वर को पुनरारंभ करें। आप आमतौर पर कुबेरनेट्स नियंत्रण विमान या क्यूब-एपिसर्वर पॉड को पुनः आरंभ करके इसे प्राप्त कर सकते हैं। systemctl restart kubelet सत्यापन: क्यूब-एपिसर्वर लॉग या उसकी स्थिति की जाँच करके सुनिश्चित करें कि PSP प्रवेश नियंत्रक अक्षम है। पर्याप्त "सोख समय" के बाद यह आश्वस्त होने के लिए कि आपको पीएसपी पर वापस जाने की आवश्यकता नहीं होगी, अगले चरण पर आगे बढ़ें। सफाई पीएसपी संसाधन: PSP प्रवेश नियंत्रक अक्षम और PSA के साथ, आप अपनी मौजूदा PodSecurityPolicies, साथ ही किसी भी संबद्ध भूमिका, ClusterRoles, RoleBindings और ClusterRoleBindings को सुरक्षित रूप से हटा सकते हैं। kubectl delete podsecuritypolicies --all kubectl delete roles,clusterroles,rolebindings,clusterrolebindings --selector=rbac.authorization.kubernetes.io/autoupdate=true यह सफ़ाई चरण सुनिश्चित करता है कि आपके क्लस्टर में कोई अवशिष्ट PSP कॉन्फ़िगरेशन नहीं है। पीएसपी प्रवेश नियंत्रक को निष्क्रिय करके और पीएसपी-संबंधित संसाधनों को समाप्त करके, आप पॉड सुरक्षा प्रवेश में संक्रमण को पूरा करते हुए, अपने क्लस्टर की सुरक्षा वास्तुकला को सरल बनाते हैं। सारांश इस व्यापक गाइड में, हमने आपके पॉड सुरक्षा नीतियों (पीएसपी) से पॉड सुरक्षा प्रवेश (पीएसए) में सुचारू रूप से परिवर्तित करने के लिए आवश्यक कदमों और विचारों का पता लगाया है। यह माइग्रेशन सुनिश्चित करता है कि कुबेरनेट्स के विकसित सुरक्षा मानकों के अनुरूप आपका कार्यभार सुरक्षित रूप से चलता रहे। कुबेरनेट्स क्लस्टर के सुरक्षा ढांचे को पॉड सिक्योरिटी एडमिशन (पीएसए) का उपयोग करने के फायदे और नुकसान पेशेवर: : पीएसए कुबेरनेट्स का एक अभिन्न अंग है, जो तीसरे पक्ष के टूल इंस्टॉलेशन की आवश्यकता को समाप्त करता है। यह प्लेटफ़ॉर्म की अंतर्निहित सुरक्षा सुविधाओं का लाभ उठाता है। मूल कुबेरनेट्स घटक : पीएसए कुबेरनेट्स के मूल सुरक्षा मानकों के साथ संरेखित होता है, जिससे प्लेटफ़ॉर्म की सर्वोत्तम प्रथाओं का अनुपालन सुनिश्चित होता है। कुबेरनेट्स मानकों को लागू करता है दोष: : पीएसए पीएसपी के समान स्तर का अनुकूलन प्रदान नहीं कर सकता है, विशेष रूप से जटिल सुरक्षा नीतियों के लिए जिनके लिए पॉड स्पेक्स के उत्परिवर्तन की आवश्यकता होती है। सीमित अनुकूलन : सुरक्षा संदर्भ सेटिंग्स को शामिल करने के लिए मौजूदा कार्यभार को अद्यतन किया जाना चाहिए, जिसके लिए YAML फ़ाइलों में संशोधन की आवश्यकता हो सकती है। रेट्रोफिटिंग आवश्यक यह मार्गदर्शिका आपको पीएसपी से पीएसए में आत्मविश्वास से स्थानांतरित करने के लिए आवश्यक ज्ञान और कदमों से लैस करती है, जो आपके कुबेरनेट्स वर्कलोड की सुरक्षा करते हुए एक सुरक्षित और कुशल संक्रमण सुनिश्चित करती है। आगामी लेखों के लिए बने रहें, जहां मैं किवर्नो और ओपीए गेटकीपर के लिए वैकल्पिक प्रवास पथ तलाशूंगा।